PROGRAMACIÓN ORIENTADA A OBJETOS

¿QUÉ ES UML?

Lenguaje Unificado de Modelado

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling
Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la
actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como
procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir
métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema
y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el
modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o
RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje
Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en
un requerimiento. Mientras que, programación estructurada, es una forma de programar como
lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a
objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.

Se encuentran las siguientes ventajas:

• Se localizan fácilmente las responsabilidades de los estados específicos, dado que se

encuentran en las clases que corresponden a cada estado. Esto brinda una mayor
claridad en el desarrollo y el mantenimiento posterior. Esta facilidad la brinda el hecho
que los diferentes estados están representados por un único atributo (State) y no
envueltos en diferentes variables y grandes condicionales.
• Hace los cambios de estado explícitos puesto que en otros tipos de implementación los
estados se cambian modificando valores en variables, mientras que aquí al estar
representado cada estado.
• Los objetos State pueden ser compartidos si no contienen variables de instancia, esto se
puede lograr si el estado que representan esta enteramente codificado en su tipo.
Cuando se hace esto estos estados son Flyweights sin estado intrínseco.
• Facilita la ampliación de estados
• Permite a un objeto cambiar de clase en tiempo de ejecución dado que al cambiar sus
responsabilidades por las de otro objeto de otra clase la herencia y responsabilidades
del primero han cambiado por las del segundo.

1
Se encuentran la siguiente desventaja:

• Se incrementa el número de subclases.

Ventajas y Desventajas de UML: Enfocaré los aspectos positivos y negativos como

características propias del elemento, cuando lo utilice más podré establecer esos criterios.

OTRAS VENTAJAS Y DESVENTAJAS

Ventajas
La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del
hardware sobre el que se ejecuta el sistema

Desventajas
Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los
cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar
decisiones que permitan un cambio continuo de la topología del sistema.

A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy
criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación
de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con
facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como
transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales
factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o
remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias
instancias de ejecución del sistema analizado. Sin embargo, UML sí acepta la creación de
nuestros propios componentes para este tipo de modelado.

Ejemplo - Tutorial UML

"Hotel"

El dueño de un hotel le pide a usted desarrollar un programa para consultar sobre las piezas
disponibles y reservar piezas de su hotel.

El hotel posee tres tipos de piezas: simple, doble y matrimonial, y dos tipos de clientes:
habituales y esporádicos. Una reservación almacena datos del cliente, de la pieza reservada, la
fecha de comienzo y el número de días que será ocupada la pieza.

El recepcionista del hotel debe poder hacer las siguientes operaciones:

• Obtener un listado de las piezas disponible de acuerdo a su tipo

• Preguntar por el precio de una pieza de acuerdo a su tipo
• Preguntar por el descuento ofrecido a los clientes habituales
• Preguntar por el precio total para un cliente dado, especificando su número de RUT, tipo
de pieza y número de noches.
• Dibujar en pantalla la foto de un pieza de acuerdo a su tipo
• Reservar una pieza especificando el número de la pieza, rut y nombre del cliente.
• Eliminar una reserva especificando el número de la pieza

2
El administrador puede usar el programa para:

• Cambiar el precio de una pieza de acuerdo a su tipo

• Cambiar el valor del descuento ofrecido a los clientes habituales
• Calcular las ganancias que tendrán en un mes especificado (considere que todos los
meses tienen treinta días).

El hotel posee información sobre cuales clientes son habituales. Esta estructura puede
manejarla con un diccionario, cuya clave sea el número de RUT y como significado tenga los
datos personales del cliente.

El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de pieza o clientes y a su

vez permitir agregar nuevas consultas.

Actor (UML)

En el Lenguaje Unificado de Modelado (UML), un actor "especifica un rol jugado por un usuario
o cualquier otro sistema que interactúa con el sujeto”.
Un actor modela un tipo de rol jugado por una entidad que interactúa con el sujeto (esto es,
intercambiando signos y datos), pero que es externo a dicho sujeto.1
Los actores pueden representar roles jugados por usuarios humanos, hardware externo, u otros
sujetos. Un actor no necesariamente representa una entidad física específica, sino simplemente
una faceta particular (es decir, un "rol") de alguna actividad que es relevante a la especificación
de sus casos de uso asociados. Así, una única instancia física puede jugar el rol de muchos
actores diferentes y, asimismo, un actor dado puede ser interpretado por múltiples instancias
diferentes.1

UML 2 no permite asociaciones entre Actores.1 2 A pesar de todo, esta restricción es

usualmente violada en la práctica, en la medida que la generalización/especialización de
relaciones entre actores es útil para el modelado de los comportamientos de superposición
entre actores.3
Archivo:Notacion Caso de Uso.svg

Ilustración de un actor, junto con los demás elementos de un diagrama de casos de uso

3
 Ejemplo sencillo de diagrama de casos de uso, donde se muestran los actores críticos de
comidas y chef

Implementación (Java)

1.
public class Test
{
public static void main( String arg[] )
{
try
{
State state = new ConcreteStateA();
Context context = new Context();
context.setState( state );
context.request();
}
catch( Exception e )
{
e.printStackTrace();
}
}
}

2.
public class Context
{
private State state;

4
 public void setState( State state )
{
this.state = state;
}

public State getState()

{
return state;
}

public void request()

{
state.handle();
}
}

3.
public interface State
{
void handle();
}

4.
public class ConcreteStateA implements State
{
public void handle()
{
}
}

public class ConcreteStateB implements State

{
public void handle()
{
}
}

5.
/**
* State patter:We have a specific class(Context) that manages the state changes of a external
class by creating different instance depending
* on the state you want to adopt.
* Every class that you create implements an interface(State) that define the method name that
they have to implement
* @author Pperez
*
*/

5
public class StatePattern {
public void main(String args[]){
try{
State state;
Context context = new Context();
SocketChannel socketChannel = null;
//-----------------------------\\
// OPEN/LISTENING SOCKET \\
//-----------------------------\\
//First State:
state = new ConnectSocketState(socketChannel);
context.setState( state );
socketChannel = context.request();
//-----------------------------\\
// CLOSE SOCKET \\
//-----------------------------\\
//Second State:
state = new CloseSocketState(socketChannel);
context.setState( state );
socketChannel = context.request();
}catch( Exception e ) {
e.printStackTrace();
}
}

public class Context

{
private State state;

public void setState( State state )

{
this.state = state;
}

public State getState()

{
return state;
}

public SocketChannel request()

{
return state.processState();
}
}
public interface State
{
SocketChannel processState();
}

public class ConnectSocketState implements State

{
SocketChannel socketChannel;

6
 public ConnectSocketState(SocketChannel socketChannel){
this.socketChannel=socketChannel;
}
public SocketChannel processState()
{
try {
int port = 21;
InetAddress host = InetAddress.getByName("192.168.1.1");
SocketAddress adress = new InetSocketAddress(host, port);
socketChannel = SocketChannel.open(adress);
socketChannel.configureBlocking(true);
} catch (IOException e) {
e.printStackTrace();
}
return socketChannel;
}
}

public class CloseSocketState implements State

{
SocketChannel socketChannel;
public CloseSocketState(SocketChannel socketChannel){
this.socketChannel=socketChannel;
}
public SocketChannel processState(){
try {
socketChannel.close();
} catch (IOException e) {
e.printStackTrace();
}
return socketChannel;
}
}

LORENZO VENTURA TENORIO

“PROGRAMACIÓN ORIENTADA A OBJETOS”
PROFR. LIC. INF. FREDDY ALONSO ORTÍZ ROSADO
ING. EN SISTEMAS COMPUTACIONALES
SISTEMA SEMI-ESCOLARIZADO. “ITSSAT”

SAN ANDRÉS TUXTLA, VER., FEBRERO DEL 2011