SlideShare una empresa de Scribd logo
1 de 67
Descargar para leer sin conexión
Tecnología Orientada a
Objetos
Maestría en Desarrollo de Software
ISC. Erivan Martínez Ovando
Introducción
La Tecnología Orientada a Objetos se apoya
en fundamentos de la ingeniería, cuyos
elementos reciben el nombre global de
modelo de objetos, el cual abarca los
principios de abstracción, encapsulación,
modularidad, jerarquía, concurrencia y
persistencia.
Fundamentos de la TOO
• SIMULACIÓN
• ENCAPSULAMIENTO
• MODULARIDAD
• OCULTAMIENTO
• REUTILIZACIÓN
Introducción
• La TOO es un nuevo enfoque sobre la manera
de organizar las diferentes piezas que
conforman un sistema de información.
• Términos
POO
AOO
DOO
BDOO
Introducción
• El concepto objeto y las operaciones relacionadas no
son nuevos en la programación, sin embargo el DOO es
poco explorado.
• En los inicios de la computación el nivel de abstracción
que se utilizaba era muy bajo, los lenguajes
ensambladores permitían el uso de instrucciones
maquina
Introducción
• El siguiente nivel de abstracción se dio con la
aparición de los lenguajes de alto nivel, los
cuales permitieron el uso de estructuras de
datos y de control predefinidas.
• La abstracción y el ocultamiento de
información surgió en los años 70´s lo que dio
lugar a métodos de diseño conducidos por los
datos
Antecedentes
 La TOO data de los años 60.
 En 1961 Krystin Nygaard crea Simula I.
 En 1967 se creó Simula 67 y con ello nace por
primera vez los conceptos de Clase, objetos y
herencia.
 En 1970 se crea SmallTalk dirigido por Allan
Kay con interfaz gráfica y herramientas de
desarrollo integradas.
 Visualizadores de Clases
 Inspeccionadores de código
Antecedentes
• Énfasis en la abstracción de datos y los
problemas del mundo se representaban como
un conjunto de objetos de datos para los que
existían ciertas operaciones
Antecedentes
• El enfoque DOO se base en la abstracción,
ocultamiento de la información y la
modularidad.
• A finales de los 80´s el DOO se usaba en
aplicaciones de software que iban desde las
animaciones graficas hasta las
telecomunicaciones
Antecedentes
• Las técnicas orientadas a objetos permiten que
el software se construya a partir de objetos de
comportamiento especifico
Antecedentes
• En el análisis de sistemas OO requiere estudiar
los objetos en un ambiente, así como los
eventos que interactúan con dichos objetos.
TOO (Perspectiva Histórica)
• Las técnicas OO se unen a otras tecnologías
de software para lograr una correcta
construcción de sistemas OO.
• Case, I case (integrated case)
• Programación visual
• Generadores de código
• Repositorios
• Bases de Datos OO
• Lenguajes no procedimentales
• Bibliotecas de Clase
• Análisis Orientado a Objetos
TOO (Perspectiva Histórica)
Estilos de programación
Estilo de programación Abstracción
• Orientado a Procedimientos - Algoritmos
• Orientados a Objetos - Clases y Objetos
• Orientados a Lógica - Calculo de pred.
• Orientados a Reglas - si...entonces
TOO (Perspectiva Histórica)
Estilos de programación
• Cada estilo de programación es capaz de
resolver cierto tipos de problemas, por lo que
no hay un estilo de programación que sea el
mejor.
• Cada estilo se basa en su propio marco de
referencia conceptual, una actitud mental
diferente.
TOO (Perspectiva Histórica)
• Hoy en día la TOO ya no se aplica solamente
en los lenguajes de programación, además se
aplica en el análisis y el diseño así como en las
bases de datos
TOO perspectiva histórica
• Programación lineal
• Programación estructurada
• Programación Orientada a Objetos
Modelo Orientado a Objetos
• Elementos básicos
• Abstracción
• Encapsulamiento
• Jerarquía
• Tipificación
• Concurrencia
• Persistencia
* Los tres primeros son necesarios para
considerarse OO
Abstracción
• Proceso mental mediante el cual se extraen los
rasgos esenciales de algo con el fin de representarlo
mediante un lenguaje grafico.
• La abstracción depende del contexto mental de
quien hace la dicha abstracción.
Abstracción
• Denota las características esenciales de un
objeto que lo distinguen de todos los demás
tipos de objetos y proporciona fronteras
conceptuales definidas
Métodos de Abstracción
• Abstracción por parametrizacion
La identidad de los datos se sustituyen por parámetros
• Abstracción por especificación
Permite fijarnos en el comportamiento que son
necesarios al usuario
Abstracción de Datos
• Metodología que permite diseñar estructuras
de datos bajo ciertos lineamientos, este
proceso se olvida de los detalles de
implementación de datos.
• Cuando se diseña una estructura de datos se
llama tipo de datos abstracto (TDA)
Abstracción de Datos
• En la especificación de un TDA se indica la
abstracción realizada al diseñar una estructura
de datos y las reglas para poder usar el TDA.
Abstracción
Especificación de un TDA
• La especificación de un TDA debe
contener los siguientes datos;
1. Elementos que conforman la estructura
2. Tipo de organización para guardar los
elementos:
1. Lineal (1-1)
2. Jerárquica (1-M)
3. Red (M-M)
4. Sin relación
3. Dominio de la estructura
4. Descripción de las operaciones de la
estructura
Abstracción
Especificación de un TDA
• Las operaciones deben incluir los siguientes
puntos:
• Nombre
• Descripción
• Datos de entrada
• Datos de salida
• Precondición
• Postcondición
Abstracción
Niveles de abstracción
• Nivel lógico o abstracto
• Se definen las estructuras de datos y las
operaciones relacionadas
• Nivel físico o de implementación
• Se decide el leng. de programación y se implementa
la estructura como un modulo.
• Nivel de aplicación o de uso
• Uso del TDA para llamar a las operaciones.
Encapsulamiento
• Se consigue ocultado la información, es
decir es el proceso de ocultar todos los
secretos de un objeto.
La abstracción y el encapsulamiento son complementarios, la
abstracción se centra en el comportamiento observable de
los objetos y el encapsulamiento se centra en la
implementación que da lugar a dicho comportamiento.
Encapsulamiento
• Proceso de almacenar en un mismo
compartimiento los elementos de
una abstracción que constituyen su
estructura y su comportamiento.
Encapsulamiento
• El objeto esconde sus datos de los demás
objetos y permite el acceso mediante sus
propios métodos.
• Es más fácil modificar los programas que
utilizan el encapsulado por que se modifica al
mismo tiempo un tipo de objetos. El
comportamiento se puede probar de manera
independiente a los demás tipos de objetos.
Modularidad
• “El acto de fragmentar un programa en
componentes individuales puede reducir su
complejidad en algún grado...” Myers
Propiedad que tiene un
sistema que ha sido
descompuesto en un
conjunto de módulos
cohesivos y débilmente
acoplados
Modularidad
• Implica que el software se divide en
componentes con nombres y ubicaciones
determinados que se denominan módulos y
que se integran para satisfacer los requisitos
del sistema.
Modularidad
• Los módulos pueden compilarse separadamente pero
tienen conexiones con otros módulos.
 Los lenguajes que soportan el
concepto de modulo
generalmente distinguen entre
la interfaz y su
implementación.
Modularidad
• Los módulos sirven como contenedores físicos
en los que se declaran las clases y los objetos
del diseño lógico realizado.
• Un modulo esta abierto si puede ser ampliado
• Un modulo esta cerrado si está disponible para su
uso
Modularidad
• En el diseño estructurado, la popularización
persigue el agrupamiento de subprogramas
utilizando los criterios de acoplamiento y
cohesión. En el DOO, la tarea es decidir donde
empaquetar físicamente las clases y objetos
Modularidad
• Los módulos deben agrupar abstracciones con
relaciones lógicas (cohesivos) y la dependencia
entre módulos debe ser mínima
(acoplamiento).
Jerarquía
“ Es una clasificación u ordenación de
abstracciones”
• Las dos jerarquías más importantes en un
sistema complejo son su estructura de clases
(jerarquía de clases) y su estructura de objetos
(jerarquía de partes).
Jerarquía
• Ejemplos de jerarquía:
• Herencia Simple
• Herencia Múltiple
• Generalización
Jerarquía (Tipificación)
• Un tipo es una caracterización precisa de
propiedades estructurales o de
comportamiento que comparten una serie de
entidades.
Los objetos de tipos
distintos no pueden
intercambiarse o solo de
formas muy restringidas.
Jerarquía (Tipificación)
• Los lenguajes de programación pueden tener
comprobación estricta de tipos, comprobación
débil, o incluso no tener tipos y aun así ser
considerados como OO.
Concurrencia
• Capacidad de un sistema para manejar varios
eventos (procesos) de forma simultanea
La concurrencia permite a varios objetos actuar
al mismo tiempo.
• La concurrencia es la propiedad que distingue
un objeto activo de uno no activo
Persistencia
La persistencia conserva el estado de un
objeto en el tiempo y en el espacio
• La persistencia de objetos abarca lo
siguiente:
• Resultados transitorios
• Variables locales
• Variables propias
• Datos que existen entre ejecuciones
• Datos que existen entre versiones de un
programa
• Datos que sobreviven al programa
Persistencia
• Los lenguajes de programación tratan los 3
primero tipos de persistencia, en tanto que los
últimos pertenecen al dominio de las BDOO.
• En la practica las BD se construyen sobre
tecnología contrastada, bd secuenciales,
indexadas, jerárquicas, pero ofrecen una
abstracción de la interfaz OO
Objetos
• Un objeto podría considerarse como:
• Una cosa tangible y/o visible
• Algo que puede comprenderse intelectualmente
• Algo hacia lo que se dirige un pensamiento o acción
Objetos
• Un objeto modela parte de la realidad, por
ello, es algo que existe en el tiempo y el
espacio.
• En el ámbito del software el termino objeto
se utilizo por primera vez con el lenguaje
simula.
Objetos
Un objeto representa un elemento, unidad o entidad
individual e identificable, ya sea real o abstracta,
con un papel bien definido en el dominio del
problema
Smith y Tockey
Objetos
• Definición del objeto: coche
Atributos
• Color
•Velocidad
• Modelo
• Cilindros
Funciones
• Andar
• Parar
• Girar a la derecha
•Girar a la izquierda
Objetos
• Los objetos se pueden manifestar en una de
las siguientes formas:
• Entidades externas: otros sistemas,
dispositivos que producen y consumen
información.
• Cosas: Informes, visualizadores, forman
parte del dominio de la información
Objetos
• Un objeto puede considerarse como una
capsula dividida en tres partes:
• Relaciones
• Propiedades
• Métodos
Objetos (Formato)
• Debe existir un formato que permita
identificar a los objetos y sus elementos
involucrados
Nombre del objeto
Propiedades
Operaciones
Objetos (Atributos)
• Los atributos describen un objeto
seleccionado, los atributos definen en esencia
un objeto
Mueble
Dimensiones
Costos
Peso
Color
Objetos
• Un objeto tiene estado, comportamiento e
identidad; la estructura y comportamiento de
objetos similares están definidos en su clase
común.
Objetos (Estado)
El estado de un objeto abarca todas las
propiedades (normalmente estáticas) del
mismo más los valores actuales (normalmente
dinámicos) de cada una de esas propiedades
Objetos (Comportamiento)
• Ningún objeto existe de forma aislada, los
objetos reciben acciones y actúan sobre otros
objetos.
El comportamiento es como actúa y reacciona
un objeto, en términos de sus cambios de
estados y paso de mensajes
Objetos (comportamiento)
• Los objetos se comunican mediante mensajes
Objetos (Comportamiento)
• En los lenguajes de POO las operaciones que
se pueden realizar sobre un objeto suelen
declararse como métodos, que forman parte
de la declaración de clase
Objetos (Comportamiento)
• El comportamiento de un objeto es función de
su estado así como de la operación que se
realiza sobre el.
Objetos (Operaciones)
• Una operación denota un servicio que una
clase ofrece a sus clientes:
• Modificador: Altera el estado de un objeto
• Selector: Accede al estado de un objeto
• Iterador: Accede a las partes de un objeto en
un orden establecido
• Constructor
• Destructor
Objetos (Métodos)
• Los métodos especifican la forma en que se
controlan los datos de un objeto.
• Los métodos en un tipo de objeto solo hacen
referencia a la estructura de datos de dicho
objeto
Objetos (operaciones vs métodos)
• Una operación es un tipo de servicio solicitado
y el método es el código de programación
asociado
• Operación: Promedio
• Método: forma de calcular el promedio
Objetos (Encapsulación y
Ocultamiento)
• Los objetos son estructuras complejas que
contienen datos y programas relacionados
entre si, dicha estructura encierra estos
elementos. (encapsulación).
Objetos (Encapsulación y
Ocultamiento)
• Los objetos son inaccesibles e impiden que
otros objetos o los usuarios conozcan como
está distribuida la información, la única forma
de accesar un objeto es a través de sus
métodos
Objetos (identidad)
Es la propiedad de un objeto que lo distingue de
todos los demás objetos
• En la mayoría de los lenguajes se
utilizan nombres de variables para
distinguir objetos.
• Se debe reconocer la diferencia entre el
nombre de un objeto y el objeto en si
mismo
Objetos
• Los objetos con estados y comportamientos
similares se agrupan en clases
Clases
• Los términos objeto y clase están
relacionados, sin embargo una clase
representa sólo una abstracción de un objeto
Una clase es un conjunto de objetos
que comparten una estructura común y
un comportamiento común
Clases (consideraciones)
• Un objeto es la instancia de una clase
• Un objeto no es un clase, pero una clase
puede ser un objeto
• Una clase es necesaria pero no suficiente para
la descomposición
Clase (interfaz)
• Una clase sirve como vinculo entre una
abstracción y todos sus clientes.
• La interfaz de una clase proporciona su visión
externa, es decir, oculta la estructura y los
detalles del comportamiento de un objeto.
• La implementación de una clase proporciona
su visión interna
Clases (interfaz)
• Se puede dividir la interfaz de una clase en
tres partes:
• Public (publica) Accesible por todos los clientes
• Protected (protegida) Accesible por la propia clase,
subclases y clases amigas
• Private (privada) Accesible solo por la propia clase y
sus clases amigas
Clases (relaciones)
• Las clases, al igual que los objetos no existen
en forma aislada; las relaciones entre clases se
dan dos razones:
• Comparten elementos
• Conexión semántica

Más contenido relacionado

Similar a tecnologiasoo-01-140709001709-phpapp02.pdf

Diseño del Software y el Diseño Orientado a Objetos
Diseño del Software y el Diseño Orientado aObjetosDiseño del Software y el Diseño Orientado aObjetos
Diseño del Software y el Diseño Orientado a ObjetosAlexander J Sanchez A
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetosalexmoncada21
 
Fundamentos de la Tecnologia Orientada a Objetos
Fundamentos de la Tecnologia Orientada a ObjetosFundamentos de la Tecnologia Orientada a Objetos
Fundamentos de la Tecnologia Orientada a Objetosedwinlemmon
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetosricardoloja
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiRaimonKoudsi
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareAndhy H Palma
 
03 -fundamentos_de_la_tecnologia_orientada_a_objetos
03  -fundamentos_de_la_tecnologia_orientada_a_objetos03  -fundamentos_de_la_tecnologia_orientada_a_objetos
03 -fundamentos_de_la_tecnologia_orientada_a_objetoskarlalopezbello
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetosNanda Moran
 
Terminología y conceptos en Arquitecturas dirigidas por Modelos
Terminología y conceptos en Arquitecturas dirigidas por ModelosTerminología y conceptos en Arquitecturas dirigidas por Modelos
Terminología y conceptos en Arquitecturas dirigidas por ModelosRicardo Tesoriero
 
Diapositiva de Estudio: FUNDAMENTOS UML.ppt
Diapositiva de Estudio: FUNDAMENTOS UML.pptDiapositiva de Estudio: FUNDAMENTOS UML.ppt
Diapositiva de Estudio: FUNDAMENTOS UML.pptjorgejvc777
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetoswellington018
 
2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetos2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetosjohnny herrera
 
Sistemas ii fundamentos y metodos de analisis de requerimientos
Sistemas ii   fundamentos y metodos de analisis de requerimientosSistemas ii   fundamentos y metodos de analisis de requerimientos
Sistemas ii fundamentos y metodos de analisis de requerimientosGalderIL057
 

Similar a tecnologiasoo-01-140709001709-phpapp02.pdf (20)

Diseño del Software y el Diseño Orientado a Objetos
Diseño del Software y el Diseño Orientado aObjetosDiseño del Software y el Diseño Orientado aObjetos
Diseño del Software y el Diseño Orientado a Objetos
 
Diseño de software
Diseño de softwareDiseño de software
Diseño de software
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetos
 
UML
UMLUML
UML
 
Fundamentos de la Tecnologia Orientada a Objetos
Fundamentos de la Tecnologia Orientada a ObjetosFundamentos de la Tecnologia Orientada a Objetos
Fundamentos de la Tecnologia Orientada a Objetos
 
Poo
PooPoo
Poo
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetos
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
 
porgramacion orientada a objetos
porgramacion orientada a objetos porgramacion orientada a objetos
porgramacion orientada a objetos
 
tarea poo s-a
tarea poo s-atarea poo s-a
tarea poo s-a
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
 
03 -fundamentos_de_la_tecnologia_orientada_a_objetos
03  -fundamentos_de_la_tecnologia_orientada_a_objetos03  -fundamentos_de_la_tecnologia_orientada_a_objetos
03 -fundamentos_de_la_tecnologia_orientada_a_objetos
 
Modelo de analisis expo
Modelo de analisis expoModelo de analisis expo
Modelo de analisis expo
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetos
 
Terminología y conceptos en Arquitecturas dirigidas por Modelos
Terminología y conceptos en Arquitecturas dirigidas por ModelosTerminología y conceptos en Arquitecturas dirigidas por Modelos
Terminología y conceptos en Arquitecturas dirigidas por Modelos
 
Diapositiva de Estudio: FUNDAMENTOS UML.ppt
Diapositiva de Estudio: FUNDAMENTOS UML.pptDiapositiva de Estudio: FUNDAMENTOS UML.ppt
Diapositiva de Estudio: FUNDAMENTOS UML.ppt
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetos
 
2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetos2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetos
 
Poo3
Poo3Poo3
Poo3
 
Sistemas ii fundamentos y metodos de analisis de requerimientos
Sistemas ii   fundamentos y metodos de analisis de requerimientosSistemas ii   fundamentos y metodos de analisis de requerimientos
Sistemas ii fundamentos y metodos de analisis de requerimientos
 

Último

INFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsx
INFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsxINFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsx
INFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsxCORPORACIONJURIDICA
 
EGLA CORP - Honduras Abril 27 , 2024.pptx
EGLA CORP - Honduras Abril 27 , 2024.pptxEGLA CORP - Honduras Abril 27 , 2024.pptx
EGLA CORP - Honduras Abril 27 , 2024.pptxDr. Edwin Hernandez
 
Buenas Practicas de Almacenamiento en droguerias
Buenas Practicas de Almacenamiento en drogueriasBuenas Practicas de Almacenamiento en droguerias
Buenas Practicas de Almacenamiento en drogueriasmaicholfc
 
diseño de redes en la cadena de suministro.pptx
diseño de redes en la cadena de suministro.pptxdiseño de redes en la cadena de suministro.pptx
diseño de redes en la cadena de suministro.pptxjuanleivagdf
 
gua de docente para el curso de finanzas
gua de docente para el curso de finanzasgua de docente para el curso de finanzas
gua de docente para el curso de finanzassuperamigo2014
 
ADMINISTRACION FINANCIERA CAPITULO 4.pdf
ADMINISTRACION FINANCIERA CAPITULO 4.pdfADMINISTRACION FINANCIERA CAPITULO 4.pdf
ADMINISTRACION FINANCIERA CAPITULO 4.pdfguillencuevaadrianal
 
cuadro sinoptico tipos de organizaci.pdf
cuadro sinoptico tipos de organizaci.pdfcuadro sinoptico tipos de organizaci.pdf
cuadro sinoptico tipos de organizaci.pdfjesuseleazarcenuh
 
Como Construir Un Modelo De Negocio.pdf nociones basicas
Como Construir Un Modelo De Negocio.pdf   nociones basicasComo Construir Un Modelo De Negocio.pdf   nociones basicas
Como Construir Un Modelo De Negocio.pdf nociones basicasoscarhernandez98241
 
CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONES
CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONESCULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONES
CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONESMarielaAldanaMoscoso
 
LIC-ZIEGLER-Planificación y Control de Gestión
LIC-ZIEGLER-Planificación y Control de GestiónLIC-ZIEGLER-Planificación y Control de Gestión
LIC-ZIEGLER-Planificación y Control de GestiónBahamondesOscar
 
DELITOS CONTRA LA GESTION PUBLICA PPT.pdf
DELITOS CONTRA LA GESTION PUBLICA PPT.pdfDELITOS CONTRA LA GESTION PUBLICA PPT.pdf
DELITOS CONTRA LA GESTION PUBLICA PPT.pdfJaquelinRamos6
 
Plan General de Contabilidad Y PYMES pdf
Plan General de Contabilidad Y PYMES pdfPlan General de Contabilidad Y PYMES pdf
Plan General de Contabilidad Y PYMES pdfdanilojaviersantiago
 
Modelo de convenio de pago con morosos del condominio (GENÉRICO).docx
Modelo de convenio de pago con morosos del condominio (GENÉRICO).docxModelo de convenio de pago con morosos del condominio (GENÉRICO).docx
Modelo de convenio de pago con morosos del condominio (GENÉRICO).docxedwinrojas836235
 
modulo+penal+del+16+al+20+hhggde+enero.pdf
modulo+penal+del+16+al+20+hhggde+enero.pdfmodulo+penal+del+16+al+20+hhggde+enero.pdf
modulo+penal+del+16+al+20+hhggde+enero.pdfmisssusanalrescate01
 
COPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESA
COPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESACOPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESA
COPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESADanielAndresBrand
 
Clima-laboral-estrategias-de-medicion-e-book-1.pdf
Clima-laboral-estrategias-de-medicion-e-book-1.pdfClima-laboral-estrategias-de-medicion-e-book-1.pdf
Clima-laboral-estrategias-de-medicion-e-book-1.pdfConstructiva
 
Presentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdf
Presentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdfPresentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdf
Presentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdfLuisAlbertoAlvaradoF2
 
INTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptx
INTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptxINTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptx
INTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptxRENANRODRIGORAMIREZR
 
Presentación Final Riesgo de Crédito.pptx
Presentación Final Riesgo de Crédito.pptxPresentación Final Riesgo de Crédito.pptx
Presentación Final Riesgo de Crédito.pptxIvnAndres5
 
PIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptx
PIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptxPIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptx
PIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptxJosePuentePadronPuen
 

Último (20)

INFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsx
INFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsxINFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsx
INFORMATIVO CIRCULAR FISCAL - RENTA 2023.ppsx
 
EGLA CORP - Honduras Abril 27 , 2024.pptx
EGLA CORP - Honduras Abril 27 , 2024.pptxEGLA CORP - Honduras Abril 27 , 2024.pptx
EGLA CORP - Honduras Abril 27 , 2024.pptx
 
Buenas Practicas de Almacenamiento en droguerias
Buenas Practicas de Almacenamiento en drogueriasBuenas Practicas de Almacenamiento en droguerias
Buenas Practicas de Almacenamiento en droguerias
 
diseño de redes en la cadena de suministro.pptx
diseño de redes en la cadena de suministro.pptxdiseño de redes en la cadena de suministro.pptx
diseño de redes en la cadena de suministro.pptx
 
gua de docente para el curso de finanzas
gua de docente para el curso de finanzasgua de docente para el curso de finanzas
gua de docente para el curso de finanzas
 
ADMINISTRACION FINANCIERA CAPITULO 4.pdf
ADMINISTRACION FINANCIERA CAPITULO 4.pdfADMINISTRACION FINANCIERA CAPITULO 4.pdf
ADMINISTRACION FINANCIERA CAPITULO 4.pdf
 
cuadro sinoptico tipos de organizaci.pdf
cuadro sinoptico tipos de organizaci.pdfcuadro sinoptico tipos de organizaci.pdf
cuadro sinoptico tipos de organizaci.pdf
 
Como Construir Un Modelo De Negocio.pdf nociones basicas
Como Construir Un Modelo De Negocio.pdf   nociones basicasComo Construir Un Modelo De Negocio.pdf   nociones basicas
Como Construir Un Modelo De Negocio.pdf nociones basicas
 
CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONES
CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONESCULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONES
CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONES
 
LIC-ZIEGLER-Planificación y Control de Gestión
LIC-ZIEGLER-Planificación y Control de GestiónLIC-ZIEGLER-Planificación y Control de Gestión
LIC-ZIEGLER-Planificación y Control de Gestión
 
DELITOS CONTRA LA GESTION PUBLICA PPT.pdf
DELITOS CONTRA LA GESTION PUBLICA PPT.pdfDELITOS CONTRA LA GESTION PUBLICA PPT.pdf
DELITOS CONTRA LA GESTION PUBLICA PPT.pdf
 
Plan General de Contabilidad Y PYMES pdf
Plan General de Contabilidad Y PYMES pdfPlan General de Contabilidad Y PYMES pdf
Plan General de Contabilidad Y PYMES pdf
 
Modelo de convenio de pago con morosos del condominio (GENÉRICO).docx
Modelo de convenio de pago con morosos del condominio (GENÉRICO).docxModelo de convenio de pago con morosos del condominio (GENÉRICO).docx
Modelo de convenio de pago con morosos del condominio (GENÉRICO).docx
 
modulo+penal+del+16+al+20+hhggde+enero.pdf
modulo+penal+del+16+al+20+hhggde+enero.pdfmodulo+penal+del+16+al+20+hhggde+enero.pdf
modulo+penal+del+16+al+20+hhggde+enero.pdf
 
COPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESA
COPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESACOPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESA
COPASST Y COMITE DE CONVIVENCIA.pptx DE LA EMPRESA
 
Clima-laboral-estrategias-de-medicion-e-book-1.pdf
Clima-laboral-estrategias-de-medicion-e-book-1.pdfClima-laboral-estrategias-de-medicion-e-book-1.pdf
Clima-laboral-estrategias-de-medicion-e-book-1.pdf
 
Presentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdf
Presentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdfPresentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdf
Presentacion III ACTIVIDADES DE CONTROL. IV UNIDAD..pdf
 
INTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptx
INTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptxINTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptx
INTERESES Y MULTAS DEL IMPUESTO A LA RENTA POWER POINT.pptx
 
Presentación Final Riesgo de Crédito.pptx
Presentación Final Riesgo de Crédito.pptxPresentación Final Riesgo de Crédito.pptx
Presentación Final Riesgo de Crédito.pptx
 
PIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptx
PIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptxPIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptx
PIA MATEMATICAS FINANCIERAS SOBRE PROBLEMAS DE ANUALIDAD.pptx
 

tecnologiasoo-01-140709001709-phpapp02.pdf

  • 1. Tecnología Orientada a Objetos Maestría en Desarrollo de Software ISC. Erivan Martínez Ovando
  • 2. Introducción La Tecnología Orientada a Objetos se apoya en fundamentos de la ingeniería, cuyos elementos reciben el nombre global de modelo de objetos, el cual abarca los principios de abstracción, encapsulación, modularidad, jerarquía, concurrencia y persistencia.
  • 3. Fundamentos de la TOO • SIMULACIÓN • ENCAPSULAMIENTO • MODULARIDAD • OCULTAMIENTO • REUTILIZACIÓN
  • 4. Introducción • La TOO es un nuevo enfoque sobre la manera de organizar las diferentes piezas que conforman un sistema de información. • Términos POO AOO DOO BDOO
  • 5. Introducción • El concepto objeto y las operaciones relacionadas no son nuevos en la programación, sin embargo el DOO es poco explorado. • En los inicios de la computación el nivel de abstracción que se utilizaba era muy bajo, los lenguajes ensambladores permitían el uso de instrucciones maquina
  • 6. Introducción • El siguiente nivel de abstracción se dio con la aparición de los lenguajes de alto nivel, los cuales permitieron el uso de estructuras de datos y de control predefinidas. • La abstracción y el ocultamiento de información surgió en los años 70´s lo que dio lugar a métodos de diseño conducidos por los datos
  • 7. Antecedentes  La TOO data de los años 60.  En 1961 Krystin Nygaard crea Simula I.  En 1967 se creó Simula 67 y con ello nace por primera vez los conceptos de Clase, objetos y herencia.  En 1970 se crea SmallTalk dirigido por Allan Kay con interfaz gráfica y herramientas de desarrollo integradas.  Visualizadores de Clases  Inspeccionadores de código
  • 8. Antecedentes • Énfasis en la abstracción de datos y los problemas del mundo se representaban como un conjunto de objetos de datos para los que existían ciertas operaciones
  • 9. Antecedentes • El enfoque DOO se base en la abstracción, ocultamiento de la información y la modularidad. • A finales de los 80´s el DOO se usaba en aplicaciones de software que iban desde las animaciones graficas hasta las telecomunicaciones
  • 10. Antecedentes • Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de comportamiento especifico
  • 11. Antecedentes • En el análisis de sistemas OO requiere estudiar los objetos en un ambiente, así como los eventos que interactúan con dichos objetos.
  • 12. TOO (Perspectiva Histórica) • Las técnicas OO se unen a otras tecnologías de software para lograr una correcta construcción de sistemas OO. • Case, I case (integrated case) • Programación visual • Generadores de código • Repositorios • Bases de Datos OO • Lenguajes no procedimentales • Bibliotecas de Clase • Análisis Orientado a Objetos
  • 13. TOO (Perspectiva Histórica) Estilos de programación Estilo de programación Abstracción • Orientado a Procedimientos - Algoritmos • Orientados a Objetos - Clases y Objetos • Orientados a Lógica - Calculo de pred. • Orientados a Reglas - si...entonces
  • 14. TOO (Perspectiva Histórica) Estilos de programación • Cada estilo de programación es capaz de resolver cierto tipos de problemas, por lo que no hay un estilo de programación que sea el mejor. • Cada estilo se basa en su propio marco de referencia conceptual, una actitud mental diferente.
  • 15. TOO (Perspectiva Histórica) • Hoy en día la TOO ya no se aplica solamente en los lenguajes de programación, además se aplica en el análisis y el diseño así como en las bases de datos
  • 16. TOO perspectiva histórica • Programación lineal • Programación estructurada • Programación Orientada a Objetos
  • 17. Modelo Orientado a Objetos • Elementos básicos • Abstracción • Encapsulamiento • Jerarquía • Tipificación • Concurrencia • Persistencia * Los tres primeros son necesarios para considerarse OO
  • 18. Abstracción • Proceso mental mediante el cual se extraen los rasgos esenciales de algo con el fin de representarlo mediante un lenguaje grafico. • La abstracción depende del contexto mental de quien hace la dicha abstracción.
  • 19. Abstracción • Denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objetos y proporciona fronteras conceptuales definidas
  • 20. Métodos de Abstracción • Abstracción por parametrizacion La identidad de los datos se sustituyen por parámetros • Abstracción por especificación Permite fijarnos en el comportamiento que son necesarios al usuario
  • 21. Abstracción de Datos • Metodología que permite diseñar estructuras de datos bajo ciertos lineamientos, este proceso se olvida de los detalles de implementación de datos. • Cuando se diseña una estructura de datos se llama tipo de datos abstracto (TDA)
  • 22. Abstracción de Datos • En la especificación de un TDA se indica la abstracción realizada al diseñar una estructura de datos y las reglas para poder usar el TDA.
  • 23. Abstracción Especificación de un TDA • La especificación de un TDA debe contener los siguientes datos; 1. Elementos que conforman la estructura 2. Tipo de organización para guardar los elementos: 1. Lineal (1-1) 2. Jerárquica (1-M) 3. Red (M-M) 4. Sin relación 3. Dominio de la estructura 4. Descripción de las operaciones de la estructura
  • 24. Abstracción Especificación de un TDA • Las operaciones deben incluir los siguientes puntos: • Nombre • Descripción • Datos de entrada • Datos de salida • Precondición • Postcondición
  • 25. Abstracción Niveles de abstracción • Nivel lógico o abstracto • Se definen las estructuras de datos y las operaciones relacionadas • Nivel físico o de implementación • Se decide el leng. de programación y se implementa la estructura como un modulo. • Nivel de aplicación o de uso • Uso del TDA para llamar a las operaciones.
  • 26. Encapsulamiento • Se consigue ocultado la información, es decir es el proceso de ocultar todos los secretos de un objeto. La abstracción y el encapsulamiento son complementarios, la abstracción se centra en el comportamiento observable de los objetos y el encapsulamiento se centra en la implementación que da lugar a dicho comportamiento.
  • 27. Encapsulamiento • Proceso de almacenar en un mismo compartimiento los elementos de una abstracción que constituyen su estructura y su comportamiento.
  • 28. Encapsulamiento • El objeto esconde sus datos de los demás objetos y permite el acceso mediante sus propios métodos. • Es más fácil modificar los programas que utilizan el encapsulado por que se modifica al mismo tiempo un tipo de objetos. El comportamiento se puede probar de manera independiente a los demás tipos de objetos.
  • 29. Modularidad • “El acto de fragmentar un programa en componentes individuales puede reducir su complejidad en algún grado...” Myers Propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados
  • 30. Modularidad • Implica que el software se divide en componentes con nombres y ubicaciones determinados que se denominan módulos y que se integran para satisfacer los requisitos del sistema.
  • 31. Modularidad • Los módulos pueden compilarse separadamente pero tienen conexiones con otros módulos.  Los lenguajes que soportan el concepto de modulo generalmente distinguen entre la interfaz y su implementación.
  • 32. Modularidad • Los módulos sirven como contenedores físicos en los que se declaran las clases y los objetos del diseño lógico realizado. • Un modulo esta abierto si puede ser ampliado • Un modulo esta cerrado si está disponible para su uso
  • 33. Modularidad • En el diseño estructurado, la popularización persigue el agrupamiento de subprogramas utilizando los criterios de acoplamiento y cohesión. En el DOO, la tarea es decidir donde empaquetar físicamente las clases y objetos
  • 34. Modularidad • Los módulos deben agrupar abstracciones con relaciones lógicas (cohesivos) y la dependencia entre módulos debe ser mínima (acoplamiento).
  • 35. Jerarquía “ Es una clasificación u ordenación de abstracciones” • Las dos jerarquías más importantes en un sistema complejo son su estructura de clases (jerarquía de clases) y su estructura de objetos (jerarquía de partes).
  • 36. Jerarquía • Ejemplos de jerarquía: • Herencia Simple • Herencia Múltiple • Generalización
  • 37. Jerarquía (Tipificación) • Un tipo es una caracterización precisa de propiedades estructurales o de comportamiento que comparten una serie de entidades. Los objetos de tipos distintos no pueden intercambiarse o solo de formas muy restringidas.
  • 38. Jerarquía (Tipificación) • Los lenguajes de programación pueden tener comprobación estricta de tipos, comprobación débil, o incluso no tener tipos y aun así ser considerados como OO.
  • 39. Concurrencia • Capacidad de un sistema para manejar varios eventos (procesos) de forma simultanea La concurrencia permite a varios objetos actuar al mismo tiempo. • La concurrencia es la propiedad que distingue un objeto activo de uno no activo
  • 40. Persistencia La persistencia conserva el estado de un objeto en el tiempo y en el espacio • La persistencia de objetos abarca lo siguiente: • Resultados transitorios • Variables locales • Variables propias • Datos que existen entre ejecuciones • Datos que existen entre versiones de un programa • Datos que sobreviven al programa
  • 41. Persistencia • Los lenguajes de programación tratan los 3 primero tipos de persistencia, en tanto que los últimos pertenecen al dominio de las BDOO. • En la practica las BD se construyen sobre tecnología contrastada, bd secuenciales, indexadas, jerárquicas, pero ofrecen una abstracción de la interfaz OO
  • 42. Objetos • Un objeto podría considerarse como: • Una cosa tangible y/o visible • Algo que puede comprenderse intelectualmente • Algo hacia lo que se dirige un pensamiento o acción
  • 43. Objetos • Un objeto modela parte de la realidad, por ello, es algo que existe en el tiempo y el espacio. • En el ámbito del software el termino objeto se utilizo por primera vez con el lenguaje simula.
  • 44. Objetos Un objeto representa un elemento, unidad o entidad individual e identificable, ya sea real o abstracta, con un papel bien definido en el dominio del problema Smith y Tockey
  • 45. Objetos • Definición del objeto: coche Atributos • Color •Velocidad • Modelo • Cilindros Funciones • Andar • Parar • Girar a la derecha •Girar a la izquierda
  • 46. Objetos • Los objetos se pueden manifestar en una de las siguientes formas: • Entidades externas: otros sistemas, dispositivos que producen y consumen información. • Cosas: Informes, visualizadores, forman parte del dominio de la información
  • 47. Objetos • Un objeto puede considerarse como una capsula dividida en tres partes: • Relaciones • Propiedades • Métodos
  • 48. Objetos (Formato) • Debe existir un formato que permita identificar a los objetos y sus elementos involucrados Nombre del objeto Propiedades Operaciones
  • 49. Objetos (Atributos) • Los atributos describen un objeto seleccionado, los atributos definen en esencia un objeto Mueble Dimensiones Costos Peso Color
  • 50. Objetos • Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares están definidos en su clase común.
  • 51. Objetos (Estado) El estado de un objeto abarca todas las propiedades (normalmente estáticas) del mismo más los valores actuales (normalmente dinámicos) de cada una de esas propiedades
  • 52. Objetos (Comportamiento) • Ningún objeto existe de forma aislada, los objetos reciben acciones y actúan sobre otros objetos. El comportamiento es como actúa y reacciona un objeto, en términos de sus cambios de estados y paso de mensajes
  • 53. Objetos (comportamiento) • Los objetos se comunican mediante mensajes
  • 54. Objetos (Comportamiento) • En los lenguajes de POO las operaciones que se pueden realizar sobre un objeto suelen declararse como métodos, que forman parte de la declaración de clase
  • 55. Objetos (Comportamiento) • El comportamiento de un objeto es función de su estado así como de la operación que se realiza sobre el.
  • 56. Objetos (Operaciones) • Una operación denota un servicio que una clase ofrece a sus clientes: • Modificador: Altera el estado de un objeto • Selector: Accede al estado de un objeto • Iterador: Accede a las partes de un objeto en un orden establecido • Constructor • Destructor
  • 57. Objetos (Métodos) • Los métodos especifican la forma en que se controlan los datos de un objeto. • Los métodos en un tipo de objeto solo hacen referencia a la estructura de datos de dicho objeto
  • 58. Objetos (operaciones vs métodos) • Una operación es un tipo de servicio solicitado y el método es el código de programación asociado • Operación: Promedio • Método: forma de calcular el promedio
  • 59. Objetos (Encapsulación y Ocultamiento) • Los objetos son estructuras complejas que contienen datos y programas relacionados entre si, dicha estructura encierra estos elementos. (encapsulación).
  • 60. Objetos (Encapsulación y Ocultamiento) • Los objetos son inaccesibles e impiden que otros objetos o los usuarios conozcan como está distribuida la información, la única forma de accesar un objeto es a través de sus métodos
  • 61. Objetos (identidad) Es la propiedad de un objeto que lo distingue de todos los demás objetos • En la mayoría de los lenguajes se utilizan nombres de variables para distinguir objetos. • Se debe reconocer la diferencia entre el nombre de un objeto y el objeto en si mismo
  • 62. Objetos • Los objetos con estados y comportamientos similares se agrupan en clases
  • 63. Clases • Los términos objeto y clase están relacionados, sin embargo una clase representa sólo una abstracción de un objeto Una clase es un conjunto de objetos que comparten una estructura común y un comportamiento común
  • 64. Clases (consideraciones) • Un objeto es la instancia de una clase • Un objeto no es un clase, pero una clase puede ser un objeto • Una clase es necesaria pero no suficiente para la descomposición
  • 65. Clase (interfaz) • Una clase sirve como vinculo entre una abstracción y todos sus clientes. • La interfaz de una clase proporciona su visión externa, es decir, oculta la estructura y los detalles del comportamiento de un objeto. • La implementación de una clase proporciona su visión interna
  • 66. Clases (interfaz) • Se puede dividir la interfaz de una clase en tres partes: • Public (publica) Accesible por todos los clientes • Protected (protegida) Accesible por la propia clase, subclases y clases amigas • Private (privada) Accesible solo por la propia clase y sus clases amigas
  • 67. Clases (relaciones) • Las clases, al igual que los objetos no existen en forma aislada; las relaciones entre clases se dan dos razones: • Comparten elementos • Conexión semántica