CARLOS ANDRES CASTRO DIAZ

Modelado
La programación orientada a objetos es un paradigma de desarrollo, al igual que la programación
funcional o la programación imperativa.

El principio es que dentro del programa, todos los conceptos de negocio, las entidades de la "vida real", los
"actores" de los algoritmos, se representan por piezas de software llamadas "objetos". Los distintos
objetos del programa contienen datos y tienen un comportamiento definido por su implementación.
También interactúan entre sí, utilizándose mutuamente para llevar el programa a cumplir su objetivo.

Una de las etapas más importantes (si no la más importante), es el modelado del programa. Consiste en
enumerar los objetos que necesitará la aplicación y definir las relaciones entre ellos. Esta etapa puede
incluir varios niveles de abstracción más o menos altos: el nivel más alto puede incluir solo las grandes
partes de la arquitectura, el nivel más bajo solo presenta los objetos "finales" que realmente se
desarrollarán, con tantos niveles intermedios como sea necesario dependiendo de la complejidad del
proyecto.

Las partes de alto nivel no se preocupan por los problemas técnicos de la implementación: se trata de
ordenar los objetos que representan el problema que el software intentará resolver. También es muy útil
llamar a una persona del "negocio" durante la fase de modelado de un programa de software, para
asegurarse de que este se estructura de forma coherente con respecto al negocio.

Los modelos de bajo nivel afectan a las estructuras de datos, la gestión de la memoria, las
entradas/salidas, pero sin hacer referencia directa al lenguaje de programación que se utilizará. En la
práctica, es bastante ilusorio imaginar que un esquema como este permanecerá congelado en el tiempo:
surgirán problemas técnicos que requerirán un nuevo objeto aquí, una nueva relación allá, etc.

La etapa de modelado es un trabajo colaborativo entre personas potencialmente de diferentes áreas del
negocio. Por tanto, necesitamos un lenguaje común, que todos puedan entender, para poder llevar a cabo
esta tarea con éxito. En este caso, UML.

UML (Unified Modeling Language - lenguaje de modelado unificado) es un lenguaje visual creado en la
segunda mitad de la década de 1990 por Grady Booch, Ivar Jacobson y James Rumbaugh. Su objetivo es
producir un lenguaje estandarizado para visualizar el modelado de un programa. La estandarización es un
punto importante, porque al ser UML

© Éditions ENI - Todos los derechos reservados - Copia personal de CARLOS ANDRES CASTRO DIAZ -1-
 CARLOS ANDRES CASTRO DIAZ

una herramienta de comunicación, cualquier ambigüedad o incertidumbre en su definición lo convertiría

en una mala herramienta. Todo el software de modelado UML utiliza la misma representación gráfica y los
mismos términos para calificar los componentes de un esquema. Desde 2005, el lenguaje UML ha sido un
estándar ISO.

El modelado de un software desarrollado utilizando un lenguaje orientado a objetos es un paso

importante y un ejercicio de comunicación completo si el desarrollo se realiza en equipo. Es el cliente
quien expresa sus necesidades de negocio y depende de usted transcribirlas en UML. Como en toda
comunicación, pueden aparecer muchos malentendidos: dificultades de expresión, vocabulario diferente,
falta de atención, suposiciones, etc. El alma del software tomará forma dialogando, haciendo preguntas y
reformulando su punto de vista. Las líneas de código se entenderán mucho más fácilmente.

Si usted es el único que trabaja en el proyecto, esta etapa también le permite definir gráficamente la
arquitectura general del software y, si actúa correctamente, le obligará a enumerar las diferentes
funcionalidades a desarrollar.

Lanzarse a ciegas a un proyecto sin saber lo que quiere, o teniendo solo una vaga idea, supone una
enorme cantidad de tiempo perdido en volver atrás, buscar una solución que funcione, volver a desarrollar
partes del mismo que no son adecuadas, probar y volver a probar de nuevo lo que se ha hecho para
asegurarse de que el código siempre devuelva el resultado deseado, etc. Además, la forma en que aborda
el problema puede cambiar por completo de un día para otro, y los pensamientos que tuvo el lunes
pueden estar a años luz de los que tiene el jueves. Razón de más para fijar su arquitectura y anotar
comentarios si es posible, para que no pierda tiempo reflexionando sobre algo que ya ha tratado, pero que
ya no puede retomar.

En cualquier caso, un diagrama UML no garantiza que la arquitectura elegida sea la correcta, y
ciertamente, no es un documento escrito en piedra que no cambiará hasta el final del proyecto. A menos
que dedique mucho tiempo a pensar en ello, es imposible prever todos los problemas que surgirán
durante el avance del proyecto. Ya sea la incorporación de clases de herramientas para facilitar el trabajo,
la definición de nuevos miembros privados para garantizar buenos resultados de cálculo, la evolución del
perímetro funcional, etc. Todo ello modificará la cantidad de clases, su contenido y las relaciones entre
ellas. Esto es bastante normal: la teoría de UML se adapta a la realidad del software y se refina a medida
que evoluciona.

© Éditions ENI - Todos los derechos reservados - Copia personal de CARLOS ANDRES CASTRO DIAZ -2-