Upload
panchoxman-urenda
View
105
Download
4
Embed Size (px)
Citation preview
1
Fundamentos de Programación Ingeniería en Tecnologías de la Información y Comunicaciones
Objetivo del curso:
Analizar y solucionar problemas informáticos y representar su solución mediante
herramientas de software orientado a objetos.
Competencias previas
Habilidad para el manejo de la computadora.
Navegación en Internet.
Capacidad de análisis y síntesis.
Manejar herramientas de software mediante menús.
Manejar comandos y funciones básicas en algún sistema operativo de
computadora.
Aplicar lógica matemática en la solución de problemas informáticos.
Competencias a desarrollar
Competencias específicas:
Analizar y solucionar problemas informáticos y representar su solución mediante
herramientas de software orientado a objetos.
Aportación del curso al perfil profesional:
La asignatura de Fundamentos de Programación aporta al perfil del Ingeniero en
Tecnologías de la Información y Comunicaciones, los conocimientos, habilidades,
metodología, así como capacidades de análisis y síntesis, para plantear la solución de
problemas susceptibles de ser computarizados, a través de diagramas de flujo,
pseudocódigo, algoritmos y el paradigma de programación orientada a objetos.
Relación con las materias anteriores y posteriores:
Temario:
I. Fundamentos de programación orientada a objetos.
I.1. Evolución de la programación
I.2. Conceptos fundamentales de la Programación Orientada a Objetos
I.3. Lenguajes orientados a objetos
I.4. Relaciones entre clases y objetos
I.5. Papel de clases y objetos en el análisis y el diseño
2
II. Metodología de Solución de Problemas.
II.1. Descripción del problema (enunciado)
II.2. Definición de solución (especificaciones)
II.3. Diseño de la solución (modelado)
II.4. Desarrollo de la solución (codificación)
II.5. Depuración y pruebas (pruebas)
II.6. Documentación (manuales)
III. Herramientas de programación.
III.1. Simbología
III.2. Reglas para la construcción de diagramas
III.3. Pseudocódigo
III.4. Tipos de datos y expresiones
III.5. Estructuras lógicas
IV. Programación orientada a objetos y modelado.
IV.1. Características del modelo orientado a objetos
IV.2. Elementos primordiales en el modelo de objetos
IV.3. Representación gráfica del diseño
IV.4. Relación entre la programación orientada a objetos y la estructurada
V. Implementación Orientada a Objetos.
V.1. Estructura de una clase
V.2. Elementos de una clase
V.3. Clase principal
V.4. Crear objetos
VI. Modularidad.
VI.1. Declaración de métodos
VI.2. Métodos de clase
VI.3. Métodos de instancia
Bibliografía
1. Hjalmar Jacobson, Ivar. El Lenguaje Unificado de Modelado Guía del Usuario. 2a.
edición. Ed. Addison Wesley.
2. Flores Cueto, Juan José. Método de las 6’D UML – Pseudocódigo – Java Enfoque
Algorítmico, Serie Textos Universitarios Facultad de Ingeniería y Arquitectura. ed.
Universidad de San Martín de Porres, (http://books.google.com/).
3. Joyanes Aguilar, Luis; Fernández Azuela, Matilde y Rodríguez Baena, Luis.
Fundamentos de Programación Libro de Problemas Algoritmos Estructura de Datos y
Objetos. 2a. edición. Ed. McGraw Hill.
3
4. Ramírez, Felipe. Introducción a la Programación, Algoritmos y su Implementación en
Vb.Net, C#, Java y JAVA. 2a. edición. Ed. Alfaomega Grupo Editor.
5. Cairo Battistutti, Osvaldo. Metodología de la Programación, Algoritmos Diagramas de
Flujo y Programas. 3a. edición. Ed. Alfaomega Grupo Editor.
6. Martin Robert, C. UML for Java(TM) Programmers. Ed. Robert C. Martin Series,
Pearson. 2003.
7. Grady Booch, James. Rumbaugh E., Greg Perry. Aprendiendo Principios de
Programación en 24 horas. Ed. Prentice Hall.
8. Sintes, Anthony. Aprendiendo Programación Orientada a Objetos en 21 Lecciones
Avanzadas. Ed. Pearson Educación, 2002.
Fechas de Exámenes
Examen Fecha Unidades
1er
2º.
3er
2ª Oportunidad
Calificación Final
Criterios de evaluación y acreditación
Exámenes 60%
Productos de Aprendizaje 40%
Otras Observaciones:
Personificador
Hora de entrada
Asistencia a clase
2ª oportunidad
Revisión equitativa
4
I. Fundamentos de programación orientada a objetos.
El paradigma orientado a objetos nació en 1969 de la mano del
doctor noruego que intentando escribir un programa que
describiera el movimiento de los barcos a través de un fiordo,
descubrió que era muy difícil simular las mareas, los movimiento
de los barcos, y las formas de las líneas costeras con los métodos
de programación existentes en ese momento. Además descubrió
que los elementos del entorno que trataba de modelar (Barcos,
Mareas y Líneas de la costa de los fiordos) así como las acciones
de cada elemento eran mas fácil de manejar utilizando otro
modelo, es aquí donde surge la Programación Orientada a
Objetos (OOP de sus siglas en ingles).
I.1. Evolución de la programación
La evolución de la programación se puede sintetizar en tres modelos o paradigmas Un
paradigma es una forma establecida de pensar acerca de cómo hacer algo. En el libro ―La
Revolución Científica Estructural‖ de Thomas Kuhn describe los paradigmas como un
conjunto de teorías, estándares y métodos que juntos representa un medio de
organización de conocimiento, es decir un medio de visualizar el mundo.
Los tres modelos o paradigmas de la evolución de la programación son:
La programación mediante procedimientos (procedural o modular)
La programación estructurada
La programación orientada a objetos
Programación Procedural o Modular
Los programas se dividen módulos (partes independientes), cada una de las cuales
ejecuta una única actividad o tarea y se codifican independientemente uno de otro. Cada
uno de estos módulos se analiza, codifica y pone a punto por separado.
5
Cada programa contiene un modulo denominado programa principal (por ejemplo en el
lenguaje c se llama main al igual que en Java) que controla todo que sucede,
transfiriendo el control a los submódulos (subprogramas o procedimientos) y estos al
terminar transfieren el control a modulo principal. Si la tarea asignada a cada submodulo
es demasiado compleja, este podrá dividirse en otros submódulos más pequeños. Estas
tares pueden se procesos de entrada, salida, manipulación de datos, control de otros
módulos o alguna combinación de estas.
Programación Estructurada
Se refiere a un conjunto de técnicas que han ido evolucionando desde los primeros
trabajos de Edgar Dijkstra. Esta técnica aumenta la productividad del programa
reduciendo el tiempo para escribir, verificar, depurar y mantener los programas. La
programación estructurada utiliza un número limitado de estructuras de control que
minimiza la complejidad de los problemas y, por consiguiente reduce los errores.
El conjunto de técnicas que incorpora la programación estructurada son:
Diseño descendente (TopDown)
Recursos Abstractos
Estructuras básicas
Diseño descendente (TopDown)
Es el proceso mediante el cual un problema se descompone en una serie de niveles o
pasos sucesivos de refinamiento. Para establecer un refinamiento pasamos de qué hace
a cómo lo hace.
Raíz
Modulo 1
Modulo 1.1
Modulo 1.2
Modulo 2
Modulo 2.1
Modulo 2.2
Modulo 2.2.1
Modulo 2.2.2
Modulo 3
Modulo 3.1
Modulo 4
Modulo 4.1
Modulo 4.2
6
¿Qué hace?
¿Cómo lo hace?
Diseño descendente
Recursos Abstractos
La abstracción es el proceso de extraer las propiedades relevantes de un objeto al tiempo
que se ignora los detalles no esenciales. Las propiedades extraídas definen una vista del
objeto. En esencia la abstracción supone la capacidad de encapsular y aislar la
información del diseño.
Según Dijkstra, la abstracción descompone un programa en términos de recursos
abstractos, es decir, descompone una acción compleja en una serie de acciones más
simples, capaces de ser implementadas en una computadora.
Estructuras básicas
En mayo de 1966 Böhm y Jacopini demostraron que un programa puede ser escrito
utilizando solamente tres tipos de estructura de control:
7
Secuenciales
Selectivas
Repetitivas
Secuenciales
La estructura secuencial es aquella en la que una acción (instrucción) sigue a otra en
secuencia.
Diagrama de Flujo Diagrama NassiSchneiderman
(NS) Pseudocódigo
Inicio Acción 1 Acción 2 … Acción n
Fin
Selectivas
Diagrama de Flujo
Acción 1
Acción 2
...
Acción n
Inicio
Fin
Inicio
Acción 1
Acción 2
...
Acción n
Fin
Condición
Acción 1
Verdadero Falso
8
Diagrama NassiSchneiderman (NS)
Pseudocódigo
Si Condición
Acción 1 Fin Si
Diagrama de Flujo
Diagrama NassiSchneiderman (NS)
Acción 1
Condición
FalsoVerdadero
Condición
Acción 1
Verdadero Falso
Acción 2
Acción 1
Condición
FalsoVerdadero
Acción 2
9
Pseudocódigo
Si Condición
Acción 1 En otro caso
Acción 2 Fin Si
Repetitivas
Diagrama de Flujo
For/Next
While/Mientras
Repeat/Repite
Diagrama NassiSchneiderman (NS)
For/Next
While/Mientras
Condición
Inc/Dec
Inicio
Proceso
Condición
Proceso Verdadero
Falso
Condición
Proceso
Verdadero
Falso
Inc/Dec
Inicio
Proceso
While Condición
Proceso
10
Repeat/Repite
Pseudocódigo
For/Next
Para I = VI Hasta VF Proceso
Fin Para
While/Mientras
Mientras Condición Proceso
Fin Mientras
Repeat/Repite Repite
Proceso Hasta Condición
I.2. Conceptos fundamentales de la Programación Orientada a Objetos
La programación orientada a objetos, tal vez el paradigma de programación más utilizado
en el mundo del desarrollo de software y de la ingeniería de software del siglo XXI, trae un
nuevo enfoque a los retos que se plantean en la programación estructurada cuando los
problemas a resolver son complejos. Al contrario que la programación procedimental que
enfatiza en los algoritmos, la POO enfatiza en los datos. En lugar de intentar ajustar un
problema al enfoque procedimental de un lenguaje, POO intenta ajustar el lenguaje al
problema. La idea es diseñar formatos de datos que se correspondan con las
características esenciales de un problema.
La idea fundamental de los lenguajes orientados a objetos es combinar en una única
unidad o módulo, tanto los datos como las funciones que operan sobre esos datos. Tal
Repeat Condición
Proceso
11
unidad se llama un objeto. Las funciones de un objeto se llaman funciones miembro en o
métodos y son el único medio para acceder a sus datos. Los datos de un objeto, se
conocen también como atributos o variables de instancia. Si se desea leer datos de un
objeto, se llama a una función miembro del objeto. Se accede a los datos y se devuelve
un valor. No se puede acceder a los datos directamente. Los datos son ocultos, de modo
que están protegidos de alteraciones accidentales. Los datos y las funciones se dice que
están encapsulados en una única entidad. El encapsulamiento de datos y la ocultación de
los datos son términos clave en la descripción de lenguajes orientados a objetos.
Si se desea modificar los datos de un objeto, se conoce exactamente cuáles son las
funciones que interactúan con las funciones miembro del objeto. Ninguna otra función
puede acceder a los datos. Esto simplifica la escritura, depuración y mantenimiento del
programa. Un programa en Java se compone normalmente de un número de objetos que
se comunican unos con otros mediante la llamada a otras funciones miembro. La
organización de un programa en Java se muestra en la siguiente figura. La llamada a una
función miembro de un objeto se denomina enviar un mensaje a otro objeto.
En el paradigma orientado a objetos, el programa se organiza como un conjunto finito de
objetos que contiene datos y operaciones (funciones miembro) que llaman a esos datos y
que se comunican entre sí mediante mensajes.
Datos
Función Miembro(Método)
Función Miembro(Método)
Objeto
Datos
Función Miembro(Método)
Función Miembro(Método)
Objeto
Datos
Función Miembro(Método)
Función Miembro(Método)
Objeto
12
Propiedades fundamentales de la orientación a objetos
Existen diversas características ligadas a la orientación a objetos. Todas las propiedades
que se suelen considerar, no son exclusivas de este paradigma, ya que pueden existir en
otros paradigmas, pero en su conjunto definen claramente los lenguajes orientados a
objetos. Estas propiedades son:
Abstracción (tipos abstractos de datos y clases).
Encapsulado de datos.
Ocultación de datos.
Herencia.
Polimorfismo.
Abstracción
La abstracción es la propiedad de los objetos que consiste en tener en cuenta sólo los
aspectos más importantes desde un punto de vista determinado y no tener en cuenta los
restantes aspectos. El término abstracción que se suele utilizar en programación se
refiere al hecho de diferenciar entre las propiedades externas de una entidad y los
detalles de la composición interna de dicha entidad. Es la abstracción la que permite
ignorar los detalles internos de un dispositivo complejo tal como una computadora, un
automóvil, una lavadora o un horno de microondas, etc., y usarlo como una única unidad
comprensible. Mediante la abstracción se diseñan y fabrican estos sistemas complejos en
primer lugar y, posteriormente, los componentes más pequeños de los cuales están
compuestos. Cada componente representa un nivel de abstracción en el cual el uso del
componente se aísla de los detalles de la composición interna del componente. La
abstracción posee diversos grados denominados niveles de abstracción.
En consecuencia, la abstracción posee diversos grados de complejidad que se
denominan niveles de abstracción que ayudan a estructurar la complejidad intrínseca que
poseen los sistemas del mundo real. En el modelado orientado a objetos de un sistema
esto significa centrarse en qué es y qué hace un objeto y no en cómo debe
implementarse. Durante el proceso de abstracción es cuando se decide qué
características y comportamiento debe tener el modelo.
Aplicando la abstracción se es capaz de construir, analizar y gestionar sistemas de
computadoras complejos y grandes que no se podrían diseñar si se tratara de modelar a
un nivel detallado. En cada nivel de abstracción se visualiza el sistema en términos de
componentes, denominados herramientas abstractas, cuya composición interna se ignora.
Esto nos permite concentrarnos en cómo cada componente interactúa con otros
componentes y centrarnos en la parte del sistema que es más relevante para la tarea a
realizar en lugar de perderse a nivel de detalles menos significativos.
13
En estructuras o registros, las propiedades individuales de los objetos se pueden
almacenar en los miembros. Para los objetos es de interés cómo están organizados sino
también qué se puede hacer con ellos. Es decir, las operaciones que forman la internan
de un objeto son también importantes. El primer concepto en el mundo de la orientación a
objetos nació con los tipos abstractos de datos (TAD). Un tipo abstracto de datos describe
no sólo los atributos de un objeto, sino también su comportamiento (las operaciones).
Esto puede incluir también una descripción de los estados que puede alcanzar un objeto.
Un medio de reducir la complejidad es la abstracción. Las características y los procesos
se reducen a las propiedades esenciales, son resumidas o combinadas entre sí. De este
modo, las características complejas se hacen más manejables.
Encapsulación y ocultación de datos
El encapsulado o encapsulación de datos es el proceso de agrupar datos y operaciones
relacionadas bajo la misma unidad de programación. En el caso de los objetos que
poseen las mismas características y Introducción a la ciencia de la computación y a la
programación 25 comportamiento se agrupan en clases, que no son más que unidades o
módulos de programación que encapsulan datos y operaciones.
La ocultación de datos permite separar el aspecto de un componente, definido por su
interfaz con el exterior, de sus detalles internos de implementación. Los términos
ocultación de la información y encapsulación de datos se suelen utilizar como sinónimos,
pero no siempre es así, y muy al contrario, son términos similares pero distintos. En Java
no es lo mismo, ya los datos internos están protegidos del exterior y no se pueden
acceder a ellos más que desde su propio interior y por tanto, no están ocultos. El acceso
al objeto está restringido sólo a través de una interfaz bien definida.
El diseño de un programa orientado a objetos contiene, al menos, los siguientes pasos:
1. Identificar los objetos del sistema.
2. Agrupar en clases a todos objetos que tengan características y comportamiento
comunes.
3. Identificar los datos y operaciones de cada una de las clases.
4. Identificar las relaciones que pueden existir entre las clases.
En Java, un objeto es un elemento individual con su propia identidad; por ejemplo, un
libro, un automóvil, etc. Una clase puede describir las propiedades genéricas de un
ejecutivo de una empresa (nombre, título, salario, cargo, etc.) mientras que un objeto
representará a un ejecutivo específico (Luis Mackoy, director general). En general, una
clase define qué datos se utilizan para representar un objeto y las operaciones que se
pueden ejecutar sobre esos datos.
14
Cada clase tiene sus propias características y comportamiento; en general, una clase
define los datos que se utilizan y las operaciones que se pueden ejecutar sobre esos
datos. Una clase describe un objeto. En el sentido estricto de programación, una clase es
un tipo de datos. Diferentes variables se pueden crear de este tipo. En programación
orientada a objetos, éstas se llaman instancias. Las instancias son, por consiguiente, la
realización de los objetos descritos en una clase. Estas instancias constan de datos o
atributos descritos en la clase y se pueden manipular con las operaciones definidas dentro
de ellas.
Los términos objeto e instancia se utilizan frecuentemente como sinónimos
(especialmente en Java). Si una variable de tipo Carro se declara, se crea un objeto Carro
(una instancia de la clase Carro).
Las operaciones definidas en los objetos se llaman métodos. Cada operación llamada por
un objeto se interpreta como un mensaje al objeto, que utiliza un método específico para
procesar la operación.
En el diseño de programas orientados a objetos se realiza en primer lugar el diseño de las
clases que representan con precisión aquellas cosas que trata el programa. Por ejemplo,
un programa de dibujo, puede definir clases que representan rectángulos, líneas,
pinceles, colores, etc. Las definiciones de clases, incluyen una descripción de
operaciones permisibles para cada clase, tales como desplazamiento de un círculo o
rotación de una línea. A continuación se prosigue el diseño de un programa utilizando
objetos de las clases.
El diseño de clases fiables y útiles puede ser una tarea difícil. Afortunadamente, los
lenguajes POO facilitan la tarea ya que incorporan clases existentes en su propia
programación. Los fabricantes de software proporcionan numerosas bibliotecas de clases,
incluyendo bibliotecas de clases diseñadas para simplificar la creación de programas para
entornos tales como Windows, Linux, Macintosh o Unix. Uno de los beneficios reales de
Java es que permite la reutilización y adaptación de códigos existentes y ya bien
probados y depurados.
Objetos
El objeto es el centro de la programación orientada a objetos. Un objeto es algo que se
visualiza, se utiliza y juega un rol o papel. Si se programa con enfoque orientado a
objetos, se intentan descubrir e implementar los objetos que juegan un rol en el dominio
del problema y en consecuencia programa. La estructura interna y el comportamiento de
un objetivo, en una primera fase, no tiene prioridad. Es importante que un objeto tal como
un carro o una casa jueguen un rol.
Dependiendo del problema, diferentes aspectos de un aspecto son relevantes. Un carro
puede ser ensamblado de partes tales como un motor, una carrocería, unas puertas o
puede ser descrito utilizando propiedades tales como su velocidad, su kilometraje o su
15
fabricante. Estos atributos indican el objeto. De modo similar una persona, también se
puede ver como un objeto, del cual se disponen de diferentes atributos. Dependiendo de
la definición del problema, esos atributos pueden ser el nombre, apellido, dirección,
número de teléfono, color del cabello, altura, peso, profesión, etc.
Un objeto no necesariamente ha de realizar algo concreto o tangible. Puede ser
totalmente abstracto y también puede describir un proceso. Por ejemplo, un partido de
baloncesto o de rugby puede ser descrito como un objeto. Los atributos de este objeto
pueden ser los jugadores, el entrenador, la puntuación y el tiempo transcurrido de partido.
Cuando se trata de resolver un problema con orientación a objetos, dicho problema no se
descompone en funciones como en programación estructurada tradicional, caso de C,
sino en objetos. El pensar en términos de objetos tiene una gran ventaja: se asocian los
objetos del problema a los objetos del mundo real.
La correspondencia entre objetos de programación y objetos del mundo real es el
resultado eficiente de combinar datos y funciones que manipulan esos datos. Los objetos
resultantes ofrecen una mejor solución al diseño del programa que en el caso de los
lenguajes orientados a procedimientos.
Un objeto se puede definir desde el punto de vista conceptual como una entidad individual
de un sistema y que se caracteriza por un estado y un comportamiento. Desde el punto de
vista de implementación un objeto es una entidad que posee un conjunto de datos y un
conjunto de operaciones (funciones o métodos).
El estado de un objeto viene determinado por los valores que toman sus datos, cuyos
valores pueden tener las restricciones impuestas en la definición del problema. Los datos
se denominan también atributos y componen la estructura del objeto y las operaciones —
también llamadas métodos representan los servicios que proporciona el objeto.
La representación gráfica de un objeto en UML:
Objeto : Clase X
Atributo1 = Expresión…
Método ()…
Objeto : Clase X
(b) Notación reducida de un objeto(a) Notación completa de un objeto
16
Características de la POO
Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las
características siguientes son las más importantes:
Abstracción: denota las características esenciales de un objeto,
donde se capturan sus comportamientos. Cada objeto
en el sistema sirve como modelo de un "agente"
abstracto que puede realizar trabajo, informar y cambiar
su estado, y "comunicarse" con otros objetos en el
sistema sin revelar cómo se implementan estas
características. Los procesos, las funciones o los
métodos pueden también ser abstraídos y cuando lo
están, una variedad de técnicas son requeridas para
ampliar una abstracción. El proceso de abstracción
permite seleccionar las características relevantes dentro
de un conjunto e identificar comportamientos comunes
para definir nuevos tipos de entidades en el mundo real.
La abstracción es clave en el proceso de análisis y
diseño orientado a objetos, ya que mediante ella
podemos llegar a armar un conjunto de clases que
permitan modelar la realidad o el problema que se quiere
atacar.
Encapsulamiento: Significa reunir a todos los elementos que pueden
considerarse pertenecientes a una misma entidad, al
mismo nivel de abstracción. Esto permite aumentar la
cohesión de los componentes del sistema. Algunos
autores confunden este concepto con el principio de
Acadia : GMC
Atributo1 = Expresión…
Método ()…
Marco : Alumno
(d) Objeto Marco de la clase Alumno(c) Objeto Acadia de la clase GMC
17
ocultación, principalmente porque se suelen emplear
conjuntamente.
Principio de ocultación: Cada objeto está aislado del exterior, es un módulo
natural, y cada tipo de objeto expone una interfaz a otros
objetos que específica cómo pueden interactuar con los
objetos de la clase. El aislamiento protege a las
propiedades de un objeto contra su modificación por
quien no tenga derecho a acceder a ellas, solamente los
propios métodos internos del objeto pueden acceder a
su estado. Esto asegura que otros objetos no pueden
cambiar el estado interno de un objeto de maneras
inesperadas, eliminando efectos secundarios e
interacciones inesperadas. Algunos lenguajes relajan
esto, permitiendo un acceso directo a los datos internos
del objeto de una manera controlada y limitando el grado
de abstracción. La aplicación entera se reduce a un
agregado o rompecabezas de objetos.
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. O dicho
de otro modo, las referencias y las colecciones de
objetos pueden contener objetos de diferentes tipos, y la
invocación de un comportamiento en una referencia
producirá el comportamiento correcto para el tipo real del
objeto referenciado. Cuando esto ocurre en "tiempo de
ejecución", esta última característica se llama asignación
tardía o asignación dinámica. Algunos lenguajes
proporcionan medios más estáticos (en "tiempo de
compilación") de polimorfismo, tales como las plantillas y
la sobrecarga de operadores de JAVA.
Herencia: las clases no están aisladas, sino que se relacionan
entre sí, formando una jerarquía de clasificación. Los
objetos heredan las propiedades y el comportamiento de
todas las clases a las que pertenecen. La herencia
organiza y facilita el polimorfismo y el encapsulamiento
permitiendo a los objetos ser definidos y creados como
tipos especializados de objetos preexistentes. Estos
pueden compartir (y extender) su comportamiento sin
tener que volver a implementarlo. Esto suele hacerse
habitualmente agrupando los objetos en clases y estas
18
en árboles o enrejados que reflejan un comportamiento
común. Cuando un objeto hereda de más de una clase
se dice que hay herencia múltiple.
Recolección de basura: la recolección de basura o garbage collector es la
técnica por la cual el entorno de objetos se encarga de
destruir automáticamente, y por tanto desvincular la
memoria asociada, los objetos que hayan quedado sin
ninguna referencia a ellos. Esto significa que el
programador no debe preocuparse por la asignación o
liberación de memoria, ya que el entorno la asignará al
crear un nuevo objeto y la liberará cuando nadie lo esté
usando. En la mayoría de los lenguajes híbridos que se
extendieron para soportar el Paradigma de
Programación Orientada a Objetos como JAVA u Object
Pascal, esta característica no existe y la memoria debe
desasignarse manualmente.
I.3. Lenguajes orientados a objetos
Históricamente el lenguaje Simula (1967) es aceptado como el primer lenguaje que posee
las características principales de un lenguaje orientado a objetos. Fue creado para hacer
programas de simulación, en donde los "objetos" son la representación de la información
más importante. Smalltalk (1972 a 1980) es posiblemente el ejemplo canónico, y con el
que gran parte de la teoría de la programación orientada a objetos se ha desarrollado.
El lenguaje de programación C fue desarrollado por Dennis Ritche de AT&T en los
Laboratorios Bell que se utilizó para escribir y mantener el sistema operativo UNIX (hasta
que apareció C, el sistema operativo UNIX fue desarrollado por Ken Thompson en AT&T
mediante en lenguaje ensamblador o en B). C es un lenguaje de propósito general que se
puede utilizar para escribir cualquier tipo de programa, pero su éxito y popularidad está
especialmente relacionado con el sistema operativo UNIX. (Fue desarrollado como
lenguaje de programación de sistemas, es decir, un lenguaje de programación para
escribir sistemas operativos.
COBOL ALGOL APL PASCAL
GPSS PROLOG
Lenguaje Maquina
1950 1960 1970 1980 2000
Declarativos
Imperativos
Orientados a Objetos
Funcional
FORTRAN BASIC C ADA
SMALLTALK VISUAL BASIC JAVA
C#
LISP LM SCHEMA
1990
C++
19
Entre los lenguajes orientados a objetos se destacan los siguientes:
Ada
JAVA
C#
Clipper
Object Pascal (Delphi)
Gambas
Eiffel
Java
JavaScript
ObjectiveC
R
Perl
PHP
PowerBuilder
Python
Ruby
Smalltalk
VB.NET
Visual FoxPro
Visual Basic
Visual Objects
XBase++
I.4. Relaciones entre clases y objetos
En el Lenguaje Unificado de Modelado (UML, Unifield Modeling Language), una clase es
representada por un rectángulo que posee tres divisiones:
En donde:
La parte superior: Contiene el nombre de la Clase
La intermedia: Contiene los atributos (o variables de instancia) que caracterizan a
la Clase (pueden ser publica (public), privado (prívate), protegido (protected) y por
defecto (amigable).
La parte Inferior: Contiene los métodos u operaciones, los cuales son la forma
como interactúa el objeto con su entorno, que al igual que los atributos contienen
tipo de acceso (publico, privado, protegido y por defecto).
Nombre de la clase
Atributos
Comportamiento
Atributos y Métodos:
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el
grado de comunicación y visibilidad de ellos con el entorno, estos son:
public (+, ): Indica que el atributo será visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
private (-, ): Indica que el atributo sólo será accesible desde dentro de la
clase (sólo sus métodos lo pueden accesar).
protected (#, ): Indica que el atributo no será accesible desde fuera de la
clase, pero si podrá ser accesado por métodos de la clase
además de las subclases que se deriven (herencia).
defecto Si no especifica ningún tipo de acceso, se utiliza el acceso
por defecto, esto significa que la variable es accesible a
todas las clases contenidas en le mismo paquete.
Métodos:
Cada método tiene asociado un tipo que se utiliza para controlar el acceso al método.
Entre estos se encuentra:
public (+, ): Indica que el método será visible tanto dentro como fuera de
la clase, es decir, es accsesible desde todos lados.
private (-, ): Indica que el método sólo será accesible desde dentro de la
clase (sólo otros métodos de la clase lo pueden accesar).
protected (#, ): Indica que el método no será accesible desde fuera de la
clase, pero si podrá ser accesado por métodos de la clase
además de métodos de las subclases que se deriven
(herencia).
defecto Si no especifica ningún tipo de acceso, se utiliza el acceso
por defecto, esto significa que el método es accesible a
todas las clases contenidas en le mismo paquete.
Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden
interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relación y éstas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
número fijo: m (m denota el número).
Ejemplo:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.
Producto de Aprendizaje 1:
De los siguientes conceptos seleccione uno en base al Número de Lista, desarróllelo
como clase, expóngalo, seleccione 3 que se puedan relaciona y junto a los temas que no
sean seleccionados desarróllelo y preséntelo por escrito.
1 Actor 21 Empleado 41 Notebook
2 Avión 22 EquipoSonido 42 Pantalón
3 Blusa 23 Escuela 43 Periódico
4 Camión 24 Estadio 44 Persona
5 Camioneta 25 Estudiante 45 Pickup
6 Camisa 26 Fabrica 46 Pluma
7 Carro 27 Farmacia 47 Portafolio
8 Casa 28 Fraccionamiento 48 Profesionista
9 Catedrático 29 Hospital 49 ProgramaRadio
10 CertificadoMédico 30 Ingeniero 50 ProgramaTV
11 CertificadoCalifiaciones 31 Lápiz 51 Revista
12 Coche 32 Laptop 52 Supermercado
13 Computadora 33 Libro 53 Teléfono
14 Cuaderno 34 Licenciado 54 Terreno
15 Cuenta 35 Maestro 55 Tienda
16 CuentaAhorros 36 Mascota 56 Universidad
17 CuentaBancaria 37 Medico 57 Vehículo
18 CuentaCrédito 38 Mochila 58 Ventana
19 Director 39 Modulo 59 Vestido
20 Doctor 40 Museo 60 Zapato
Cada clase deberá tener los siguientes términos:
Nombre de clase
Atributos y Descripción
Comportamiento y Descripción
Para las tres clases establezca:
Relación de las Clases
I.5. Papel de clases y objetos en el análisis y el diseño
Una casa bien diseñada es algo más que un montón de paredes, puestas juntas para
sostener en alto un techo que proteja de las inclemencias del tiempo. Cuando una
persona discute con un arquitecto el diseño de una casa para su familia, se debe tomar en
cuenta el numero de integrantes, las edades y gustos de cada uno, además de la
ubicación de los dormitorios, así como la cocina o la distribución de los baños, si tendrán
cochera o jardín, etc.. ¿Qué pasaría si se construye una casa sin baños? o ¿sin cocina? o
¿sin techo?, o ¿sin cochera? o ¿Sin jardín? que se tendría que hacer en cada uno de
estos casos.
Por lo tanto el papel de las clases y los objetos en el análisis y diseño es muy importante,
porque el diseño de clases en donde falten características (atributos) o comportamiento
(métodos) afectara en el funcionamiento y desempeño de los objetos. ¿Que pasaría si se
diseña una clase que represente una casa y esta no tuviese techo?, al crear objetos de
esa clases tendrá este defecto.
La solución para este caso es parchar la clase con otra clase que tenga el techo, pero la
mejor alternativa es regresar a la fase de análisis y diseño, y corregir la clase poniéndole
techo.