UML Capítulo 6: Vista Estática I

¡Hola de nuevo internauta!,

      Cómo vimos anteriormente la vista estática modela conceptos del dominio de la aplicación por lo que podemos resumir sus características en los siguientes puntos:

• Captura la estructura de los objetos.
• Describe las declaraciones de comportamiento pero no los detalles de dicho comportamiento (eso se hace en otras vistas).
• Es la base para el resto de vistas.
• Sus elementos claves son los clasificadores (describen cosas que contienen valores) y sus relaciones (asociación, generalización y varios tipos de dependencias).

1. Clasificadores

Es un elemento de la vista estática que modela un objeto cuyas características son:

• Identidad: Es único aunque pueden existir varios objetos del mismo tipo (clases, actores, etc).
• Estado: Tiene datos asociados a él.
• Comportamiento: Se le pueden hacer cosas con él y puede hacer cosas a otros objetos.
• Relaciones: El objeto puede o no tener relaciones con otros objetos 
• Estructura interna opcional.: Algunos clasificadores pueden tener una estructura interna opcional (las clases) y otros no (actor).

Tipos

La siguiente tabla indica los distintos tipos de clasificadores existentes:

            Clasificador: Nombre del clasificador.
            Función: Breve explicación sobre lo que representa.
            Notación: Cómo se representa de manera visual.

A continuación definiremos los clasificadores más usados, a saber, clase; interfaz y tipo primitivo quedando para sucesivas entradas el resto. ¡No os agobiéis que habrá para todos!.

Clase

La clase cumple con los siguientes preceptos:

• Representa un elemento de un tipo particular, p. ej. : un vehículo.
• Es el descriptor para aquellos objetos con similar estructura, comportamiento y relaciones poseyendo un estado y una descripción. Tomando el ejemplo del punto anterior, la clase vehículo describe a motos, coches, camiones, y sí, bicicletas. El estado se describe mediante atributos (valores puros sin identidad) y asociaciones (conexiones entre los objetos con identidad). Las piezas individuales de comportamiento que se pueden invocar se denominan operaciones.
• Hereda el estado y a descripción del comportamiento de sus antecesores, y define el estado y la descripción de sus descendientes. P.ej. : Bicicleta hereda de vehículo que tiene ruedas y la moto hereda de bibicleta que tiene dos ruedas (un ejemplo un poco tonto pero que espero que refleje la explicación de herencia).
• Posee una visibilidad que especifica cómo puede ser usada por otras clases. Así los métodos o atributos privados sólo lo pueden usar la misma clase, los abstractos lo pueden usar también las hijas y los públicos el resto de clases. En la notación se representa de la siguiente manera.

• + atributo/método para visibilidad pública.
• - atributo/método privado.
• # atributo/método protegido        

• Sus niveles de significación son:

• Análisis: Representa un concepto lógico sin entrar en temas de rendimiento o construcción.
• Diseño: Captura las decisiones claves del diseño, la ubicación de la información y la funcionalidad de sus objetos. Es decir, indica la información del estado y las operaciones perteneciente a dicha clase.
• Implementación: Es escribir la clase en el código de lenguaje de programación.

Veamos con un ejemplo los niveles de significación pues no tienen porque quedar claros con la teoría (y sí, es un ejercicio con enunciado como en nuestra niñez, para que no perdamos esa pueril conexión interior ;P):

Estamos desarrollando una aplicación para el alquiler de películas, como no quiero hacer muy largo el ejemplo nos centraremos sólo en las características de una película a "grosso modo" y el cliente nos informa que sus características son: título, fecha de estreno, directores, actores, género, formato y un identificador de código de barras. ¿Cómo se interpretaría esto en los diferentes niveles de significación?:

Análisis

Está claro que necesitaremos una clase para película y tras hablar con el cliente deducimos que posee unos atributos cuyos valores los recogeremos mediante unos métodos para interactuar con el sistema. Todo esto quedará recogido en una documentación de requerimientos de requisitos del usuario y del sistema. Esta fase también es conocida como Ingeniería de Requisitos.

Vemos que esta fase es muy abstracta ya que a nivel de UML no se ha realizado aún nada pero es necesaria debido a que en ella conoceremos lo que el usuario quiere obtener del sistema y lo que nosotros necesitamos para posteriores fases.. Además de ser esta documentación un contrato entre ambas partes. El formato de este documento depende de cada cliente aunque todos siguen unas pautas generales, A continuación hablaremos sobre el mismo de manera más específica.

DDR (Documentos de Definición de Requisitos) o ERS (Especificación de Requisitos del Software)

En el se indican:

• El dominio de la aplicación.
• El proceso de negocio.
• Los actores del proyecto (requisitos funcionales). y el resto de requisitos (no funcionales, técnicos y de integración).
• El diseño inicial de la arquitectura. 

Tiene que ser validado por el usuario o su equipo de expertos pues es el contrato de lo que hará y ofrecerá el sistema así como sus restricciones.

Las características básicas que han de cumplir son, según el estándar IEEE 830-1998:

• Completa: Todos los requerimientos deben estar reflejados en el documento y todas las referencias deben estar definidas.
• Consistente: Ha de existir coherencia  entre los propios requerimientos y con otros documentos de especificación.
• Inequívoca: Redacción clara para que no se pueda malinterpretar.
• Correcta: El software desarrollado ha de cumplir con lo indicado en el documento.
• Trazable: Todo requerimiento podrá ser verificado así cómo su evolución.
• Priorizable: Los requisitos tienen una jerarquía dependiendo de su importancia.
• Modificable: Los requisitos pueden modificarse fácilmente sin que ello suponga un gran impacto (tanto en el documento como en el sistema si el cambio es debido por un evolutivo del software).
• Verificable: Existe un método finito y no costoso para poder probarlo.

A continuación os dejo este y este enlace para saber más sobre dichos documentos. Su formato viene indicado por el estándar IEEE 830-1998.

Diseño

Así quedaría la clase en notación UML 2.0 una vez diseñada. Vemos que se corresponde con la creación del diagrama de clases.

Implementación

Y aquí cómo podemos ver es el paso de lo indicado en el diagrama de clases a código fuente. No voy a desarrollar lo indicado en el diagrama de clases anterior ya que lo que pretendo mostrar es la idea general de los niveles de significación. Dicho esto indicaros que donde pongo "(...)" es equivalente a un etcétera.

Public Class Pelicula(){
   private String codigo;
   private String titulo;
   (...)
   public void setPelicula(String codigo, String titulo, (...)){
      this.codigo=codigo;
      this.titulo=titulo;
      (...)
   }
   (...)
}

Interfaz

Es la descripción del comportamiento de los objetos sin proporcionar implementación o estado bien sea una clase abstracta pura o un método no implementado. Su notación en UML es la indicada en la tabla de tipos anterior aunque también se puede usar la notación para la clase como se indica en el gráfico siguiente.

Tipo Primitivo

Es la descripción de valores primitivos que carecen de identidad y posee las siguientes propiedades:

• Se pasan por valor y son inmutables. 
• No tienen atributos pero sí operaciones.
• No modifican los valores de los datos aunque pueden devolver valores de datos como resultados.

También se pueden declarar un tipo numerado que es un conjunto de literales enumerados que pueden ser usados como valores. Su utilidad es la restricción de valores a uno previamente definido. Como ejemplo

Hasta aquí está primera parte de la vista estática. ¡Más en la siguiente entrada!.

¡Gracias por leerme!.