El primer tema a abordar será los elementos básicos del UML (Unified Modeling Language) o mejor conocido en español como lenguaje de modelaje universal
También acá abordaremos los temas de clases, objetos, abstracción, modularidad, encapsulamiento, herencia y polimorfismo.
¿Pero que es el UML?
Es un lenguaje que permite modelar, construir y documentar los elementos que forman un producto de software que responde a un enfoque orientado a objetos. Este lenguaje fue creado por un grupo de estudiosos de la Ingeniería de Software formado por: Ivar Jacobson, Grady Booch y James Rumbaugh en el año 1995. Desde entonces, se ha convertido en el estándar internacional para definir organizar y visualizar los elementos que configuran la arquitectura de una aplicación orientada a objetos.
El UML posee una las siguientes características:
1. Ser tan simple como sea posible, pero manteniendo la capacidad de modelar todas las operaciones del sistema que se necesita construir.
2. Debe ser un lenguaje universal, como cualquier lenguaje de propósito general. Esto sirve para que cualquier persona pueda fácilmente trabajar un proyecto sin necesidad de haber estado colaborando en el antes
4. Imponer un estándar mundial.
UML no es un lenguaje de programación sino un lenguaje de modelaje, jamás podremos decir que programamos en UML, pero si podemos diseñar nuestros sistemas con él para así al momento de escribir el código esto se mas fácil además de haber creado una herramienta potente.
En el UML toda la documentación de u n proyecto se divide en diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.
Existen dos grandes tipos de clasificación los diagramas dinámicos y los diagramas estáticos. Los diagramas dinámicos muestran como el sistema actuara cuando este se encuentre corriendo, mientras que el estático muestra cómo trabaja el sistema aunque no esté corriendo en ese momento.
A continuación mostraremos la lista de los diferentes tipos de diagramas:
Vista casos de uso
Vista de diseño
Vista de procesos:
Vista de implementación:
Diagrama de objetos
Diagrama de Clases
Entre otros.
Es muy posible que al diseñar un programa este requiera más de un tipo de diagrama según la complejidad de este, pero para iniciar será suficiente con que entendamos solo por el momento el Diagrama de objetos y el diagrama de Clases.
Antes de seguir avanzando veremos algunos conceptos claves para el Paradigma orientado a objetos que nos servirán tanto en el diseño del UML como al programar.
Abstracción: Es la habilidad que tiene el diseñador o programador de ignorar los detalles.
¿Cómo? ¿Olvidar los detalles? ¿Está bien eso?
Cuando hablamos de olvidar los detalles no nos referimos a que aremos un UML o un Software de mala calidad, sino todo lo contrario, al ignorar detalles que en su momento no nos interesan podemos conseguir un mejor resultado, ya que no saturamos un sola cosa
Lo demostraremos con un ejemplo sencillo
Un vendedor de mostrador se dedica a vender zapatos, el se dedica únicamente a vender zapatos, a el no le interesa si el camión hizo el correspondiente envió, o si la fabrica hizo a tiempo los zapatos, o si el que vende la materia prima le vendió a tiempo la materia a la fabrica. El solo se dedica a vender.
Con esto podemos decir que el vendedor no se llena de responsabilidades, pues el solo cumple la suya de vender. Ignoro los detalles, pero claro cada quien debe responsabilizarse por su tara; así mismo el de la empresa repartidora se preocupa por mandar a tiempo el paquete, la fabrica por hacer los productos, y el vendedor de la materia prima, de tener la materia a sus disposición.
Cuando traduzcamos esto a código vernos que no servirá mucho ya que a darle a cada clase una tarea específica es más estable el sistema además de que se puede reciclar con facilidad el código
Modularidad: Es la acción de poder dividir un proceso en otras tareas para así poder realizarlas con facilidad
¿Se parece mucho al anterior no?
Pero no, de hecho al diseñar un sistemas aremos uso de ambas con una vernos que módulos podemos separar, y con la otra vernos que detalles se pueden ignorar en su momento.
Encapsulamiento: Ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
Esto nos sirve para poder tener más seguro nuestros datos para así evitar una posible modificación accidental, pues hablando de código solo una clases podrá acedar a las variables que estén dentro de ellas pero no otra clase.
Un ejemplo seria: Imaginemos que la familia juanita sabe un secreto, solo ellos podrán saber el secreto, más no otra familia.
Si en este momento no quedo muy claro este concepto, no se preocupe quedara más claro al momento que estemos programando.
Herencia: Capacidad que tiene los objetos para heredar todas o algunas de sus características (datos) y comportamiento (procedimientos) a sus descendientes o herederos, permitiendo así la reutilización de código lo que en la práctica se traduce en una herramienta muy potente de programación.
En un ejemplo muy sencillo es que ejemplo, tu papá te heredo el color de tus ojos.
Polimorfismo: Se refiere a la capacidad para que varias clases derivadas de una antecesora utilicen un mismo método de forma diferente.
Ejemplo, podemos crear dos clases distintas: Pez y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (peces y aves se mueven de forma distinta).
Una vez más si no quedo claro no se preocupe estos conceptos quedaran más claro al programar, por el momento está bien con lo que haya entendido
Diagrama de Objetos
Es un diagrama que da una muestra el sistema de manera dinámica, ósea cuando este está trabajando, este diagrama nos ofrece una mirada de cómo trabajara el sistema cuando este se esté implementando.
Muestran instancias objetos en un momento particular del sistema. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.
Diagrama de Clases
Este diagrama a diferencia del diagrama de Objetos nos muestra una vista del sistema en una forma estática, ósea que nos muestra como está el sistema cuando este no esta corriendo.
En el diagrama será donde definiremos las características de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalización. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos, definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.
En el diagrama de clases debemos definir a estas y a sus relaciones.
En este momento saber que es una clase, la clase define los atributos y los métodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el término «tipo» en lugar de clase, pero recuerde que no son lo mismo, y que el término tipo tiene un significado más general.
En palabras más simples podemos decir que una clase es como una especie de molde para los objetos.
Mientras que un objeto no es nada más que un objeto, ósea reprenda algo de la vida real.
Ejemplo
Imaginemos la Clase Auto esta posee varias características (atributos) como el numero de llantas, el tipo de auto, puertas, color, etc. El Objeto “Auto_mio” lo podemos considerar como un objeto de la clase auto, este objeto tiene 4 puertas, es rojo, y es de tipo sedan, y así se pueden construir mas objetos en base a una clase, pues como dije la clase es como el molde
Para representar una clase en UML usaremos un rectángulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los métodos (acciones que realizara).
 |
| En la parte de arriba Lleva el nombre de la clase(Cuenta), en la parte de en medio los atributos(balance), y en la ultima parte los métodos(depositar (monyo :int): void), |
En esta clase se pudo apreciar que una clase lleva los tres elementos básicos, en la parte dos no es necesario marcar el tipo de dato con el que trabajara
Atributos
Los atributos (características) se muestran al menos con su nombre, y también pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos también pueden ser mostrados visualmente:
+ Indica atributos públicos
# Indica atributos protegidos - Indica atributos privados
Métodos
Los métodos (acciones) también se muestran al menos con su nombre, y pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:
- + Indica operaciones públicas
- # Indica operaciones protegidas
- - Indica operaciones privadas
Los métodos los podemos definir como las acciones que hará como sumar, restar, mostrar total, dar cambio, etc. Podemos decir que es el verbo.
Asociaciones de clase
Las clases se puede relaciones (estar asociadas) con otras de diferentes maneras:
Generalización
La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias.
En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una línea que conecta las dos clases, con una flecha en el lado de la clase base.
Asociaciones
Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de «conexiones» entre objetos.
Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace).
Se representa mediante una línea continua, que une las dos clases
Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario.
En UML, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes
Las asaciones es básicamente como una clase trabaja con otra pues en el paradigma orientado a objetos es muy importante tener en cuenta que una clase puede trabajar con otra clase, es la forma en que se pueden comunicar
IMPORTANTE
1.- Cada clase debe tener un nombre único, que las diferencie de las otras.
2.- La primera letra de la clase debe de empezar con mayúscula.
3.- La primera letra del objeto es minúscula.
4.- Cuando el nombre del objeto o clase es mayor a una palabra se pueden juntar solo si la letra de la siguiente palabra empieza con mayúscula ejemplo: miCasa (objeto) MiCasa(Clase)
O igual se pude separar con guiones bajos mi_casa
5.-Para marcar que un objeto pertenece a una clase se escribe la primera palaba que sera el nombre del objeto mientras que la palabra de abajo es a la clase a la que pertenece(figura 1.0)
 |
| Figura 1.0 |
6.-Los nombres no pueden llevar coma, ni ningún carácter especial.
Diferencia entre Diagrama de Clases y Diagrama de Objetos
El de la izquierda se pude ver que es un diagrama de objetos y se puede identificar fácilmente que “miVisor” es un objeto que pertenece a VisorDeReloj
Por el momento ignoremos los dos campos de horas y minutos, esos los podremos explicar más detalladamente al momento que vemos código.
En el diagrama de la derecha se aprecia con facilidad que es un diagrama de Clase se puede apreciar a primera vista las “Asociasones de clases” pues la clase VisorDeReloj trabaja con objetos de la clase VisorDeNumeros
Acá se puede apreciar de manera muy fácil su diferencia entre cada diagrama pues el diagrama de objetos nos muestra la vista dinámica, ósea cuando nuestro sistema está corriendo. Mientras que el Diagrama de Clases nos muestra la vista Estática, Ósea cuando nuestro sistema está parado.
Algo muy importante es que ambos son necesarios para un buen diseño de un Software, ya que cada uno muestra una vista diferente del sistema
Ejemplo
A continuación se mostrara un ejemplo de diagrama de Clases.
Nos enfocaremos en diagramas de clases ya que nos serán de gran utilidad al pasar al bluej
 |
| Acá podemos apreciar como todo lo anterior se aplica |
Hasta este momento vimos dos Diagramas muy importantes, estos dos tipos de diagramas nos ayudaran a empezar a modelar nuestros pequeños sistemas. Para que así podamos ver cómo trabajan. En un futuro el lector e incluso el autor se meterán a investigar el resto de tipos de diagramas, pero por el momento bastara con estos dos.
Hay que tener muy en cuenta que el UML no es un lenguaje de programación, jamás podremos decir que uno programa en UML. Entonces uno se pregunta ¿Para qué carajo me sirve el UML si no puedo programar en él?
La respuesta es muy sencilla, pues como su nombre lo dice es un Lenguaje de Modelaje esto quiere decir que nos ayuda a diseñar nuestra pieza de Software, pues al tenerlo documentado será más fácil hacerle futuras modificaciones, e incluso que otras personas que jamás han participado en el proyecto puedan fácilmente adherirse a él.
A continuación mostraremos el código en C++ para saber qué tipo de triangulo es a partir de haber ingresado los 3 lados de el
#include<stdio.h>
#include<conio.h>
float l1,l2,l3;
main()
{
printf("Hola, ingrese los tres lados del triangulo para poder determinar si es un triangulo isoceles,equilatero o escaleno\n");
scanf("%f %f %f", &l1,&l2,&l3);
if(l1==l2 && l2==l3)
{
printf("El triangulo es equilatero\n");
}
if(l1==l2 && l3!=l2 || l1==l3 && l2!=l1 || l2==l3 && l1!=l3)
{
printf("El triangulo es isoceles\n");
}
if(l1!=l2 && l1!=l3 && l2!=l3 && l2!=l1 && l3!=l1 && l3!=l2)
{
printf("El triangulo es escaleno");
}
getch();
}
Este ejemplo que es bastante sencillo uno pensaría que no es necesario hacer uso de los diagramas de UML, tal vez para este programa no sea necesario pues no nos llevara más de 50 líneas de código hacerlo , y fácilmente podemos modificarlo, o otra persona puede trabajar en el fácilmente.
Pero ahora piense que usted trabaja en con un equipo de desarrolladores y le tienen como trabajo desarrollar un videojuego, ¿Usted cree que el juego le llevaría 100 o incluso 200 líneas?
Pues no, en este casos estaríamos hablando de miles de líneas de código, entonces nos damos cuenta que para poder desarrollar este proyecto necesitaremos una especie de mapa que nos ayude a saber donde se encuentra cada parte del juego y como interactúa cada objeto con otro, ahí radica la importancia del UML, el UML será nuestro mapa del proyecto y nos guiara en todo momento, además de que será más fácil modificar el sistema en un futuro.
Si nos ponemos a analizar cualquier sistema moderno que cumpla con estándares de calidad actual se apoyara en el UML, desde juegos, programas administrativos, de manipulación de gráficos e incluso el sistema operativo de una computadora.
Se debe recordar que un programa no es nada más que un seria de líneas de código que son traducidas por un compilador a 0 y 1, que es el lenguaje de las maquinas ,y debemos tener nuestro “mapa” para así no perdernos en el mar de código que desarrollemos.
En este momento el lector habta que haber comprendido lo elemental del diagrama de clases y su importancia al desarrollar software. Con esto finalicemos la primera parte, en la parte que sige empezaremos a adentrarno en el codgigo de un programa en Java, si el lector no le quedo claro algo le recomiendo volver a leerlo o escribir sus dudadas.
Estudiante de ISC Daniel ZVPL
No hay comentarios:
Publicar un comentario