El Paradigma

Orientado a Objetos

PARADIGMA
viene
del
Griego
Paradeima = Modelo. Un paradigma es
el resultado de los usos , y costumbres,
de creencias establecidas de verdades a
medias, un paradigma es ley, hasta que
es sustituido por otro nuevo

Paradigma: Modo de Pensar

Ing. Hugo Escobar

El Paradigma Orientado
a Objetos

1. UNA PERSPECTIVA HISTRICA

1.1 Programacin Lineal
La programacin fue hecha en una manera
secuencial o lineal, la cual consista en

una

serie de pasos consecutivos con estructuras

consecutivas y bifurcaciones.

El problema : No hay

flexibilidad

y es difcil

mantener una gran cantidad de lneas de cdigo en

slo bloque, se vuelve una tarea complicada

1.UNA PERSPECTIVA HISTRICA

1.2. Programacin Estructurada

La

idea

principal

programacin

es

de

esta

separar

forma
las

de

partes

complejas del programa en mdulos

De manera que se tiene un diseo diseo
modular,

compuesto

por

mdulos

independientes que puedan comunicarse

entre s.

1.UNA PERSPECTIVA HISTRICA

1.3. Programacin orientada a objetos

La evolucin que se orientaba siempre a ir

descomponiendo ms el programa.

La POO se basa en la dividir el programa en

pequeas unidades lgicas de cdigo. A estas
pequeas unidades lgicas de cdigo se les
llama objetos. Los cuales se comunican entre
ellos mediante mensajes.

2. CARACTERSTICAS DE LA PROGRAMACIN
ORIENTADO A OBJETOS

Permite la reutilizacin y extensin del cdigo gracias a la herencia.

Permite crear sistemas ms complejos, facilitando el trabajo en equipo.
Relacionar el sistema al mundo real.
Facilita la creacin de programas visuales.
Construccin de prototipos
Agiliza el desarrollo de software
Permite la modularizacin del cdigo, ya que cada clase se crea generalmente
en un archivo distinto, y de esta manera facilitando el mantenimiento del software

3. PRINCIPALES CONCEPTOS DE LA
PROGRAMACIN ORIENTADA A OBJETOS

Objetos
Clases
Mtodos
Herencia
Polimorfismo

PRINCIPALES CONCEPTOS DE LA PROGRAMACIN ORIENTADA A OBJETOS

Un objeto es cualquier cosa que vemos a nuestro alrededor,

posee caractersticas y funcionalidades, Los datos estn ocultos

3.1 OBJETO

y slo mediante las funciones miembro es posible acceder a

ellos.

Ejemplo:
Objeto: Vehiculo
Caractersticas: Marca, modelo, color
Funcionalidades = Mtodo : Frenar, acelerar, retroceder.
Automvil
Marca: Mazada kazamai
Modelo: 2009
Color: Plateado

Frenar
Acelerar
Retroceder

PRINCIPALES CONCEPTOS DE LA PROGRAMACIN ORIENTADA A OBJETOS

Una clase es la descripcin de un conjunto de objetos;

3.2 CLASE

consta de mtodos y datos que resumen caractersticas

comunes del conjunto

Ejemplo:
Creando objetos
de la clase

Automvil
Marca: Mazada kazamai
Modelo: 2009
Color: Plateado
Frenar
Acelerar
Retroceder

Instancia de una
clase

Automvil
Marca: BMW za
Modelo: 2008
Color: Plateado
Frenar
Acelerar
Retroceder

http://www.slideshare.net/elsuse/analisis-y-diseo-orientado-objetos

DIFERENCIA
ENTRE CLASE Y
OBJETOS

La clase es un conjunto de objetos y el objeto

es una instancia de una clase

Objetos
Clase

Instancia de una clase

3.3 MTODOS

El mtodo es
secuencia
instrucciones.

Los mtodos son aquellas funciones que van a hacer

nuestra clase por ejemplo un clculos aritmticos, o
realizacin de un proceso del que se necesite

una
de

3.4 HERENCIA:

Consiste en que una clase puede heredar sus

variables y mtodos a varias subclases (la clase que hereda es
llamada superclase o clase padre)

Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene
incorporados los atributos y mtodos heredados de la superclase. De esta manera se
crea una jerarqua de herencia.
El objetivo final es la reutilizacin del cdigo anteriormente desarrollado.

Las clases se relacionan unas con otras por

HERENCIA
Las

medio de relaciones de herencia

clases se relacionan unas con otras por medio de relaciones de herencia.

Topologa de una aplicacin orientada a objetos. [5 Booch]

POLIMORFISMO

Se

Capacidad de un programa de
trabajar con ms de un tipo de objeto

puede trabajar con un

objeto de una clase

sin

importar de que clase se trate

Posibilidad

de

declarar

mtodos con el mismo nombre

que pueden tener diferentes
argumentos dentro de una
misma clase
http://docentes.uacj.mx/ovaldez/Prog2/Curso/Unidad%201.do

Encapsulamiento

Es el proceso de ocultar todos los detalles de implementacin

de un objeto. Tpicamente la estructura de un objeto queda
oculta, as como la implementacin de sus mtodos.

Controla el acceso a las estructuras internas, lo que permite al

autor de una clase modificar libremente su diseo sin intervenir
con otras partes del programa que usan la clase, si se
mantienen los llamados a las funciones miembros iguales.

El Proceso Unificado Racional

(RUP)
El

Proceso Unificado Racional (RUP, por las

siglas de Rational Unified Process)
(Krutchen, 2003) es un ejemplo de un
modelo de proceso moderno que se deriv
del trabajo sobre el UML y el proceso
asociado de desarrollo de software unificado.

 El

RUP reconoce que los modelos de

proceso convencionales presentan una sola
visin del proceso.
En contraste, el RUP por lo general se
describe desde tres perspectivas:

 1.

Una perspectiva dinmica que muestra las

fases del modelo a travs del tiempo.

2.

Una perspectiva esttica que presenta las

actividades del proceso que se establecen.

3.

Una perspectiva prctica que sugiere

buenas prcticas a usar durante el proceso.

 El

RUP es un modelo en fases que identifica

cuatro fases discretas en el proceso de
software.
Sin embargo, a diferencia del modelo en
cascada, donde las fases se igualan con
actividades del proceso, las fases en el RUP
estn ms estrechamente vinculadas con la
empresa que con las preocupaciones tcnicas.

Fases Modelo RUP

1.

Concepcin La meta de la fase de

concepcin es establecer un caso
empresarial para el sistema.
Deben identificarse todas las entidades
externas (personas y sistemas)

 que

interactuarn con el sistema y definirn

dichas interacciones.
Luego se usa esta informacin para valorar
la aportacin del sistema hacia la empresa.
Si esta aportacin es menor, entonces el
proyecto puede cancelarse despus de esta
fase.

 2.

Elaboracin Las metas de la fase de

elaboracin consisten en desarrollar la
comprensin del problema de dominio,
establecer un marco conceptual
arquitectnico para el sistema, disear el
plan del proyecto e identificar los riesgos
clave del proyecto.

 Al

completar esta fase, debe tenerse un

modelo de requerimientos para el sistema,
que podra ser una serie de casos de uso del
UML, una descripcin arquitectnica y un
plan de desarrollo para el software.

 3.

Construccin La fase de construccin

incluye diseo, programacin y pruebas del
sistema. Partes del sistema se desarrollan
en paralelo y se integran durante esta fase.

 Al

completar sta, debe tenerse un sistema

de software funcionando y la documentacin
relacionada y lista para entregarse al
usuario.

 4.

Transicin La fase final del RUP se

interesa por el cambio del sistema desde la
comunidad de desarrollo hacia la comunidad
de usuarios, y por ponerlo a funcionar en un
ambiente real.

 Esto

es algo ignorado en la mayora de los

modelos de proceso de software aunque, en
efecto, es una actividad costosa y en
ocasiones problemtica.
En el complemento de esta fase se debe
tener un sistema de software documentado
que funcione correctamente en su entorno
operacional.

 La

iteracin con el RUP se apoya en dos

formas. Cada fase puede presentarse en
una forma iterativa, con los resultados
desarrollados incrementalmente

Adems, todo el conjunto de fases puede

expresarse de manera incremental, como se
muestra en la flecha en curva desde
transicin hasta concepcin en la figura 2.12.

 El

RUP se dise en conjunto con el UML,

de manera que la descripcin del flujo de
trabajo se orienta sobre modelos UML
asociados, como modelos de secuencia,
modelos de objeto, etctera.

 En

la figura 2.13 se describen la ingeniera

central y los flujos de trabajo de apoyo.
La ventaja en la presentacin de las visiones
dinmica y esttica radica en que las fases
del proceso de desarrollo no estn
asociadas con flujos de trabajo especficos.

Figura 2.13 Flujos de trabajo estticos en el Proceso

Unificado Racional

 En

las fases iniciales del proceso, es

probable que se use mayor esfuerzo en los
flujos de trabajo como modelado del negocio
y requerimientos y, en fases posteriores, en
las pruebas y el despliegue.

 El

enfoque prctico del RUP describe las

buenas prcticas de ingeniera de software
que se recomiendan para su uso en el
desarrollo de sistemas. Las seis mejores
prcticas fundamentales que se
recomiendan son:

 1.

Desarrollo de software de manera iterativa

Incrementar el plan del sistema con base en
las prioridades del cliente, y desarrollar
oportunamente las caractersticas del
sistema de mayor prioridad en el proceso de
desarrollo.

 2.

Gestin de requerimientos Documentar de

manera explcita los requerimientos del
cliente y seguir la huella de los cambios a
dichos requerimientos. Analizar el efecto de
los cambios sobre el sistema antes de
aceptarlos.

 3.

Usar
arquitecturas
basadas
en
componentes Estructurar la arquitectura del
sistema en componentes, como se estudi
anteriormente en este captulo.

 4.

Software modelado visualmente Usar

modelos UML grficos para elaborar
representaciones de software estticas y
dinmicas.

 5.

Verificar la calidad del software Garantizar

que el software cumpla con los estndares
de calidad de la organizacin.

 6.

Controlar los cambios al software

Gestionar los cambios al software con un
sistema de administracin del cambio, as
como con procedimientos y herramientas de
administracin de la configuracin.

 El

RUP no es un proceso adecuado para

todos los tipos de desarrollo, por ejemplo,
para desarrollo de software embebido. Sin
embargo, s representa un enfoque que
potencialmente combina los tres modelos de
proceso.

 Las

innovaciones ms importantes en el
RUP son la separacin de fases y flujos de
trabajo, y el reconocimiento de que el
despliegue del software en un entorno del
usuario forma parte del proceso.

 Las

fases son dinmicas y tienen metas. Los

flujos de trabajo son estticos y son
actividades tcnicas que no se asocian con
una sola fase, sino que pueden usarse a lo
largo del desarrollo para lograr las metas de
cada fase.