Deficiencias de la programación estructurada
Un poco de historia
·
1968. Crisis del software. Nace la programación
estructurada
·
1985. C++ se posiciona en el Mercado como lenguaje
orientado a objetos
·
1996. Lanzamiento de Java al Mercado
El desarrollo de
software estructurado
Módulo: Conjunto de
subrutinas y declaraciones de tipos y constantes
El enfoque estructurado implica que:
El ladrillo con el que se construye el sistema es
la subrutina. El modulo es la -entidad que las agrupa.
è Los datos
que maneja del sistema van pasando por las distintas subrutinas que los
procesan
è Existe
una total independencia entre los datos y los procesos (los datos van de paso,
se encuentran con las subrutinas y siguen su camino)
Las deficiencias del enfoque estructurado
son:
è Los
problemas a resolver hay que traducirlos a la forma de pensar de la máquina (datos
y procesos independientes)
è El ser
humano piensa en objetos que tienen unas propiedades y unos comportamientos
(los datos y procesos forman una unidad coherente)
è Esta
diferencia a la hora de expresar la realidad dificulta la comunicación entre el
cliente y el equipo de desarrollo.
è El
enfoque estructurado limita la capacidad de abstracción, con lo que obtenemos
soluciones más dificiles de desarrollar, probar, documentar, mantener y
reutilizer
Principios de la programación orientada a objetos
Primer principio: Todo es un objeto
Este
principio sostiene que cualquier problema se puede modelar como un conjunto de
objetos.
Según la
RAE: un objeto es todo lo que tiene entidad, ya sea real o abstracta. Ejemplos:
un coche, una persona, un pedido, una factura…
Una base
de datos, una ventana, una conexión…
Un objeto
se caracteriza por:
è Unas
propiedades: color, tamaño, forma, estado…
è Unos
comportamientos: escribir, rotar, arrancar, volar…
Ejemplos:
è Mechero
BIC
o Propiedades:
Longitud = 5cm, peso = 10gr, mililitros de gas restante = 5ml, está encendido =
FALSE
o Comportamientos:
encender, apagar, rellenar gas…
è Avión
Boeing 747
o Propiedades:
Peso = 10T, potencia = 200KCV, número máximo de pasajeros = 200, número actual
de pasajeros = 130, está el motor arrancado = TRUE, está en tierra = FALSE
o Comportamientos:
arrancar motores, parar motores, despegar, aterrizar, subir / bajar un
pasajero…
Importante:
Los objetos siempre deben ser coherentes con su ESTADO INTERNO
Segundo principio: Todo objeto es de algún
tipo
¿Qué es lo
que hace que dos mecheros de marcas distintas y con propiedade distintas los
clasifiquemos bajo el mismo concepto?
Si saco
un objeto que parece una pistola y al presionar el gatillo sale una llama del
cañón, ¿diremos que tengo una pistola o un mechero?
El
conjunto de comportamientos esperados de un objeto es lo que determina a qué
tipo o CLASE pertenece.
Una CLASE
es la abstracción de las propiedades y de los comportamientos de un conjunto de
objetos.
Ejemplo
de clase y objeto:
La clase
es como el PLANO o el MOLDE con el que se construyen los objetos. Es la “fábrica”
de los objetos.
El segundo
principio decía: todo objeto es de algún tipo, es decir, debe ser creado a
partir de una clase o tipo.
A los
objetos que se crean a partir de una clase se les llama instancias de la clase.
En el ejemplo anterior, el objeto ‘mechero BIC’ es una instancia de la clase
mechero.
Hay que
distinguir claramente ambos conceptos
Clases:
è No tiene
existencia real, son solo el molde de creación de los objetos
è Son
elementos estáticos, no evolucionan en el tiempo
è De una
clase se puedan crear muchos objetos (instancias)
Objetos
è Tienen
existencia real y unas propiedades con valor concretos
è Son
elementos dinámicos, su estado evoluciona durante la marcha del programa
è Un objeto
solo puede ser creado a partir de una clase
Tercer principio: Los objetos se comunican
mediante mensajes
Los
mensajes son las peticiones que un objeto realiza a otro para que éste ultimo ejecute
alguno de sus comportamientos.
Ejemplo:
Fumar hará
una petición a encender() y fumar la hará a apagar()
Cuarto principio: Una aplicación orientada a
objetos es una COMUNIDAD DE OBJETOS que nacen (se crean), interactúan (se mandan
mensajes) y mueren (se destruyen)
Diagramas de clases y objetos en UML
Para
denotar nuestras clases, objetos y sus interacciones usaremos la notación UML.
·
UML (unified modeling language = lenguaje de
modelado unificado) es el lenguaje diagramático más usado para representar
sistemas orientados a objetos
Empezaremos
con lo básico y ampliaremos la notación a medida que nos haga falta.
Representación de una clase UML
Representación de objeto en UML
Arquitectura basada en tres capas
Cuando desarrollamos una aplicación (ya sea orientada a objetos o
estruturada) podemos asemejar la tarea a la construcción de un edificio.
·
Capa persistencia: Se ocupa del almacenamiento de
información conectando directamente con la base de datos.
·
Capa del negocio: Realiza todas las operaciones
·
Capa de presentación: Se encarga del diseño. La
interfaz
1. El
usuario solicita un servicio mediante la capa de presentación
2. El
sistema resuelve la petición en la capa del negocio
3. La capa
del negocio se apoya en la capa de persistencia que se encarga de guarder y
recuperar objetos de la base de datos
0 comments:
Publicar un comentario