Modelo Estatico, Dinamico y Funcional en OMT

Hola a todos!!!, hoy voy a escribir sobre estos tres tipos de modelos, por si acaso esta explicación no es solo para OMT ya que puede ser usada para entender sus pares de estos en UML, esto es gracias a que UML desciende de OMT.
 

Antes de comenzar a hablar sobre los diagramas que comprenden los modelos, primero deberemos de tener algunos conceptos claros como que es un objeto, que es una clase y cosas por el estilo, en este post hare un resumen de los conceptos más importantes y necesarios para poder entender lo diagramas, pero si desean un explicación más extensa lean este otro post, que hice hace algún tiempo.

Objeto.- Es una abstracción de algo en el dominio de un problema, reflejando las capacidades de un sistema, guardando información sobre este, interactuando con este o ambos.¹

Clase.- Una clase es una abstracción que describe características comunes de todos los objetos en un grupo de objetos similares.

Herencia.- La herencia es la idea derivada del hecho que un objeto es formado por una clase, esto nos da la idea de que se puede definir una clase superior o superclase que posee algunos atributos y operaciones muy generales, de esta clase luego se crea otra y esta otra clase hereda los atributos y parámetros de la superclase.

Modelo Estático

El modelo estático es uno de los tres modelos que componen OMT, este modelo tiene la tarea de modelar la estructura estática de nuestro sistema, mostrándonos las clases, objeto y relaciones que existen dentro del sistema.

Ahora este modelo tiene dos herramientas para mostrar de una manera más grafica el comportamiento estático del sistema, estas son “El diagrama de Clases” y “El diagrama de Objetos”.

El diagrama de clases como sus nombre indica, solo hace uso de clases para representar el sistema, mientras el diagrama de objetos usa los objetos instanciados del diagrama de clases, por lo cual para hacer un diagrama de objetos, previamente debimos de haber realizado un diagrama de clases. El diagrama de clases usa los siguientes símbolos para modelar el sistema.

Clases:

Para definir niveles de acceso se usa la siguiente nomenclatura:

+ (Publico)

# (Protegido)

- (Privado)

Seguido al nombre del atributo o método, se puede definir el tipo que representa o que devuelve (solo métodos), para hacer esto deberemos de seguir la siguiente nomenclatura:

Nombre_Atributo/Metodo: Tipo_Dato

De igual modo para los parámetros de entrada usaremos la misma nomenclatura.

Relaciones Binarias:

La relación Binaria entre clase y objeto se representa mediante una línea recta y en cada extremo se denota la multiplicidad de la relación, las multiplicidades existentes son:

<!--[if !supportLists]-->- <!--[endif]-->Uno a muchos (1 - *)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Uno (1 – 1)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Cero o Uno (1 – 0..1)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Cero o Muchos (1 – 0..*)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Uno o Muchos (1 – 1..*)

<!--[if !supportLists]-->- <!--[endif]-->Muchos a Muchos (* - *)

Además encima de la línea que representa la relación, se le deberá de etiquetar con algún nombre:

Relación de Herencia:

La relación de herencia se denota de la siguiente manera:

La flecha siempre debe de ir apuntando a la clase padre, la relación de herencia no tiene multiplicidad ni tampoco se debe de etiquetar, ya que viene implícito.

En el siguiente ejemplo se muestra una relación de herencia múltiple:

Relación de Composición:

La relación de composición debe de denotarse de la siguiente manera:

Esta relación al igual que la binaria simple debe de tener multiplicidad, pero no así etiqueta ya que al igual que la herencia esto ya viene implícito, como apunte se debe de recordar que el rombo debe de ir apuntando a la clase que está compuesta de la otra clase, en el siguiente ejemplo se denota como se debe de usar:

Ahora en el diagrama de Objetos se incluye un nuevo elemento, el Objeto que se representa de la siguiente manera:

Como se puede observar es muy parecido a la representación de una clase, la diferencia es que ya no se ponen los métodos y ahora se observan los valores que tiene los atributos.

El nombre del objeto y los atributos tienen la siguiente nomenclatura:

Nombre_Objeto: Nombre_Clase

Todo el nombre debe de estar subrayado, no olvidar esto.

Nombre_Atributo: Tipo_Dato = “Valor”

Para los atributos se debe de respetar el tipo de dato, no olvidar esto, ya que por ejemplo en un atributo del tipo Integer no deberemos de guardar cadenas de texto o numero con punto flotante.

Antes de finalizar este modelo quiero agregar algunos conceptos, que nos ayudaran a hacer mejores modelos estáticos.

Alta Cohesión:

La alta cohesión hace referencia a que: “Los atributos y operaciones de una clase deben referenciar a la misma clase y no a atributos o funcionalidades de otras clases que estén dentro del contexto del problema”, en otras palabras, tus clases deben de tener solo atributos y métodos que le conciernan solo a sí mismas.

Bajo Acoplamiento:

El bajo acoplamiento: “Define la característica de un diagrama de clase donde cada clase debe de tener la mínima cantidad de asociaciones posible con otras clases”, esto nos dice que no hagamos asociaciones inútiles entre clases.

Clave Candidata:

La clave candidata se la puede definir como: “Un atributo que debe de tener un valor único”, la clave candidata se parece al OID, pero a diferencia de esta, en la clave candidata se puede modificar su valor o eliminar el valor.

Modelo Dinámico

El modelo dinámico tiene la tarea de mostrar el comportamiento del sistema durante el transcurso del tiempo o mejor dicho en función al tiempo.

El modelo dinámico al igual que el estático tiene dos herramientas para representar esto, y estas son “El Diagrama de Estado” y “El diagrama de Sucesos”.

Ahora me gustaría definir que es un diagrama de estados para que se entienda mejor, donde y como implementarlo

Diagrama de Estados: “Es un diagrama que presenta los estados en los que puede encontrarse un objeto, junto con las transacciones entre los estados, y muestra los estados Inicial y Final de una secuencia de cambios de estados”²

Para entender mejor la anterior definición procedamos a definir que es un estado:

“Estado es la situación en la cual se encuentra un objeto con sus respectivos valores para sus atributos en un punto del tiempo especifico”.

La anterior definición nos da como pauta que si alguno de los atributos se modifica existe la posibilidad de cambio de estado, y digo posibilidad ya que puede darse el caso que si un atributo se modifica este puede no variar el estado del objeto; La variación de un atributo casi siempre se debe a un Evento o Suceso, así que sería bueno definir formalmente que es un evento o suceso:

Evento: “Hecho que se produce en un punto del tiempo, que puede o no modificar un atributo”

Con esto ya definido, creo que el concepto de Diagrama de estados se entiende a cabalidad, ahora lo que nos resta es ver los símbolos que se utilizan para modelar uno de estos diagramas:

Estado:

La nomenclatura de un estado es simple, en la parte de arriba se debe de especificar el nombre del estado sin subrayados, negrillas u otras cosas, después en la estructura tenemos tres identificadores básicos que son “entrada”, “salir” y “hacer”, tanto entrada como salir son acciones que se deben de dar tanto cuando se entra al estado como cuando se sale del estado, en el identificador hacer, podemos definir tareas que el objeto va a realizar mientras este en ese estado.

Estado Inicial:

El estado inicial es cuando un objeto acaba de ser instanciado, por lo cual es necesario representarlo de una manera diferente al resto de los estados:

Un Circulo relleno representa el estado inicial.

Estado Final:

El estado final es cuando un objeto es destruido, la manera de representarlo es la siguiente:

Transición:

La transición se representa con una línea recta y encima de esta el evento que produjo el cambio de estado:

Estado Compuesto:

Un estado compuesto o súper estado, es un estado que engloba a dos o más estados dentro de uno solo, la representación es la siguiente:

Ahora es el turno del diagrama de sucesos, al igual que el otro diagrama, procederemos a definirlo.

Diagrama de Sucesos: “Es un diagrama que muestra la interacción entre los distintos objetos mediante los mensajes que se mandan entre ellos, en un escenario en especifico”.

Creo que el concepto está realmente claro, pero creo que mejoraría si defino que es un escenario.

Escenario: “Es un conjunto especifico de eventos o sucesos que se dan dentro del sistema en un momento de tiempo dado”.

Con esto ya esta re-claro que modela el diagrama de sucesos, por lo cual solo me resta explicar los elemento con los que se modela este diagrama.

Actor:

El actor, es quien interactúa con el sistema, este actor puede ser una persona real, otro sistema o alguno objeto de nuestro sistema, todo depende de nuestro escenario, al actor se lo representa como un hombrecito.

Objeto:

Los objeto en este diagrama se representan con un cuadrado, donde se sitúa el nombre del objeto, todo sub-rayado, además tiene una línea punteada saliendo de la parte baja del recuadro, esta representa su línea de tiempo.

Mensaje:

Los mensajes se representan con una línea recta y una flechita, además en la parte de arriba se encuentra la etiqueta de este, como un apunte recordar, que los mensajes que se indiquen en el diagrama de sucesos previamente debieron de ser definidos en el diagrama de estados, ya que en ese diagrama definimos las relaciones que por donde fluye el mensaje.

Modelo Funcional

El modelo funcional tiene la tarea de modelar el funcionamiento operacional, mostrando operaciones y transformaciones durante el uso del sistema.

El modelo funcional tiene una única herramienta, que es el “Diagrama de funciones”, bueno entonces definamos que figuras son necesarias para poder representar el sistema en este diagrama:

Actor:

El actor es un objeto activo dentro del sistema, que provee y consume información de los procesos, entonces al ser un objeto, la representación es igual que en el modelo estático, con excepción que no se muestran los atributos.

Proceso:

Un proceso es una operación que se da dentro del sistema, esta puede ser grande o solo la simple implementación de un método, un proceso se representa mediante un ovalo.

Almacén de Datos:

El almacén de datos es un objeto pasivo que almacena datos, su representación es dos líneas horizontales y paralelas, y en el medio el nombre del almacén de datos.

Flujo:

Es un elemento que vincula los procesos, actores y almacenes de datos entre sí, se lo representa con una línea recta y una flecha en alguna de las puntas, en la parte superior debe de ir el nombre del Flujo o acción que genera ese flujo.

Caso de Estudio

Para que todos los conceptos y herramientas que mencione queden aun más claros, voy a realizar un caso práctico donde veremos donde y como utilizar todos los modelos.

El caso de estudio que elegí es el de una biblioteca de un colegio, aquí va el planteamiento del problema:

El colegio “Saint SomeBody” tiene una pequeña biblioteca donde almacena alrededor de unos 1000 libros, la biblioteca está a cargo de una bibliotecaria y de su ayudante, los estudiantes pueden sacar libros tanto para leerlos en sala como para llevárselos a su casa, como esto pude producir retrasos en la entrega, se ha establecido multas dependiendo de la cantidad de días de retraso, no hay que olvidar que los docentes del colegio pueden sacar libros, por lo cual se les aplicara el mismo mecanismo de multa. No hay que olvidar que el colegio pide a la bibliotecaria mensualmente un informe de los inventarios. Diseñar el sistema para esta biblioteca.

Para comenzar vamos a hacer el diagrama de clases, para lo cual identificaremos todas las clases candidatas:

- Libro

- Docente

- Alumno

- Préstamo

- Bibliotecario

- Inventario

A estas clases que están explicitas, hay que agregar las clases que se encuentran implícitas como son:

- Autor

- Editorial

- Catalogo

Con todas las clases definidas, pasamos agregar a cada una de ellas sus atributos y operaciones que creamos necesarias, además si se analiza el listado de clases podemos ver que se puede crear relaciones de herencia entre Docente, Alumno y Bibliotecario, a través de la clase persona, además tanto el docente como el alumno se los puede generalizar una vez más en una clase llamada Prestatario. Otro punto es el de los catálogos e inventarios ya que estos son clases que están compuestas de otras, por lo cual usaremos composición, a mi manera de ver el diagrama de clases debería de quedar así:

Eso sería todo el proceso para generar su diagrama de clases, para el de objeto lo único que debemos de hacer es instanciar estos, que esa tarea se los dejo a ustedes.

Ahora el diagrama de estados, es solo de un objeto en particular por lo cual elegiremos el objeto Libro_1234 que es la instanciación de la clase Libro, un libro solo puede tener dos estados alquilado o disponible, el cambio de estado solo se da a través del evento préstamo, eso quedaría de la siguiente manera:

Ahora el siguiente diagrama que nos toca es el de secuencia, para lo cual modelaremos el escenario de alquiler de un libro, eso quedaría así:

El escenario muestra al bibliotecario como actor, ya que él es quien interactúa con el sistema, primero pide ver el inventario, luego elige el libro que se desea sacar, después le pide al prestatario, que en este caso es un alumno, que se identifique como tal a través de la entrega de sus datos personales básicos, con los datos básicos obtenidos, procedemos a registrar la boleta con los objetos, libro y prestatario, registrado en el sistema el prestamos, el sistema a través de su objeto préstamo_123 procede a imprimir la boleta de comprobante de préstamo.

Como ven no es para nada difícil hacer estos diagramas, le deseo suerte para esta noche ByE.

Bibliografía:

1. - Beginning Java Objects: From Concepts to Code, Second Edition by Jacquie Barker, Apress 2005

2. - Systems Analysis and Design, Second edition by Donald Yeates and Tony Wakefield, Prentice Hall 2004

3.- Aprendiendo UML en 24 Horas, First Edition by Joseph Schmuller, Prentice Hall 2004