Notaciones de especificación y diseño (UML)
Una parte esencial de todas las tareas del desarrollo del software, y de las especificaciones de requisitos y diseño en particular, es la utilización de una notación que permita representar los aspectos esenciales de las mismas y que al mismo tiempo permita una mecanización parcial del proceso de desarrollo. Dado que en la actualidad la fase de implementación se suele realizar con tecnologías orientadas a objetos y que adicionalmente este tipo de enfoque también es aplicable en otras fases del desarrollo, es importante que el alumno conozca, al menos los principios básicos, de las notaciones orientadas a objetos, y en especial la más extendida últimamente, como es el UML (Unified Modelling Language, Lenguaje Unificado de Modelado).
Cuando alguien intenta resolver un problema complejo lo primero que hace es estudiarlo: Ver cuales son sus componentes, establecer relaciones entre las partes, comprender sus propiedades e imaginar como funciona de un modo dinámico. Pero como la mente humana es perezosa, no estarán todos los detalles, sólo los esenciales. Esto no es importante, con tal de que la representación mental funcione igual que el problema real los detalles se pueden abstraer. El resultado de este proceso es un modelo. Por tanto, modelo es una representación de la realidad donde se abstrae lo no esencial. Para un mismo sistema se puede establecer más de un modelo diferente en función de que aspecto interese resaltar o del nivel de detalle que se quiera conseguir.
“UML” son las siglas de Unified Modeling Language y como su nombre indica es un lenguaje de modelado, es decir, su utilidad está en que sirve para expresar modelos. No es nada más que eso, no indica cómo se debe hacer el análisis o el desarrollo orientados a objetos y en consecuencia, no es una metodología de desarrollo, tan solo es una notación, ahora bien, es la notación que se ha convertido en el estándar de facto de la mayor parte de las metodologías de desarrollo orientado a objetos que existen hoy en día.
Su utilidad está en la especificación, visualización, construcción y documentación. De esta frase, la palabra visualización es la más importante; UML es un lenguaje basado en diagramas y está pensado para entrar por los ojos, tanto a los desarrolladores como a los clientes.
Clase
Es el gráfico más importante. En la figura podemos ver que tiene cuatro partes que se disponen de arriba a abajo en el orden siguiente:
· Nombre: Si aparece en cursiva la clase es abstracta.
· Atributos: Pueden mostrar mucha información.
· Tipo: Atributo:Tipo
· Valor predeterminado: Atributo:Tipo=Valor ó Atributo=Valor
· Restricciones: Las restricciones se pueden poner como se ha visto en el gráfico, pero UML cuenta con un método aún más formal que es el lenguaje OCL.
· Alcance: Un atributo puede ser público(+), protegido(#) o privado(-).
· Ámbito: Hay dos tipos
· Instancia: Cada objeto tiene su propio valor.
· Archivador: Solo hay un valor en todas las instancias de una clase (como las variables static en Java). Estos atributos aparecen subrayados.
· Toda esta información es opcional, de hecho la mayoría de las veces se pone sólo el nombre del atributo.
· Métodos: Al igual que los atributos también pueden especificar su alcance o ámbito. Además pueden indicar el tipo de los argumentos que reciben y el tipo del valor devuelto. Tanto si tienen parámetros como si no deben llevar un paréntesis abierto y otro cerrado al final del nombre.
· Responsabilidades: Es una descripción de lo que hace la clase en su conjunto. Está información casi nunca está en los diagramas.
Diagrama de objetos
Es un diagrama que contiene objetos y enlaces entre ellos. Pueden también agruparse en paquetes y se puede mostrar las clases si se considera oportuno para mostrar los objetos que vienen de una clase concreta. Sirve para tomar una instantánea del sistema en un momento dado del funcionamiento. También es un modelo estático porque no representa la evolución a través del tiempo, sino un momento concreto. Como se puede ver en el ejemplo de la figura, la notación correspondiente es:
1. Se pone el objeto en un rectángulo.
2. El nombre es opcional pero se debe poner la clase a la que pertenece precedida por dos puntos, todo ello subrayado: NombreObjeto:Clase
3. Puede tener variables con su valor.
4. Al igual que las clases los objetos pueden estereotiparse.
5. Los objetos pueden estar relacionados por enlaces, que son instancias de las asociaciones definidas en el diagrama de clases.
Casos de Uso
Los casos de uso son una descripción de una interacción con el sistema por parte de algo externo al sistema que se llama actor. Por ejemplo: un usuario pulsa el botón de llamada de un ascensor. El nombre del caso de uso se pone en la elipse, como en el de la figura. Un caso de uso es un patrón o comportamiento que exhibe el sistema. Los casos de uso representan requisitos funcionales. Los casos de uso se escriben desde el punto de vista del actor, que es el usuario o sistema externo que interactúa con el sistema.
Relaciones que nos podemos encontrar en los casos de uso
1. Include: Es el concepto de subrutina. Si por ejemplo tenemos dos casos de uso A y B que tienen una serie de pasos en común se ponen esos pasos en un tercer caso de uso C y A y B lo incluyen para usarlo.
2. Extends: Significa que un caso de uso B es igual al A al cual extiende añadiendo algunos pasos.
3. Comunicates: Comunica un actor con un caso de uso o con otro actor.
Diagrama de estados
Un sistema evoluciona en el tiempo pasando por una serie de estados. Parte de un estado inicial y llega a un estado final. Un estado tiene:
· Nombre.
· Variables.
· Actividades, que pueden ser de dos tipos:
o Acciones. Programadas por los desarrolladores
o Eventos: Sucesos a los que reacciona el sistema. Pueden ser de tres tipos:
§ Entry: Actividades que se realizan al entrar al estado.
§ Exit: Eventos al abandonar el estado.
§ Do: Actividades mientras se está en el estado.
Y constan de las siguientes partes:
o Signature: Nombre y lista de parámetros.
o Guard condition: Expresión lógica que habilita o no la transición.
o Acción: Acción interna a ser ejecutada.
o Mensaje: Evento enviado a otro objeto (o a varios).
Las transiciones entre estados pueden tener parámetros. Cada transición tiene un evento asociado. Cuando se terminan las actividades de un estado hay una transición.
Por ejemplo, supongamos que tenemos un ascensor que cuando está en el sótano (área restringida a la que sólo se puede acceder con llave) sube a los pocos segundos para evitar que si alguien se ha colado pueda acceder a las viviendas. Por otra parte el ascensor puede estar subiendo, bajando o parado. Cuando se está bajando al sótano se considera como un estado especial y el hecho de estar en el sótano también. Esto se puede representar como en la figura
Diagramas de Secuencias
Muestra los objetos y los mensajes intercambiados entre ellos teniendo en cuenta la temporalidad con la que ocurren. Pueden mostrarse también los componentes porque son objetos reutilizables y los casos de uso porque se muestran como objetos que implementan el caso de uso. Sirven para documentar el diseño y validar los casos de uso. Gracias a estos diagramas se puede ver cuales don los cuellos de botella del sistema observando el tiempo que consume el método invocado. Los conceptos a tener en cuenta son:
1. Línea de vida de un objeto: Es una representación de la actividad del objeto durante el tiempo que dura el escenario. El tiempo transcurre de arriba abajo. Se representa con una cabecera con un rectángulo con el nombre del objeto y una línea vertical de puntos por debajo. Durante el tiempo en el cual el objeto tiene un método funcionando la línea de puntos se convierte en un rectángulo como se muestra en el ejemplo.
2. Activación: Es el proceso por el que un objeto pasa a tener un método en ejecución. Esto puede ocurrir o bien porque otro objeto ha invocado alguno de sus métodos o porque lo ha invocado el mismo (self-delegation). Cuando un objeto activa a otro siguen en actividad.
3. Mensaje: Un mensaje es un objeto que invoca el método de otro. La notación es una flecha horizontal desde la línea de vida de un objeto hasta otro.
4. Tiempos de transición: Es el tiempo que hay entre un mensaje y otro.
5. Condicionales: Si se desea representar una alternativa o threads. El mensaje sólo se envía si la condición es verdadera. La condición se escribe entre corchetes y puede referenciar a otro objeto
6. Iteración: Se pone el símbolo * previo a la condición. Se repite la acción mientras la condición es verdadera
7. Creación y destrucción de un objeto: La creación de un objeto se representa con un mensaje de creación sobre un rectángulo. La destrucción se representa con un aspa al final de su línea de vida (ver figura:
8. Métodos recursivos: Se representan poniendo un rectángulo superpuesto al que está activo en el momento
Diagrama de actividades
Son un caso especial de los diagramas de estados. Modela el comportamiento del sistema y la participación de las clases en ese comportamiento. Describen el comportamiento interno de una clase en vez del comportamiento en función de los eventos. Para construirlos se puede seguir la siguiente estrategia:
1. Identificar una clase que participa en el comportamiento cuyas actividades de proceso deban ser especificadas.
2. Identificar las distintas actividades que se van a modelar.
3. Identificar: estados, flujos y objetos.
Este diagrama es útil para modelar el flujo de trabajo de un negocio a alto nivel y consta de los siguientes elementos:
1. Punto inicial: Se representa por un círculo negro.
2. Punto final: Es una diana.
3. Actividades: Son rectángulos con bordes redondeados.
4. Transiciones: Son el paso de una actividad a otra. Se representan con flechas.
5. Actividades concurrentes: Se representan por sus correspondientes actividades y una barra negra de la cual parten las flechas que las inician.
6. Bifurcaciones: Se representan con un rombo o sencillamente con dos flechas que salen de una actividad a otras dos. En cualquier caso, la condición se indica en cada uno de los ramales entre corchetes.
7. Indicaciones: Se pueden enviar o recibir. El envío se representa con un rectángulo acabado en flecha. El que las recibe con una figura complementaria de la anterior. Una indicación modela el envío y recepción de eventos.
Diagrama de componentes
Modelan la vista estática del sistema. Ilustran la organización y las dependencias entre componentes software. Un componente puede ser: código fuente, un programa ejecutable, tablas, o cualquier otro tipo de documento que forme parte del sistema. No tienen que estar presentes todos los componentes, suele mostrarse una parte. Un componente puede implementar una interfaz
El estándar de UML define cinco estereotipos: executable, library, table, file y document.
Ejecutables
Para modelarlos los pasos a seguir son:
1. Identificar los componentes, particiones del sistema, cuales son factibles de ser reutilizadas, agruparlas por nodos y realizar un diagrama por cada nodo que se quiera modelar.
2. Identificar cada componente con su estereotipo correspondiente (executable, library, etc)
3. Relacionar los componentes entre sí.
Código fuente
Podemos usar estos diagramas para expresar las dependencias que existen entre los módulos para formar librerías o programas ejecutables.
Diagrama de colaboración
Dibuja las interacciones entre objetos organizadas a través de los objetos y los enlaces que hay entre ellos. Este diagrama es otra forma de ver la secuencia de eventos. Es lo mismo que los diagramas de secuencia (se puede generar de un modo automático un tipo de diagrama a partir del otro).
Diagrama de distribución
Refleja la organización del hardware. El elemento principal de este diagrama es el nodo. Hay dos tipos: los nodos con capacidad de ejecutar componentes y los que no pueden ejecutar. La información que hay en un nodo es: nombre del nodo y componentes del nodo (se puede poner sólo sus nombres o un diagrama de componentes). Los nodos a su vez pueden estar físicamente conectados con otros, lo que se representa con una línea que los une. La utilidad principal de este tipo de diagramas es la modelización de una red.
No hay comentarios:
Publicar un comentario