Considerando Objetos

 

Autor: Jose Alfredo Castillo - Estudiante de la UFG

El diseño orientado por objetos (DOO), como otras metodología de diseños orientados a la información crean una representación del dominio del problema en el mundo real y lo transforma en un dominio de soluciones que es el software.

 

A diferencia de otros métodos, el DOO da como resultado un diseño el cual interconexiona los objetos de datos (elementos de datos) y las operaciones de procesamiento, de forma tal que encapsula la información y el procesamiento.

"Este encapsulamiento es el paradigma fundamental de la orientación por objetos"

Pero, se tiene tres conceptos importantes del diseño del software, los cuales son:

• Abstracción.
• Ocultamiento de la información.
• Modularidad.

¿Qué es la orientación por objeto?

El término "orientación por objeto" significa que organizaremos el software como una colección de objetos discretos que incorporan tanto estructuras de datos como procedimientos.

¿Qué es el desarrollo Orientado por Objetos?

El desarrollo orientado por objetos es una nueva forma de pensar acerca del software basado sobre abstracciones que existen en el mundo real.

 

Ademas, debemos conocer los constructos básicos de la programación Orientada por objetos, los cuales son:

1. Objeto.
2. Identidad del objeto.
3. Clase.
4. Métodos.
5. Polimorfismo.
6. Herencia.
7. Encadenamiento dinámico

Tambien, debemos saber que podemos considerar como objetos en la programación:

Debemos de considerar como objetos lo siguiente:

• Persona.
• Equipo Hardware.
• Materiales.
• Información.
• Software.
• Procesos.
• Procedimientos 

Un ejemplos seria:

• Se tiene un objeto llamado: horno.
• Sus operaciones asociadas son las siguientes: Encendido, apagado, cargado y descargado.
• Sus operaciones son: Agregar, eliminar, verificar vacía, verificar si llena, primero cola y siguiente cola.

Componentes para la construcción de Software de un objeto

Cuando un objeto se transforma en una realización de software, consta de una interfaz, una estructura de datos privada y unos procesos llamados operaciones o métodos que son los únicos que pueden transformar legítimamente la estructura de datos.

En la orientación a objetos, se trabajo con:

• Clases y objetos.
• Diagramas de clases.
• Diagramas de interacción entre objetos.
• Patrones de diseño.
• Herencia, polimorfismo, sobrecarga de operadores.
• Etc.

Conceptos de Diseño

Los tres conceptos claves para la calidad de un diseño (además de ser correcto, claro), son:

Acoplamiento (bajo): Captura la fuerza de interconexión entre módulos y cuánto más acoplados existe más dependientes entre si, entonces, más difícil comprenderlos y modificarlos.

Cohesión (alta): Se focaliza en conocer porqué los elementos de un módulo están juntos en ese módulo.

Principio abierto-cerrado (cumplir con el principio): Tiene como objetivo, promover la construcción de sistemas que sean fáciles de modificar. Módulos abiertos para la extensión:

"el comportamiento puede ser extendido".

Metodología de Diseño

Existen varias, pero siempre es una actividad creativa por lo que no es un conjunto de pasos que mágicamente produce un diseño.

Ademas, se asume que durante el diseño de la arquitectura, se partió el sistema en varios subsistemas.

Por lo tango, se va a producir un diseño orientado a objetos; entonces, el problema que se ataca es cómo producir un diseño orientado a objetos de un subsistema.

Diagrama de clases

Un diagrama de clases está compuesto por los siguientes elementos:

• Clase: Atributos, métodos y visibilidad.
• Relaciones: Herencia, composición, agregación y asociación y uso.

Ademas; en UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

• Superior: contiene el nombre de la clase.
• Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la clase (pueden ser private, protected o public).
• Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno.

Ejemplo: 

Una cuenta corriente que posee como característica: 

• Balance 

Puede realizar las operaciones de: 

• Depositar 
• Girar 
• Balance 

El diseño asociado es: 

Relaciones entre Clases

Ahora ya definido el concepto de clase, es necesario explicar cómo se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende,  la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).

Agregación:

Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer OBJETOS QUE SON INSTANCIAS DE CLASES definidas por el desarrollador de la aplicación.

Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. 

Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

Clase parametrizada 

Ejemplo: 

Suponga que se tiene el caso de un Diccionario implementado mediante un árbol binario, en donde cada nodo posee: 

• key: variable por la cual se realiza la búsqueda, puede ser genérica. 

• item: contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede ser genérico. 

Para este caso particular se ha definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como ítems, solo se mostrarán las relaciones para la implementación del Diccionario.

Ahora, que ya hemos explicado los aspectos mas importantes sobre el tema "considerando los objetos", respondo a la siguiente pregunta "¿Cómo diseñan ustedes?"

Acorde a mi experiencia laboral (tomando de base uno de los proyectos en donde trabajo), describo los pasos que sigo para diseñar un sistema:

1. Se tienen las reuniones necesarias con los usuarios, para el levantamiento de requerimientos.
2. Se hace una minuta con todos los requerimientos levantados en las reuniones, y las firman mi persona y miembros de las reuniones.
3. Se procede a definir los requerimientos funcionales y no funcionales, acorde a un formato establecido que la empresa utiliza.
4. Luego, se les vuelve a presentar los requerimientos detallados a los usuarios para que no se vaya a omitir nada. Si todo esta bien, todos firmamos el documento de requerimientos.
5. Luego, se crean las pantallas de cada modulo del software (un mockup ), se definen los tiempos y entregables con mucho valor para los usuarios.
6.  Despues, se tiene otra reunión para mostrarles el diseño (mockup) que tendrá el sistema para que el mismo usuario, diga si todo esta bien o si necesita algún cambio. Ademas, se les presenta los tiempos y entregables que se harán.
7. Si el usuario dio su OK, nosotros los programadores ya iniciamos con la respectiva documentación del sistema: Casos de uso, diagramas del sistema propuesto, diagrama de procesos, diagramas de secuencia, diagrama de clases, diagrama de perfiles, diagrama de componentes, diagrama de bases de datos, un diccionario de datos de la base de datos.
8. Ya teniendo bien definido lo que haremos, se definen los sprint con las historias de usuarios y cada sprint es un entregable para el usuario (definidos anteriormente y presentados a los usuarios mencionado en el paso 5).
9. Se define una tarea en el sprint para crear la arquitectura del software (Se trabaja con arquitectura N-Capas y los sistemas son MVC usando el patron Modelo-Vista-Controlador).
10. Se inicia con el desarrollo.
11. Cada ves que terminamos una historia, se le presenta al Product Owner (PO) y si todo esta bien, la finalizamos y pasamos a la siguiente historia.
12. Al finalizar el sprint, se procede a realizar el proceso de validación de código, coordinaciones y puestas en producción. "Cabe mencionar que en cada sprint se entrega un valor al usuario y cuando se pone en producción, el usuario ya ha validado cada detalle para que no haya ningún inconveniente en producción".

Este tema es muy amplio, pero he tratado de explicarles los aspectos más relevantes de esta temática.

Por el momento esto seria todo; sin embargo, esperen más aportes sobre "considerando objetos", seguiré publicando más foros.

Saludos.