Este artículo tiene una finalidad divulgativa para quien no esté familiarizado con el desarrollo del software de alto nivel. También es de lectura recomendada para profesionales, dado que puede enfatizar usos del UML eventualmente subestimados o pasados por alto.
- Repasaremos en primer lugar el concepto de Programación Orientada a Objetos, conocida por su acrónimo inglés OOP (Object Oriented Programming).
- Seguidamente describiremos en el Lenguaje Unificado de Modelado, conocido también por su acrónimo UML (Unified Modeling Language) como notación de OOP.
- En tercer lugar, subrayaremos la importancia del modelo en una aplicación software.
- Por último, haremos énfasis en el UML como herramienta de desarrollo del software, orientado o no a objetos.
La orientación a objetos (OOP)
A la hora de construir un programa, una manera (un paradigma) de hacerlo es imaginarse que, en ejecución, un programa no es más que un conjunto de entidades, objetos, que interactúan entre ellos, mandándose mensajes.
Un objeto guarda información interna, y ofrece diferentes métodos que pueden ser invocados por otros objetos o mediante un evento que produzca que se ejecuten.
Así, por ejemplo, un objeto representando a un paciente de un hospital puede guardar internamente la fecha de nacimiento, y ofrecer un método que devuelva su edad. El método haría una resta cada vez que se le invoca, devolviendo el número de años que han transcurrido desde el nacimiento del objeto-paciente. Siguiendo con el mismo ejemplo, podríamos querer introducir el hecho de que objeto-paciente A es el hermano del objeto-paciente B, cosa que se dispararía por ejemplo al hacer click en un botón de una web.
UML nació en los 90 como estándar para representar la OOP.
El lenguaje unificado de modelado (UML)
Cuando se desarrolla un software en el que hay o bien un número muy alto de entidades interrelacionadas, o bien un número no muy grande pero con una complejidad apreciable en la manera en cómo se relacionan, resulta prácticamente imprescindible representarse ese microuniverso de objetos, de sus relaciones, de cómo interactuarán entre ellos, de cómo se desarrollará la secuencia de acontecimientos cuando queramos que el software implemente cada una de las situaciones. Para poder tratar con ello, UML ofrece muchas herramientas, de las cuales destacaremos tres:
- El diagrama de casos de uso: representar cada cosa que pueda querer hacerse con el software, por parte de qué actor.
Ejemplos de casos de uso para una tienda online: - "Alta artículo": un usuario administrador de una tienda online ("actor admin") tiene que poder dar de alta un nuevo artículo - "Pagar": un usuario comprador ("actor comprador") debería poder proceder a pagar, una vez llena la cesta de la compra. Este caso de uso puede convenir representarlo incluido en un caso de uso más genérico llamado "Comprar".
- El diagrama estático de clases: representar qué entidades hay que contemplar, y qué guardar de cada una, y qué relaciones con otras entidades pueden tener.
Ejemplos de clases para una tienda online: - "Artículo": representa un artículo de la tienda. Debería tener como mínimo un nombre, un conjunto de fotos relacionadas, y un precio según quién sea el comprador (si es extranjero puede por ejemplo pagar un impuesto diferente) "Comprador": representa un comprador, que es un usuario que además puede comprar. Un objeto comprador puede tener definida una relación de padrinaje con otro objetos-comprador, de tal forma que cuando compre su ahijado, él incremente un contador con el cual pueda tener un bono (sería un objeto-bono, que también hay que representar)
- Los diagramas de secuencia: representar la secuencia de acontecimientos cuando se lleva a cabo un caso de uso.
Ejemplo para pagar en una tienda online: La secuencia para pagar puede ser primero introducir la tarjeta y luego saltar a una web externa que sea la entidad bancaria, o saltar contando que ya en la web externa se le pedirá ese número (más conveniente en general, por tratarse de información sensible).
El modelo en un sistema software
Un sistema software requiere representarse de alguna manera lo más simple posible, y lo más completa y claramente posible, la información con la que tiene que tratar. Una vez está claro cómo representarse esa información, podemos programar de muchas maneras el cómo modificarla.
Un buen modelo tiene previsto ya en su concepción el que en un futuro pueda ampliarse sin ser muy traumático (sin tener que deshacer/rehacer mucha parte del mismo). Para ello, el ingeniero de software pacta con el usuario un modelo, antes de empezar a programar. A tal efecto dibuja, en una pizarra, o representa en hojas de cálculo datos reales, busca situaciones y cómo se guardarían en ese modelo. Tiene la gran responsabilidad, compartida con el usuario, de caer en la cuenta de lo que se requiere guardar, y de lo que es posible que se quiera guardar en probables ampliaciones del software.
El modelo es el corazón de un software. Todos los métodos más o menos bonitos, cómodos, ingeniosos para modificarlo, para tratar con él, lo hacen útil. Pero un sistema software es, en esencia, una manera de tratar información.
El UML como herramienta para el desarrollo
El estándar UML es una herramienta más en la mesa de cualquier ingeniero del software. Es tan o más importante que la pantalla, el teclado o el ordenador. Es mediante la notación UML (o una notación alternativa) con la que se concibe el software. Después, queda implementarlo, hacerlo realidad.
En el momento en que un sistema software está expresado mediante UML disponemos de lo que para un arquitecto serían los planos de un edificio. No en vano se usa el término arquitecto de software o arquitectura software. Cualquier programador experimentado sabe que no se puede contar con que esos planos sean exactamente lo que el software será, pero sí lo representan con la suficiente exactitud y completitud como para poder desarrollarlo y mantenerlo a un coste aceptable, esto es, sin que rehacer mucha parte de él.
Aunque no se utilice el paradigma de orientación a objetos, UML sigue siendo potente como representación de un software, para representar todo lo que puede pasar y para dividir el problema grande en problemas pequeños.
Lecturas recomendadas
- Página oficial de UML: http://www.uml.org/
- Para una buena introducción a la OOP y al UML: "Especificación de sistemas software en UML" Dolors Costal, M. Ribera Sancho, Ernest Teniente. Ediciones UPC, 2003. ISBN: 9788483017234