TECNOLÓGICO NACIONAL DE MÉXICO

Instituto Tecnológico de Zacatecas

Materia: Programación Orientada a Objetos

Maestro: Luis Eduardo Torres Hernández

Alumno: Luis Alfredo Castañeda Fernández

Fecha: 18/03/2022

Grupo: 2°A
 Índice

1. Paradigma de la programación orientado a objetos ....................................... 3

1.1. Clases ...................................................................................................... 3

1.2. Objetos .................................................................................................... 4

1.3. Abstracción .............................................................................................. 4

1.4. Modularidad ............................................................................................. 4

1.5. Encapsulación.......................................................................................... 5

1.6. Herencia .................................................................................................. 6

1.7. Polimorfismo ............................................................................................ 6

2. Modelado unificado UML ................................................................................ 7

2.1. Diagramas de clases ............................................................................... 7

2.2. Diagrama de secuencia ........................................................................... 8

2.3. Diagrama de estados ............................................................................... 8

2.4. Diagrama de actividad ............................................................................. 9

2.5. Diagrama entidad – relación .................................................................... 9

3. Conclusiones ................................................................................................ 10

4. Referencias .................................................................................................. 11

2
 Programación Orientada a Objetos

1. Paradigma de la programación orientado a objetos

Es un paradigma de programación que define los programas en términos de “clases

de objetos”, objetos que son entidades que combinan estado (propiedades o datos),
comportamiento (procedimientos o métodos) e identidad (propiedad del objeto que lo
diferencia del resto).

Las ventajas de un lenguaje orientado a objetos son:

• Fomenta la reutilización y extensión del código.

• Permite crear sistemas más complejos.
• Relacionar el sistema al mundo real.
• Facilita la creación de programas visuales
• Construcción de prototipos
• Agiliza el desarrollo de software
• Facilita el trabajo en equipo
• Facilita el mantenimiento del software

1.1. Clases

Las clases son uno de los principales componentes de un lenguaje de

programación, pues en ellas ocurren todos los procesos lógicos requeridos para un
sistema, en si podemos definirlas como estructuras que representan objetos del mundo
real, tomando como objetos a personas, lugares o cosas, en general las clases poseen
propiedades, comportamientos y relaciones con otras clases del sistema.

Nombre: Contiene el nombre de la clase.

Atributos: Representan las propiedades que caracterizan la clase.

Métodos: Representan el comportamiento u operaciones, la forma como interactúa

la clase con su entorno.

3
 1.2. Objetos

Los objetos representan una entidad concreta o abstracta del mundo real, en
programación básicamente se le conoce como la instancia de una clase en si es lo que
da el sentido a estas.

Al igual que las clases se componen de tres partes fundamentales:

Estado: Representa los atributos o características con valores concretos del objeto.

Comportamiento: Se define por los métodos u operaciones que se pueden realizar

con él.

Identidad: Es la propiedad única que representa al objeto y lo diferencia del resto.

Para que un objeto aproveche al máximo este paradigma de programación, debe

seguir los cuatro principios de la programación orientada a objetos: encapsulación,
abstracción, herencia y polimorfismo.

1.3. Abstracción

La abstracción es un proceso de interpretación y diseño que implica reconocer y

enfocarse en las características importantes de una situación u objeto, y filtrar o ignorar
todas las particularidades no esenciales.

Dejar a un lado los detalles de un objeto y definir las características específicas de

éste, aquellas que lo distingan de los demás tipos de objetos.

Hay que centrarse en lo que es y lo que hace un objeto, antes de decidir cómo
debería ser implementado.

Se hace énfasis en el qué hace más que en el cómo lo hace.

1.4. Modularidad

La modularidad consiste en dividir un programa en módulos que puedan compilarse

por separado, sin embargo, tendrá conexiones con otros módulos.

La modularidad también tiene principios y son los siguientes:

4
 Capacidad de descomponer un sistema complejo: Este procedimiento descompone
un sistema en subprogramas (recuerda llamarlos módulos), el problema en general lo
divides en problemas más pequeños.

Capacidad de componer a través de sus módulos: Indica la posibilidad de componer

el programa desde los problemas más pequeños completando y resolviendo el
problema en general, particularmente cuando se crea software se utilizan algunos
módulos existentes para poder formar lo que nos solicitan, estos módulos que se
integran a la aplicación deben de ser diseñados para ser reusables.

Comprensión de sistema en partes: El poder tener cada parte separada nos ayuda
a la comprensión del código y del sistema, también a la modificación de este,
recordemos que si el sistema necesita modificaciones y no hemos trabajado con
módulos definitivamente eso será un caos.

1.5. Encapsulación

La encapsulación no es un concepto propio de la programación orientada a objetos,

pero es fundamental, los objetos son la abstracción que proporciona la encapsulación.

La encapsulación consiste en hacer que los datos sean modificados únicamente por
las funciones destinadas a tal efecto. La encapsulación permite que los datos
conserven un estado válido y consistente, trata de evitar que cualquier código pueda
modificar una estructura de datos con el consiguiente problema de generación de
inconsistencias.

Se denomina encapsulación porque los datos y sus estructuras de datos no están

accesibles de forma directa, sino que para acceder a los datos o manipularlos se ha
de realizar a través de las funciones asociadas, los datos están encapsulados.

Las distintas formas de encapsular son:

Abierto: Hace que el miembro de la clase pueda ser accedido desde el exterior de
la clase cualquier parte del programa.

Protegido: Solo es accesible desde la clase y las clases que heredan (a cualquier
nivel).

5
 Cerrado: Solo es accesible desde las clases

1.6. Herencia

Decir que una clase hereda de otra quiere decir que esa clase obtiene los mismos
métodos y propiedades de la otra clase. Permitiendo de esta forma añadir a las
características heredadas las suyas propias.

Existen dos tipos de herencia:

1. Herencia por especialización

2. Herencia por generalización

En realidad, la herencia es la misma, esta es una diferenciación puramente

conceptual sobre la forma en que se ha llegado a ella.

Una herencia por especialización es la que se realiza cuando necesitamos crear

una clase nueva que disponga de las mismas características que otra pero que le
añada funcionalidades. Por ejemplo, si tenemos una clase que genera un botón simple,
y necesitamos crear un botón que sea igual que el anterior pero que además añada
un efecto al ser clicado.

La herencia por generalización es la que realizamos cuando tenemos muchas

clases que comparten unas mismas funcionalidades y por homogeneizar las partes
comunes se decide crear una clase que implemente toda esa parte común y se dejan
solo las partes especificas en cada clase.

1.7. Polimorfismo

El polimorfismo es la habilidad que poseen los objetos para reaccionar de modo

diferente ante los mismos mensajes. Se refiere a la posibilidad de definir múltiples
clases con funcionalidad diferente, pero con métodos o propiedades denominados de
forma idéntica, que pueden utilizarse de manera intercambiable mediante código
cliente en tiempo de ejecución.

En algunos lenguajes, el término polimorfismo es también conocido como

‘Sobrecarga de parámetros’ ya que las características de los objetos permiten aceptar

6
distintos parámetros para un mismo método (diferentes implementaciones)
generalmente con comportamientos distintos e independientes para cada una de ellas.

2. Modelado unificado UML

2.1. Diagramas de clases

El diagrama de clases es uno de los diagramas incluidos en UML 2.5 clasificado

dentro de los diagramas de estructura y, como tal, se utiliza para representar los
elementos que componen un sistema de información desde un punto de vista estático.

Es importante destacar que, por esta misma razón, este diagrama no incluye la
forma en la que se comportan a lo largo de la ejecución los distintos elementos, esa
función puede ser representada a través de un diagrama de comportamiento, como
por ejemplo un diagrama de secuencia o un diagrama de casos de uso.

El diagrama de clases es un diagrama puramente orientado al modelo de

programación orientado a objetos, ya que define las clases que se utilizarán cuando
se pase a la fase de construcción y la manera en que se relacionan las mismas. Se
podría equiparar, salvando las distancias, al famoso diagrama de modelo Entidad-
Relación (E/R), no recogido en UML, tiene una utilidad similar: la representación de
datos y su interacción. Ambos diagramas muestran el modelo lógico de los datos de
un sistema.

7
 2.2. Diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama de interacción contenido en UML

2.5. Su objetivo es representar el intercambio de mensajes entre los distintos objetos
del sistema para cumplir con una funcionalidad. Define, por tanto, el comportamiento
dinámico del sistema de información.

Normalmente es utilizado para definir como se realiza un caso de uso por lo que es
comúnmente utilizado junto al diagrama de casos de uso. También se suele construir
para comprender mejor el diagrama de clases, ya que el diagrama de secuencia
muestra como objetos de esas clases interactúan haciendo intercambio de mensajes.

2.3. Diagrama de estados

El diagrama de máquina de estados o, más comúnmente llamado, el diagrama de

estados es un diagrama de comportamiento usado para especificar el comportamiento
de una parte del sistema diseñado a través de transiciones de estados finitos. El
formalismo de esta diagramado utilizado en UML es una variante basada en objetos
de los diagramas de estado de Harel. Es utilizado para mostrar los estados por los que
pasa un componente de un sistema de información.

El comportamiento se modela utilizando una serie de nodos que representan

estados y que están conectados a través de las llamadas transiciones. Estas
transiciones se activan a través de eventos.

8
 2.4. Diagrama de actividad

El diagrama de actividades es un diagrama UML de comportamiento que muestra

el flujo de control o el flujo de objetos, con especial énfasis en la secuencia y las
condiciones de este flujo.

Los diagramas de actividades muestran una secuencia de acciones, un flujo de

trabajo que va desde un punto inicial hasta un punto final.

2.5. Diagrama entidad – relación

Un diagrama entidad-relación, también conocido como modelo entidad relación o

ERD, es un tipo de diagrama de flujo que ilustra cómo las "entidades", como personas,
objetos o conceptos, se relacionan entre sí dentro de un sistema. Los diagramas ER
se usan a menudo para diseñar o depurar bases de datos relacionales en los campos

9
de ingeniería de software, sistemas de información empresarial, educación e
investigación.

También conocidos como los ERD o modelos ER, emplean un conjunto definido de
símbolos, tales como rectángulos, diamantes, óvalos y líneas de conexión para
representar la interconexión de entidades, relaciones y sus atributos. Son un reflejo de
la estructura gramatical y emplean entidades como sustantivos y relaciones como
verbos.

3. Conclusiones

La programación orientada a objetos es actualmente el paradigma que más se

utiliza para diseñar aplicaciones y programas informáticos. Son muchas sus ventajas,

principalmente cuando necesitas resolver desafíos de programación complejos.

Permite una mejor estructura de datos y reutilización del código, lo que facilita el ahorro

de tiempo a largo plazo. Eso sí, para ello se requiere pensar bien en la estructura del

programa, planificar al comienzo de la codificación, así como analizar los requisitos en

clases simples y reutilizables que se pueden usar para diseñar instancias de objetos.

10
4. Referencias

Programación orientada a objetos. (s. f.). IBM. Recuperado 18 de marzo de 2022,

de https://www.ibm.com/docs/es/spss-modeler/SaaS?topic=language-object-oriented-

programming

Programación orientada a objetos, OOP. (2021, 17 mayo). ComputerWeekly.

Recuperado 18 de marzo de 2022, de

https://www.computerweekly.com/es/definicion/Programacion-orientada-a-objetos-

OOP

Henao., C. (s. f.). Conceptos Básicos de Programación Orientada a Objetos.

CoDejaVu. Recuperado 18 de marzo de 2022, de

http://codejavu.blogspot.com/2013/05/conceptos-de-programacion-orientada.html

Los cuatro pilares de la programación orientada a objetos. (2020, 28 noviembre).

ICHI.PRO. Recuperado 18 de marzo de 2022, de https://ichi.pro/es/los-cuatro-pilares-

de-la-programacion-orientada-a-objetos-154930785235691

Todos los diagramas UML. Teoría y ejemplos. (s. f.). DiagramasUML. Recuperado

18 de marzo de 2022, de https://diagramasuml.com

11