Programacion orientada a objetos Unidad 1-intro al paradigma poo

TECNOLÓGICO NACIONAL DE MÉXICO
Instituto Tecnológico Superior de Guasave
Ingeniería en Sistemas Computacionales
Unidad 1: Introducción al Paradigma de la POO
PROGRAMACIÓN ORIENTADA A OBJETOS

Unidad 1
Competencia de la unidad:
Comprende y aplica los conceptos del paradigma de
programación orientada a objetos para modelar situaciones de
la vida real.

¿Qué es un objeto?
• Un objeto es una entidad física o abstracta que tiene un
comportamiento antes ciertos estímulos, tanto externos como
de otros objetos específicos que se encuentran dentro del
sistema.

¿Qué se puede considerar como objeto?
- Persona
- Equipo Hardware
- Materiales
- Información
- Software
- Procesos
- Procedimientos

Objeto Físico: Horno
Operaciones asociadas:
• Encendido
• Apagado

Objeto Abstracto: Cola
Operaciones asociadas:
• Agregar elemento
• Eliminar elemento
• Verificar si está vacía
• Verificar si está llena
• Primer elemento de la cola
• Siguiente elemento de la cola

Práctica:
Del objeto “Vehículo de Motor” mencione cuales son sus operaciones
asociadas e identifique al menos 3 tipos:

Identidad de un objeto
• Cada objeto tiene su propia identidad que lo distingue de los demás
objetos. En otras palabras, dos objetos distintos no son iguales
aunque todos los valores de sus atributos sean idénticos.

• La programación orientada a objetos o POO (OOP según sus siglas en
inglés) es un paradigma de programación que usa objetos y sus
interacciones, para diseñar aplicaciones y programas informáticos.
• Está basado en varias técnicas incluyendo:
• Herencia
• Abstracción
• Polimorfismo y
• Encapsulamiento

Clases y Objetos
• Una clase es básicamente un plano para un tipo de datos personalizado.
Cuando se define una clase, se utiliza cargándola en la memoria.
• Una clase que se ha cargado en la memoria se denomina objeto o
instancia.

Las características principales de los objetos
son:
• Encapsulación: combinación en una sola
estructura los datos, procedimientos y
funciones que los manipulan para formar un
nuevo tipo - el objeto.
• Permite que la información de un objeto
permanezca oculta para el mundo exterior.

Práctica
Del objeto “vehículo de motor” menciona los datos, procedimientos y
funciones que lo conforman:

• Herencia: Definición de un objeto y luego uso del mismo para construir una
jerarquía de objetos descendientes, con cada descendiente heredando
acceso a todo el código y datos del ancestro.

Práctica
Del objeto “vehículo de motor” menciona al menos 3 tipos heredados y de
cada tipo al menos 2 subtipos heredados:

• Polimorfismo: Dada una acción un nombre que es compartido hacia
arriba y abajo en una jerarquía de objetos, con cada objeto en la jerarquía
implementando la acción de una manera apropiada a sí mismo.

Práctica
De los 3 tipos de vehículos de motor que ya mencionaste describe como
realizan sus acciones básicas cada uno, diferenciándolos de los demás tipos:

• Abstracción: Es la encargada desde
el punto de vista de la
programación orientada a objetos
expresa las características
esenciales de un objeto, las cuales
distinguen al objeto de los demás.
Además de distinguir entre los
objetos provee límites
conceptuales.
• Entonces se puede decir que la
encapsulación separa las
características esenciales de las no
esenciales dentro de un objeto.

Aplicando
abstracción
Objetos polígonos
Clase polígono
Atributos
Vértices
Colordelborde
Colorde relleno
Operaciones
Dibujar
Borrar
Mover

Práctica
De los 3 tipos de vehículos de motor que ya mencionaste describe sus
componentes que son ocultados al exterior y por lo tanto resultan abstractos:

Tarea 1:
• Dibuje una jerarquía de vehículos para pasajeros (bicicleta, motocicleta,
automóvil, etc.)
• Comience con el diseño de un mapa conceptual de la Programación
Orientada a Objetos.

Modelado de Clases y Objetos con UML

• El lenguaje UML (en inglés, Unified Modeling Language) es un
lenguaje para la:
• Especificación,
• Visualización,
• Construcción, y
• Documentación de las partes de un sistema de software.
• Consiste en una colección de las mejores prácticas de ingeniería que
mostraron ser exitosas en el modelado de sistemas complejos.

• Fue creado en 1996, por el Object Mangement Group (www.omg.org) con
sucesivas modificaciones y agregados para permitir mayor funcionalidad,
gracias al aporte y la participación de empresas como IBM, Hewlett
Packard, Microsoft, Unisys y Oracle, entre otras.
• Es un lenguaje predominantemente visual, que consiste de varios
diagramas, cada uno modelando un parte esencial del sistema a construir.

DIAGRAMA DE CLASES
• Las clases son dibujadas con un rectángulo, dividido en tres partes:
• El nombre de la clase,
• Los atributos, y
• Las operaciones correspondientes.
• Puede agregarse también una división en donde se especifican las
responsabilidades de esa clase.

Representación de una clase

• El nombre de la clase debe ser lo menos ambiguo posible, usualmente
un sustantivo.
• Atributos: Los atributos describen las características de los objetos.
• Poseen un tipo, que nos indica qué clase de atributo es. Si bien existen
ciertos tipos primitivos, como enteros, booleanos y reales, cualquier tipo
puede ser usado, incluso otras clases.

• La restricción más importante es que los atributos son visibles
únicamente por la clase que los contiene.
• La sintaxis de declaración es la siguiente:
<nombre>:<tipo> < = valor_inicial >
• El dato valor_inicial es opcional y permite inicializar los atributos
directamente en la declaración.

• Las operaciones son utilizadas para manipular los atributos o realizar
consultas.
• La sintaxis para describir una operación es la siguiente:
<nombre_operación>(<parámetros>):<tipo_resultado>

• A diferencia de los atributos, las operaciones pueden tener diferente
visibilidad hacia otras clases, la cual se denota entre llaves a la izquierda de
la declaración.
• Todas las operaciones están agrupadas de acuerdo a los estereotipos
• <<comando>>,
• <<consulta>> o
• <<constructor>> de acuerdo a su función en la clase.

• Las responsabilidades son las obligaciones de una clase y son definidas
por el usuario.
• Si bien, existe un compartimiento dentro de la clase para la
especificación de las responsabilidades, éstas son de carácter opcional.

• Dependiendo del nivel de detalle que queremos alcanzar en el modelo, se
pueden obviar algunas de las divisiones del gráfico de clases.
• Esto permite simplificar el diagrama completo, de acuerdo al nivel de
abstracción necesario. Puede utilizarse, por ejemplo

Práctica:
• Realice representación de clase de una persona con sus atributos básicos y
operaciones (al menos 3 de cada uno)

Notas en el diagrama:
• A los gráficos de clases se les puede agregar notas o comentarios sobre
algún aspecto interesante de la clase.
• Estas notas pueden incluir observaciones sobre la clase, alguna
restricción de uso, e incluso el pseudo-código de algunas operaciones.
• Se grafican por medio de un rectángulo con la esquina superior derecha
plegada, como si fuera una hoja, y se une con una línea al elemento de la
clase al cual corresponde la nota.

Representación de las Notas

Las relaciones más importantes entre clases que utilizaremos son:
• Asociaciones,
• Agregaciones,
• Dependencia, y
• Generalización.

Asociación (Conexión entre clases)
• Una asociación es una conexión entre clases. Significa que los objetos de
dos clases tendrán un vínculo bidireccional en común, el cual puede
interpretarse como “para cada X existe un Y”.
• Se representa por medio de una línea continua entre dos clases.

Multiplicidad
• Se utiliza multiplicidad cuando no necesariamente los vínculos entre
objetos son de uno a uno.
• Se especifica en cada extremo del vínculo, a través de un rango, cuántos
objetos pueden estar vinculados.

• El diagrama anterior indica que cada programador tendrá varias
computadoras (posiblemente ninguna), y que cada computadora será usada
por al menos un programador.

Rangos
• Algunos ejemplos de rangos son los siguientes:
Cuando no se especifica ningún rango, se asume el valor uno (1) por defecto.
Puede agregarse una flecha a la línea, indicando la dirección del vínculo:

Agregaciones (Posee/contiene)
• Agregación es un caso especial de asociación. Indica que una o más clases
(clases componentes) forman parte de otra clase (clase agregada).
• Se denota con un rombo en uno de los extremos del vínculo, aquél que
corresponde a la clase agregada.
• Puede interpretarse como “posee (o contiene) un”.

• En la agregación, la multiplicidad de la clase agregada debe ser cero o uno
(0..1), pero en las clases que conforman las partes puede ser un rango
cualquiera.
Aquí, el diagrama indica que una ventana de Windows puede contener
uno o más botones.

• Otra posible forma de representar la agregación entre clases es incluir el
gráfico de una clase (el agregado) dentro del gráfico de otra. Por ejemplo;

• Si el agregado requiere especificar multiplicidad, escribimos el rango
correspondiente en la esquina superior derecha de la clase.

Práctica: Agregaciones (Posee/contiene)
• Identifique en un automóvil al menos 3 agregaciones que no sean las ya
mencionadas.

Dependencia (relación de uso)
• Es una relación de uso entre dos clases (una usa a la otra). Esta relación es
la más básica entre clases y comparada con los demás tipos de relación, la
mas débil.
Representación UML
• Se representa con una flecha discontinua que parte desde una clase y
apunta a otra. El sentido de la flecha nos indica quien usa a quien.

Práctica: Dependencia (relación de uso)
• Identifique en una computadora que relación de dependencia tiene con
otros objetos.

Generalizaciones (Herencia/Especificación)
• La generalización es la relación entre una clase más general y un clase más
específica.
• La clase más especifica (denominada subclase) es consistente con la clase
más general (denominada superclase), y contiene información adicional.
• La generalización permite la especialización de las clases, es decir, en este
caso la superclase hereda todas sus características a la subclase.

Generalizaciones Se denota con un triángulo en el extremo del vínculo
correspondiente al elemento más general. La relación puede interpretarse
informalmente como “es un”.
• El diagrama indica que un taxi es una clase particular de autos, con una
patente (placa) extra y un código utilizado por la empresa. Son heredados
de la clase Auto todos los demás atributos, como la patente oficial, el
modelo, el motor, etc.

• Cuando una clase posee más de una subclase, pueden organizarse en
forma de árbol de la siguiente manera:

Ejemplo de Generalizaciones
• Identifique de un objeto avión al menos 3 generalizaciones con
sus respectivos atributos.

Ejemplo:

Ejemplo de diagrama de clases:

Evidencia de aprendizaje 1:
• Genera la clase vehículo con todos sus atributos, acciones y hereda al menos
3 tipos de vehículos.
• A cada objeto heredado genera sus asociaciones, agregaciones, rangos,
multiplicidad, generalizaciones, etc. (entre 1 y 3 de cada una).
• Entregar trabajo individual con el diagrama completo en papel.

Instituto Tecnológico Superior de Guasave
RÚBRICA PARA EVIDENCIAS GRÁFICAS
Carrera:
Asignatura:
Tema:
Alumno/equipo:
DIMENSIONES O CRITERIOS A
EVALUAR
% POR
CRITERIO
%
OBTENIDO
OBSERVACIONES (anotar razones por las que no se alcanzó el porcentaje más
alto)
REDACCIÓN Y ORTOGRAFÍA 20%
Utiliza las reglas ortográficas básicas. 10
Claridad y continuidad del contenido. 10
FORMATO Y CONTENIDO 80%
Utiliza los elementos gráficos vistos en
clase
15
Ordena los elementos gráficos de manera
visual y entendible
15
Traza las relaciones de los gráficos
correctamente
10
Los elementos gráficos son fáciles de
interpretar
10
Se identifican claramente la idea principal
y las ideas secundarias
15
Se identifican claramente las jerarquías
existentes
15
Total de Puntos Obtenidos

Programacion orientada a objetos Unidad 1-intro al paradigma poo

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Programacion orientada a objetos Unidad 1-intro al paradigma poo

Similar a Programacion orientada a objetos Unidad 1-intro al paradigma poo (20)

Más de José Antonio Sandoval Acosta

Más de José Antonio Sandoval Acosta (20)

Último

Último (20)

Programacion orientada a objetos Unidad 1-intro al paradigma poo