UML

     Al hablar de un sistema de información o software debemos tener en cuenta que antes hay que definir sus partes, realizar una especie de "plano" o modelado de lo que se desea obtener del sistema en cuestión: funcionalidades, objetivos, maneras para lograrlo, usos posibles, necesarios y opcionales, y una gama de componentes más que tienen relación con el modelo que buscamos realizar. Pero surge un problema, ¿Qué es un modelo? Pues Booch, Rumbaugh y Jacobson definieron en 1999 un modelo como "una simplicidad de la realidad"; una manera con un nivel de abstracción tal que permita obtener sólo lo relevante al problema que deseamos solucionar para enfocarnos en ello. 

   Estas tres personas mencionadas previamente son importantes al hablar sobre el Lenguaje Unificado de Modelado (UML por sus siglas en inglés) ya que fueron ellos quienes realizaron la propuesta de usar una semántica universal para diseñar el plano y toda la documentación previa al desarrollo del software, ya que anterior a esta propuesta no había nada concreto y entre programadores podía haber confusión sobre lo que se quería representar del sistema, ya que no todos tenemos el mismo nivel ni capacidad de abstracción. Ante esta problemática fue que se hizo la propuesta del UML en 1995, que sería posteriormente aprobada por la Organización Internacional de la Normalización (ISO) para ser adaptado como el lenguaje más común para realizar diagramas sobre sistemas. Aunque es el lenguaje más usado, no es el único lenguaje existente en el modelado de sistemas, pero nos enfocaremos únicamente en este. 

     El UML se basa en el método Booch, que es un lenguaje de modelado de objetos, ampliamente usada en la ingeniería de software para el diseño y el análisis orientado a objetos por su representación gráfica que ahora utiliza UML; en la técnica de Modelado de Objetos (OMT), de la cual adquiere los tipos de clase (específicas y generales), las relaciones de asociación o los símbolos de generalización; y en la Ingeniería de Software Orientada a Objetos (OOSE), de la cual obtiene los "casos de uso" que fue una de las principales características de OOSE, pero al igual que los otros dos lenguajes pertenecientes a la cuña base del UML, han quedado obsoletos por la aparición del mismo. 

   Este lenguaje está enfocado más que todo en la programación orientada a objetos y esto es apreciado fácilmente, no sólo por la base que le dio vida al UML sino también por los distintos diagramas que lo componen:  

• Diagramas de Estructura. 
• Diagramas de Comportamiento.
• Diagramas de Interacción.

     Entre los diagramas de estructura tenemos el diagrama de clases, que es uno de los diagramas que trabajaremos en el aula de clase, por tanto será uno a los que demos mayor énfasis. 

     El diagrama de clases es un diagrama de estructura estática que sirve para visualizar más eficientemente las distintas clases del sistema, sus atributos, operaciones y la relación con otros objetos del sistema que se esté modelando. Es importante definir una clase, para poder saber cómo se debería estructurar el diagrama, partiendo de esto podemos decir que una clase son varios elementos que comparten una serie de atributos, operaciones y relaciones dentro del sistema, pudiendo así agruparlos dentro de un único objeto que represente a esos elementos ahí encontrados. Hay elementos que tienen atributos y/u operaciones en común, pero otros muchos en los que difieren, por ejemplo: si tuviésemos una clase llamada vehículos, los vehículos todos tienen una atributo en común: permiten la movilización, pero tenemos diferentes tipos de vehículos, bien sean terrestres, aéreos, acuáticos, incluso hasta espaciales. Es aquí donde UML tiene en su diagrama de clase la característica obtenida de la OMT, que son clases generales y clases específicas, representando en una clase generalizada llamada vehículo, la cual podría tener atributos tales como Velocidad, Combustible; que serían atributos generales que heredan las clases específicas que se desprendan de él. Hemos escogido estos dos atributos como generales porque todo vehículo tiene una velocidad a la que se mueve y usa un tipo de combustible, por lo tanto puede ser una clase general para que todos los vehículos, sin importar sus especificaciones, tengan estos atributos. 

     En clases específicas tendríamos, por ejemplo: carro, avión, moto, helicóptero. Todas estas son vehículos, por lo tanto comparten las mismas características de la clase general, pero tienen atributos diferentes en sí: tamañoRin sería un atributo de las motos y los carros, pero que no aplicaría para algunos helicópteros, así mismo longitudHélices sería un atributo de helicópteros, pero que no aplicaría para los carros o motos, sin embargo podrían cumplir con dicha características uno que otro avión. Tenemos también el siguiente ejemplo: 

     El diagrama de casos de uso sirve para representar al actor principal o usuario del sistema interactuando de las diferentes maneras posibles con el software para poder tener una idea de las necesidades del sistema, pero no sólo así con el actor principal ya que hay otros usuarios secundarios que no son parte directa del sistema, pero el mismo podría interactuar con ellos para lograr su objetivo. Los diagramas de caso de uso se pueden representar de manera narrativa y gráfica. Aquí dejaré un ejemplo de manera gráfica de un diagrama de caso de uso de un restaurante y más adelante veremos cómo se trabaja de manera narrativa este tipo de diagrama de comportamiento. 

Fin del décimo post.

Tiempo tomado para investigar y redactar: 6 horas.

Autor: Daniel Marcano.

Fuentes: www.wikepedia.org