Modelamiento Logico de una base de datos

Los modelos  se  utilizan  en  todo  tipo  de  ciencias.  Su  finalidad  es  la  de  simbolizar  una
parte del mundo real de forma que sea más fácilmente manipulable. En definitiva es un
esquema mental (conceptual) en el que se intentan reproducir las características de una
realidad específica.
En el caso de los modelos de datos, lo que intentan reproducir es una información
real que deseamos almacenar en un sistema informático.
Se denomina  esquema  a  una  descripción  específica  en  términos  de  un  modelo  de
datos. El conjunto de datos representados por el esquema forma la base de datos.




clasificación de los modelos de datos
Esquema
Conceptual
Mundo
real Esquema
canónico
Esquema
interno BD
Físical
Modelo
Conceptual
Modelo
Lógico
Modelo
Interno
DBMS
Ilustración 5, Clasificación de los modelos de datos
En la ilustración anterior aparecen los distintos esquemas que llevan desde el mundo real
a la base de datos física. Como se ve aparecen varios esquemas intermedios. Los que están
más a la izquierda se alejan más de las características físicas. Los elementos de ese
esquema son:
€ Mundo real. Contiene la información tal cual la percibimos como seres humanos.
Es el punto de partida
€ Esquema conceptual. Representa el modelo de datos de forma independiente del
DBMS que se utilizará.
€ Esquema canónico (o de base de datos). Representa los datos en un formato
más cercano al del ordenador
€ Esquema interno. Representa los datos según el modelo concreto de un sistema
gestor de bases de datos (por ejemplo Oracle)
€ Base de datos física. Los datos tal cual son almacenados en disco. Diseño conceptual de bases de datos
modelado de datos
<16>
Para conseguir estos esquemas se utilizan modelos de datos. El paso entre cada esquema
se sigue con unas directrices concretas. Estas directrices permiten adaptar un esquema
hacia otro.
Los dos modelos fundamentales de datos son el conceptual y el lógico. Ambos son
conceptuales en el sentido de que convierten parámetros del mundo real en abstracciones
que permiten entender los datos sin tener en cuenta la física de los mismos.
diferencias entre el modelo lógico y el conceptual
€ El  modelo  conceptual  es  independiente del DBMS que se  vaya a utilizar. El lógico
depende de un tipo de SGBD en particular
€ El modelo lógico es más cercano al ordenador
€ Es más cercano al usuario el modelo conceptual, el lógico forma el paso entre el
informático y el sistema.
Algunos ejemplos de modelos conceptuales son:
€ Modelo E/R
€ Modelo RM/T
€ Modelos semántico
Ejemplos de modelos lógicos son:
€ Modelo relacional
€ Codasyl
€ Jerárquic

1- ETAPAS DE UNA METODOLOGÍA DE DISEÑO

En los últimos años venimos asistiendo, gracias al avance tecnológico, a una gran difusión de los SGBDR, cuyos productos se soportan en cualquier plataforma, desde los superordenadores a los ordenadores personales. Sin embargo, y a pesar del esfuerzo realizado por numerosos investigadores y estudiosos del tema, la concepción de una BD sigue siendo una tarea larga y costosa.

Estas dificultades inherentes al diseño de una base de datos han de afrontarse con procedimientos ordenados y metódicos en el marco de una metodología de diseño de bases de datos.

En el proceso de diseño de una base de datos hemos de distinguir tres grandes fases:

-          Diseño conceptual: cuyo objetivo es obtener una buena representación de los recursos de información de la empresa, con independencia de usuarios o aplicaciones en particular, y fuera de consideraciones sobre eficiencia del ordenador.

-          Diseño lógico: cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar. Nosotros nos vamos a referir al modelo relacional, pero de forma análoga se podría adaptar esta etapa de diseño lógico a otros modelos de datos, como el Jerárquico o el Codasyl.

-          Diseño físico: cuyo objetivo es conseguir una instrumentación, lo más eficiente posible, del esquema lógico.

Cuando estudiamos el papel de los modelos de datos en el diseño de las bases de datos, ya señalamos las ventajas de obtener, en una primera fase del diseño, un esquema conceptual independiente de las características de los modelos convencionales, como el modelo relacional, y que recogiese la semántica del mundo real.

Un problema que se suele presentar en el diseño de bases de datos es la comunicación entre el diseñador y el usuario; este último conoce bien el dominio de aplicación, lo que en general no ocurre con el diseñador, pero muchas veces no sabe expresarlo de forma correcta y, menos aun, precisa. La utilización del modelo E/R, en una primera fase del diseño, facilita el dialogo entre el informático, conocedor de las técnicas de estructuración de los datos pero ajeno al dominio de la aplicación, y el usuario, que suele conocer bien su mundo real pero que no es capaz de describirlo bajo las premisas que impone un modelo convencional.

El modelo E/R sencillo, pero a la vez suficientemente potente, permite entablar un diálogo entre el usuario y el diseñador que facilitara que se despejen dudas y aclaren aspectos del universo del discurso a modelar. Se facilita así la colaboración de los especialistas con los usuarios, de manera que estos últimos pueden participar activamente, e incluso ser protagonistas, en el diseño.

Podemos representar esquemáticamente las dos primeras fases (diseño conceptual y diseño lógico) de la metodología, en este ejemplo, en el cual aparece el proceso de diseño de una biblioteca; el diseñador observa el mundo real bajo unos ciertos objetivos (universo del discurso) y, apoyándose en una primera etapa en el modelo E/R, llega a un esquema conceptual, al cual se le aplicara un conjunto de reglas a fin de transformarlo en una estructura relacional (conjunto de tablas).

2- TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL AL RELACIONAL

El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes:

-          Todo tipo de entidad se convierte en una relación.

-          Todo tipo de interrelación N:M se transforma en una relación.

-          Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave o bien se crea una nueva relación.

A primera vista se puede observar que en el paso del modelo E/R al relacional pierde semántica, puesto que tanto las entidades como las interrelaciones se transforman en relaciones, de forma que ya no es posible distinguir entre unas y otras (en el modelo relacional) solo existe la relación para presentar ambos tipos de objetos).

También se constata que la perdida de semántica es aún mayor en el caso de la propagación de clave, donde desaparece incluso el nombre de la interrelación. Es preciso destacar que la perdida de semántica no implica, necesariamente, un peligro para la integridad de la base de datos, ya que, si la transformación se ha realizado correctamente, se habrán definido las necesarias restricciones (muy en especial las claves ajenas con sus opciones) que aseguraran la consistencia de los datos.

En el ejemplo, puede observarse que las tres entidades EDITORIAL, LIBRO y AUTOR se transforman en otras tantas relaciones. La interrelación N:M Escribe da lugar a una nueva relación ESCRIBE cuya clave primaria es la concatenación de los atributos identificadores de las entidades que participan en ella (nombre de AUTOR y código de LIBRO), siendo además estos claves ajenas de ESCRIBE que referencian a las relaciones AUTOR yLIBRO, respectivamente. La interrelación 1:N edita se transforma en la relación LIBRO la clave de la relaciónEDITORIAL (  a la que llamamos Editorial); atributo que será clave ajena de la relación LIBRO referenciando aEDITORIAL.

Las opciones de clave ajena en la transformación del ME/R al relacional

Si bien, insistimos, el paso del ME/R al relacional implica una cierta pérdida de semántica, se debe procurar que está perdida sea lo menor posible, además de asegurar al máximo la consistencia de los datos, es decir, la integridad de la base de datos en las operaciones de actualización. Las opciones de clave ajena, cuando se borran o modifican ocurrencias de la relación referenciada (“NO ACTION”,”SET NULL”,”CASCADE, y “SET DEFAULT”), nos pueden ayudar a cumplir este objetivo de mantener la integridad. Seguidamente analizaremos las posibles opciones de borrado y modificación asociada a las claves ajenas en los casos de propagación de clave y de creación de una nueva relación.

Read more »

Análisis y diseño orientado a objetos

Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En este método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.

UML es un lenguaje gráfico para construir modelos, no guía al desarrollador en la forma de realizar buenos análisis y diseños, ni le indica cual proceso de desarrollo adoptar. La idea de esta serie de artículos va más allá de aprender la notación UML utilizada para diseñar y construir sistemas software orientados a objetos de buena calidad independiente del proceso de desarrollo utilizado. Guiará al desarrollador principiante como yo a realizar buenos análisis y diseños orientados a objetos utilizando patrones de diseño.

El caso de estudio que vamos a tratar es el simulador de la cantera que he diseñado para las prácticas de la asignatura Ingeniería del software de la universidad. Voy a intentar realizarlo todo más o menos siguiendo la temática del libro UML y patrones de Craig Larman. De esta forma me sirve a mí mismo para mejorar la implementación y el diseño que realizé y afirmar todo lo aprendido. Como soy un novato principiante en este mundillo, si algún lector sigue mis artículos y encuentra alguna burrada sería recomendable que me avisara para rectificarlo. De todas formas este curso va a seguir una bibliografía recomendada así que me voy a basar en principios reales y no inventar conceptos nuevos.

En este curso, aprenderemos a crear modelos conceptuales del dominio del problema al que nos enfrentamos y a representarlos mediante diagramas de clases en UML.  Aprenderemos a extraer los casos de usos funcionales a partir de la especificación de requerimientos del sistema que vamos a desarrollar y a representarlos mediante diagramas de casos de uso en UML. Aprenderemos a realizar diagramas de secuencia, de colaboración y de estado en UML. Paralelamente a este curso voy a intentar redactar otros artículos dedicados exclusivamente a los patrones de diseño, esta vez sin seguir un caso de uso, sino a partir de ejemplos donde podamos aplicarlos.

Este proyecto puede durar mucho tiempo, debido a que paralelamente estoy redactando otros cursillos de PHP, y MySQL que incorporar al blog. Además en unas semanas empiezo a trabajar diseñando una aplicación de gestión inmobiliaria, así que no voy a tener mucho tiempo libre.

En breves os explicaré el caso de estudio y realizaremos una especificación de funcionalidades que incorporar a nuestro sistema software. La implementación la desarrollaremos en el lenguaje C#. Para este curso voy a presuponer que se tienen ciertos conocimientos de la metodología orientada a objetos, así como del lenguaje C# y de construcción de aplicaciones mediante formularios windows. No va a tener acceso a base de datos para simplificar un poco el desarrollo. Ya explicaré el sistema que realizaremos para cargar y guardar datos.

Read more »

Arquitectura en Capas

Por qué es tan importante la programación por capas?

Visual Basic .NET es un lenguaje POO (es decir, Programación Orientada a Objetos) desde su versión 2002, que fue el salto definitivo del antiguo y arcaico Visual Basic 6.

Este salto supone muchas ventajas, ya que permite la creación de clases (como indica su definición, permiten la Herencia, etc… ya lo explicaré más en profundidad en otra ocasión)

Y es aquí donde intervienen las capas, ya que las capas pueden ser conjuntos de clases y, en caso de ser un equipo de desarrollo de software, cada grupo se podría ocupar de programar una capa en concreto y así optimizar el proceso de mejoría en los programas, ya que se tardará menos tiempo en lanzar una nueva versión.

Es decir, puedes mejorar la capa de datos (mejoría en la gestión de consultas, etc….) sin que la capa de negocio se vea afectada, por ejemplo. Programar un poco por módulos.

Además, las capas no hacen falta que estén todas en el mismo ordenador, sino que en caso de tener una red LAN, cada capa puede estar en un PC distinto tal y como se puede apreciar en la siguiente imagen:

• Capa de presentación
• Capa de negocio
• Capa de datos

• La capa de la  Presentación
  Esta capa reúne todos los aspectos del software que tiene que ver con las interfaces y la interacción con los diferentes tipos de usuarios humanos Estos aspectos típicamente incluyen el manejo y aspecto de las ventanas, el formato de los reportes, menúes,  gráficos y elementos multimedia en general.
   
• La capa del Dominio de la Aplicación
  Esta capa reúne todos los aspectos del software que tienen que automatizan o apoyan los procesos de negocio que llevan a cabo los usuarios. Estos aspectos típicamente incluyen las tareas que forman parte de los procesos, las reglas y restricciones que aplican. Esta capa también recibe el nombre de la capa de la Lógica de la Aplicación.
   
• La capa del Repositorio
  Esta capa reúne todos los aspectos del software que tienen que ver con el manejo de los datos persistentes, por lo que también se le denomina la capa de las Bases de Datos).

RPM toca muy superficialmente los problemas asociados al desarrollo de una capa de Presentación. Menciona que es conveniente usar un enfoque de prototipaje y que pueden ser útiles los casos reales de uso; sin embargo no proporciona métodos, principios o lineamientos metodológicos que apoyen el desarrollo de una metáfora de diseño para la interfaz, el diseño lógico de la presentación o su diseño físico.

RPM tampoco proporciona muchas luces sobre el desarrollo de la capa del Repositorio y tiende a subestimar su complejidad.

Una vez elaborado el Modelo de Uso, RPM recomiendo seguir con actividades de análisis de requerimientos. Para ello se elabora un Modelo Conceptual, en el cual se busca identificar los conceptos importantes del dominio de la aplicación, abstrayendo todo lo que puedan ser mecanismos o conceptos propios de un diseño o de una implementación. Así, en el ejemplo de un Sistema de Punto de Venta, nos interesan los conceptos como Venta, Recibo, Efectivo, Cheque, Impuesto que tienen que ver con los procesos de negocio que se están apoyando y no nos interesan conceptos como Menú, Ventana, Tabla relacional, Consulta a Base de Datos que tienen que ver con cómo mejor implementar los conceptos del negocio. La mayoría de estos elementos de un Modelo Conceptual terminan agrupándose naturalmente en la capa del Dominio de la Aplicación.

Este enfoque de RPM termina por sesgar la metodología hacia el desarrollo de la capa del Dominio de la Aplicación, y en la práctica, tiende a hacer presuponer que el desarrollo de las otras capas se puede ajustar al diseño de la capa del Dominio de Aplicación, lo cual no es siempre el caso, incluso dentro del ámbito de los Sistemas de Información.

Antes de estudiar el Modelo Conceptual, nos conviene aclarar qué es una arquitectura de capas, su importancia e implicaciones, para tener mayor claridad en los riesgos que corremos al adoptar una metodología como RPM.
 

Arquitectura de Capas

• Preguntar qué conocen por arquitectura de capas (en Sistemas de Operación, Redes de Computadores...).

§  Nos limitaremos a manejar la noción de arquitectura como una forma de estructurar los elementos de un software.

§  En toda arquitectura de capa los elementos agrupados en una misma capa pueden comunicarse entre si; pero existen variantes en cuanto a las comunicaciones permitidas entre elementos de capas diferentes:

1. Arquitectura top-down de capas:
   Los elementos de una capa i+1 pueden enviar solicitudes de servicio a elementos de la capa inferior i. Típicamente se produce una cascada de solicitudes, es decir para satisfacer una solicitud a una capa i+2, ésta requiere enviar varias solicitudes a la capa i+1; cada una de estas solicitudes a la capa i+1 genera a su vez un conjunto de solicitudes a la capa i y así sucesivamente.  Una arquitectura top-down es laxa (o no estricta) si los elementos de una capa i+1 pueden enviar solicitudes de servicio directamente a un elemento de cualquiera de las i capas inferiores.
    
2. Arquitectura bottom-up de capas:
   Cada elemento de una capa i puede notificar a elementos de la  capa superior i+1 de que ha ocurrido algún evento de interés (ej. manejadores de dispositivos). La capa i+1 puede juntar varios eventos antes de notificar a su vez an elemento de la capa i+2. Una arquitectura bottom-up tambien puede ser no estricta si el elemento de la capa i puede notificar a cualquier elemento de cualquier capa superior a la capa i.
    
3. Arquitectura bidireccional de capas
   En su forma más común involucra dos pilas de N capas  que se comunican entre si. El ejemplo más conocido es el de los protocolos en Redes de Computadores.

Al implementar una arquitectura top-down  de capas, se deben tomar en cuenta los siguientes factores:

1. ¿Cuál es el criterio de abstracción para agrupar servicios/clases en una capa?
   Mencionar el criterio Presentación-Dominio de Aplicación-Repositorio de Sistemas de Información.
    
2. Determinar el número de capas
   En términos simplistas, a más capas más flexibilidad pero menor desempeño. [Discutir]
    
3. Típicamente las capas más internas ofrecen menos servicios.
   Esto ayuda la reutilización de capas ("pirámide invertida de reuso").
    
4. El grado de encapsulamiento de las capas.
   A mayor encapsulamiento, menor dependencia externa sobre la estructura de una capa.
    
5. Estructura interna de cada capa.
    
6. ¿Cuánta información pasar de una capa a otra?
   Tomemos el caso de la arquitectura top-down. Es muy posible que, de acuerdo con el tipo de servicio solicitado, la capa inferior requiera una cantidad de información variable. En un modelo puro "empujado" (push), la capa superior está obligada a enviarle toda la información que pueda llegar a hacerle falta a la capa inferior en la solicitud.

Esto no siempre es posible (piense por ejemplo en una solicitud de servicio a una base de datos que no logra completarse por estar fuera de línea. ¿Qué se hace: reintentar, abandonar, usar una fuente alterna?).

En el modelo contrario, "halado" (pull o por demanda), la capa inferior solicita mayor información sólo si le hace falta --¿pero de quién la pida? El modelo de solicitudes top-down presupone un invocador anónimo y un invocado conocido.

La solución la proporciona el patrón Editorial-Suscriptor (Publish-Subscribe) que encapsula la idea del callback.  Este patrón de diseño lo estudiaremos más adelante.
 

7. Diseñe la estrategia de manejo de errores. Este es un aspecto que es frecuentemente obviado, aunque tiene impacto fuerte tanto en el tiempo de procesamiento como en el esfuerzo de programación. Típicamente se recomienda manejar el error en el nivel que lo descubrió, si esto no es posible, dejar que lo resuelva la capa más arriba, pero generalmente abstrayendo el tipo de error para que sea comprensible en término de los servicios de la capa superior.

Todo patrón tiene ventajas  y desventajas: en el caso de la arquitectura de capas ya las hemos mencionado [dejar que los estudiantes las resuman]:

• Ventajas
• Reutilización de capas;
• Facilita la estandarización
• Dependencias se limitan a intra-capa
• Contención de cambios a una o pocas capas
• Desventajas
• A veces no se logra la contención del cambio y se requiere una cascada de cambios en varias capas;
• Pérdida de eficiencia;
• Trabajo innecesario por parte de capas más internas o redundante entre varias capas;
• Dificultad de diseñar correctamente la granularidad de las capas.

Existen tres propuestas de arquitecturas de capas para Sistemas de Información, donde las capas a veces reciben el nombre de niveles (en Inglés tiers):

• Arquitectura de dos capas;
• Arquitectura de tres capas;
• Arquitectura de cuatro capas.

Dos capas

En la actualidad muchos sistemas de información están basados en arquitecturas de dos capas, denominadas:

• Nivel de aplicación;
• Nivel de la base de datos.

Existen herramientas de amplio uso que presuponen esta estructura (p. ej. Visual Basic + Access/SQL server). Estas arquitecturas fueron las primeras en aprovecharse de la estructura cliente-servidor (aplicación en los clientes, base de datos como servidor). Las desventajas de dos niveles son bien conocidas:

• El nivel de las aplicaciones se recargan, entremezclando aspectos típicos del manejo de la interfaz con las reglas del negocio;
• Las reglas del negocio quedan dispersas entre el nivel de aplicación y los "stored procedures" de la base de datos;
• La aplicación queda sobrecargada de información de bajo nivel si hay que extraer los datos de varias bases de datos, posiblemente con estructuras diferentes.
• El nivel de aplicación puede ser demasiado pesado para el cliente.
   

Tres capas

Por estas razones, existe una fuerte y bien avanzada tendencia a adoptar una arquitectura de tres capas:

• Aplicación [ojo!]
• Dominio de la aplicación;
• Repositorio.

La mayoría de estos sistemas buscan conservar la tecnología de BD relacional para la capa del repositorio e introducir la tecnología OO para el dominio de la aplicación. Para la capa de presentación existe una pelea entre tecnología HTML (Java-enabled) vs. generadores GUI.

¿Qué contiene el dominio de la aplicación? En terminología más clásica de BD los tres niveles pueden equipararse, a grosso modo, con:

• Esquema externo;
• Esquema conceptual;
• Esquema interno o de almacenamiento.

La ventaja es que ahora la aplicación puede describirse  únicamente en relación a la semántica de la aplicación, sin tener que preocuparse sobre cómo está implementado ese dominio (ubicación y estructura física de la data).

****Un punto interesante es dónde ubicar el nivel del dominio de la aplicación, ¿en el lado del cliente o en el lado del servidor? Hay ventajas y desventajas asociadas con cada alternativa, al estudiante interesado le recomiendo el excelente análisis del Fowler (sección 12.2.1, vp. 243-245).

  

Cuatro capas

Los desarrollos más recientes empiezan a experimentar con una capa adicional (para 2000 no había visto evidencia de esto en Venezuela):

• Presentación;
• Aplicación;
• Dominio de la aplicación;
• Repositorio

La idea básica es separar todo lo que es programación GUI de la aplicación per se (y por ende tiende a usar frameworks para GUI como MFC). El nivel de la presentación no hace cálculos, consultas o actualizaciones sobre el dominio --de hecho nisiquiera tiene visibilidad sobre la capa del dominio. La capa de la aplicación es la encargada de accesar la capa del dominio, simplificar la información del dominio convirtiéndolo a los tipos de datos que entiende la interfaz: enteros, reales, cadenas de caracteres, fecha y clases contenedoras (container, collection).

Una forma de organizar esta nueva capa de la aplicación es considerarla una fachada al dominio. Cada aplicación presenta una fachada diferente (y simple) del dominio a la interfaz. Las ventajas de las cuatro capas se encuentra nuevamente en el texto de Fowler(sección 12.3.1, vp. 249-250). En la sección siguiente del mismo texto se argumenta que el patrón Proxy puede aplicarse a la capa de la aplicación, de forma de tener una parte de la capa en el cliente y otra en el servidor. Los detalles pueden consultarse allí.

Finalmente resulta interesante discutir el acoplamiento entre la capa del dominio y la capa del repositorio. Por falta de tiempo, prefiero posponer este acoplamiento hasta la próxima clase.

 

***De hecho, en el libro de Larman el diagrama de clases que se presenta como parte del modelo conceptual es el diagrama conceptual del dominio de la aplicación.

Read more »

Programación Orientado a Objetos

INTRODUCCIÓN

La programación orientada a objetos es una “filosofía”, un modelo de programación,
con su teoría y su metodología, que conviene conocer y estudiar antes de nada. Un
lenguaje orientado a objetos es un lenguaje de programación que permite el diseño de
aplicaciones orientadas a objetos. Dicho esto, lo normal es que toda persona que vaya a
desarrollar aplicaciones orientadas a objetos aprenda primero la “filosofía” (o adquiera
la forma de pensar) y después el lenguaje, porque “filosofía” sólo hay una y lenguajes
muchos

Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad:

• El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
• El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.
• La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o unaconstante).

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

[editar]Origen

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffelde Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha modificado, soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

[editar]Conceptos fundamentales

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

• Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
• Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
• Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
• Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
• Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
• Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
• Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
• Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
• Componentes de un objeto: atributos, identidad, relaciones y métodos.
• Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

[editar]Características de la POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las características siguientes son las más importantes:

• Abstracción: denota las características esenciales de un objeto, donde se capturan sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

• Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar lacohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

• Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

• Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
• Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
• Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos enclases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.
• Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

Read more »