ADOO Clase 13 Manual

ANÁLISIS Y DISEÑO ORIENTADO A OBJETO.

CLASE 13.

UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Análisis y diseño Orientado a

Objeto – Clase 13

Esta semana describirás las características del Diagrama de Clases,

identificarás los elementos componentes de un diagrama de clases,

identificarás los componentes del diagrama para validar las

estructuras en un diagrama, reconocerás los componentes de un

diagrama de clases y reconocerás la relación entre el modelo

estático de clases y las tablas del modelo de base de datos.


Diagrama estático de clases.

Introducción al diagrama estático

de clases.

Como se vio en los capítulos anteriores, el mundo de los

diagramas UML es bastante extenso y cada diagrama tiene un

propósito específico y entre ellos muchas veces se complementan

para entregar información más específica respecto a un proceso en

particular, o la forma en que se deben realizar las cosas.

Uno de los diagramas que nos va a permitir mostrar la forma en

que los diferentes componentes del software interactúan entre si,

es el diagrama estático de clases.

Piensa en lo siguiente, la mayoría de las cosas que conocemos

están formadas por varias partes las cuales se complementan para

realizar una tarea específica, la cual no podría ser realizada por

ninguna de las partes por separado.

Por ejemplo cuando quieres prender tu televisor y te encuentras a

una distancia apreciable, vas a tener la tendencia natural a utilizar

el control remoto, si te fijas, para lograr prender el televisor, tú

como objeto, estás interactuando con el control remoto (otro

objeto) el cual envía una señal al televisor (otro objeto) y

finalmente el televisor se enciende.


Si analizas el comportamiento que tienen los objetos, podemos

definir que el objeto persona envía un mensaje al objeto control

remoto que a su vez se comunica con el objeto televisor para

realizar una acción. De esta forma tú no enciendes el televisor, es

el control remoto el que solicita al televisor que se encienda.

Una de las funciones del diagrama estático de clases es el poder

mostrar la forma en que los objetos se comunican y relacionan.

Utilidad del diagrama estático de clases. El diagrama estático de clases como lo vimos, permite obtener

información referente a 2 vistas en particular. La primera dice

relación con la forma en que los objetos se componen, es decir sus

características y la forma en que se comportan, y la segunda es

analizar la forma en que las clases se relacionan.

El diagrama permite tener una vista estática del problema el cual

no va a cambiar con el tiempo. Este diagrama adicionalmente nos

va a permitir avanzar en una concepción más acabada de cómo

todos los procesos que determinamos en el diagrama de casos de

uso se van a convertir en una aplicación de software o en un

proyecto de algún otro tipo (recuerda que una de las ventajas de

UML es que no sólo sirve para diseñar software). Cabe señalar que

el diagrama estático de clases no hace sólo referencia a como las

distintas partes del software interactúan sino que también puede

incluir hardware, y todos los otros componentes que forman un

proyecto informático.

En cursos más avanzados en la línea de programación verás el

cómo poder interpretar este diagrama estático de clases y

convertirlo en una aplicación o al menos en una parte de ella. Una

de las ventajas de la orientación a objetos es que las aplicaciones


de software se pueden construir por partes sin que esto afecte el

total de la aplicación y adicionalmente esta parte que construyes la

puedes reutilizar en otros proyectos.

Componentes del diagrama estático de

clases.

Para comprender cómo podemos construir un diagrama estático de

clases primero vamos a conocer los distintos componentes de este

diagrama y que representan, además de cómo se relacionan unos

con otros y los diferentes significados que estos van a tomar en

función de como se relacionen.

Lo primero que debes entender es que existe una diferencia entre

la clase y el objeto, aunque muchas veces tendemos a confundirlos

producto de malos entendidos.

La clase es la muy parecido al plano de construcción de un edificio

o al diseño que hace un ingeniero en electrónica de un circuito

impreso, es decir acá se define la forma en que se van a construir

los objetos. Por lo tanto podemos decir que un objeto es la

construcción física basándonos en las especificaciones de una

clase. A continuación se define formalmente el concepto de clases

y objetos.

“descripción generalizada (por ejemplo, una plantilla, un patrón o

un prototipo) que describe una colección de objetos similares”1

“descriptor de un conjunto de objetos que comparten los mismos

atributos, operaciones, métodos, relaciones y comportamiento”2

1 Ingeniería del Software: Un enfoque práctico, Roger S. Pressman, McGraw-Hill/Interamericana de España, S.A.U. © 2002,

ISBN 84-481-3214-9


Si te fijas en las definiciones anteriores, éstas siempre hacen

referencia a un descriptor o plantilla o prototipo, es decir en una

clase es necesario hacer la definición de las características y las

acciones que realizarán los objetos. Para lograr este cometido

primero debes tener en claro el modelo que quieres representar.

Recuerda que una de las partes más complejas del desarrollo de

proyectos de tecnologías de información es tratar de definir de

forma correcta los requerimientos que tenga la contraparte.

Recuerda el ejemplo del bunker para el apocalipsis zombi. Si bien

un bunker para un apocalipsis nuclear te podría servir, el bunker

para el apocalipsis zombi tiene otras características que son

necesarias, por ejemplo muchas motosierras, y por lo tanto

suficiente combustible, y un sin número de armas corto punzantes

(machetes, espadas, katanas, etc.) que serán de mucha utilidad

cuando salgas a explorar los alrededores.

Una vez que tengas muy claro las necesidades de la contraparte

puedes comenzar a pensar en la funcionalidad que debe tener el

sistema y como cada una de estas funciones está pensada para un

tipo de usuario. Por ejemplo el sistema de transporte público tiene

funciones pensadas para diferentes usuarios (pasajeros, pasajeros

con capacidades de desplazamiento limitadas y choferes). Cada

uno de ellos utiliza funcionalidades distintas del sistema, por

ejemplo sólo el chofer puede manejar. Cuando logras definir las

funciones y quien las utiliza en el sistema, entonces puedes

construir un diagrama de casos de uso (visto en el capítulo

anterior). ¿y que paso con las clases? Cuando logras establecer el

comportamiento del sistema y los usuarios que interactúan con el

sistema analizado, entonces estás en condiciones de pasar a la

2 El Lenguaje Unificado de Modelado. Manual de Referencia, Pearson Educación, S.A. © 2000, ISBN 84-7829-037-0


siguiente etapa del proceso de análisis, que corresponde a tratar

de hacer una agrupación de funcionalidades que implementa el

sistema y agrupar estas funciones, si bien esto suena complejo, no

te preocupes esto lo has hecho de forma natural durante toda tu

vida, la diferencia es que no te habías dado cuenta. Para muestra

un ejemplo.

Supongamos que te encuentras leyendo este manual en la sala de

clases, si te fijas, la sala esta llena de objetos que interactúan

entre si y que en conjunto logran un objetivo, que en este caso es

el traspaso de conocimiento desde el docente al alumno. Ahora

debes tener en cuenta que los objetos que viven en esta sala de

clases, lo hacen con un propósito, este propósito está asociado a

su entorno, es decir, las actividades que realiza el alumno en la

sala de clases son diferentes a las acciones que realiza la misma

persona cuando va a comprar al supermercado, aunque se trate de

la misma persona.

Lo anterior nos demuestra que existe un ámbito para los objetos

en el cual el objeto se comporta de una forma específica y posee

ciertas características que están asociadas a los procesos que este

realiza. Por ejemplo, para estudiar, el alumno necesita materia que

le entrega el profesor, adicionalmente el profesor califica el

desempeño del alumno con una nota, si te fijas en el ejemplo

anterior, cada uno de los objetos realiza un proceso y ese proceso

lo realiza con un conjunto de datos que les es propio o que algún

otro objeto les entrega. Este proceso de abstracción mental en el

análisis de los procesos que se ve tan complejo en realidad tú lo

llevas haciendo desde pequeño seguramente sin darte cuenta.


Volvamos ahora hacia las clases y su representación en el modelo.

Como vimos anteriormente, en el mundo real los objetos

interactúan entre sí y poseen datos que les permiten realizar sus

procesos, esos datos a su vez definen el comportamiento posible

de los objetos. Volvamos a ver un ejemplo, si tuviéramos que

definir un lápiz en orientación a objetos, tendríamos que definir

sus características o atributos y su funcionalidad.

Definición del lápiz

En los objetos la función y las características siempre están unidos

y nunca se separan, de esta forma, la función afecta a la

característica y viceversa, por ejemplo cuando el lápiz raya, esta

acción hace que la cantidad de tinta disminuya, cuando la cantidad

de tinta llega a 0, ¿Puede seguir rayando el lápiz? . Si analizas los

comportamientos de muchos objetos que te rodean te darás

cuenta de que esta unión entre las características y la función

siempre se encuentra y es fácil de descubrir, por ejemplo, si

enciendo la ampolleta con el interruptor, ¿que otra cosa puede

hacer el interruptor? , ¿Puede volver a encender la luz?, ¿o

primero debe apagarla?. Fíjate que al encender o apagar la

ampolleta, estas cambiando el estado de la ampolleta (una

característica que posee) y al apagarla, esto también ocurre, pero


al estar encendida, esta sólo se puede apagar, ¿te das cuenta de la

relación?, si aún no queda claro, acá va otro ejemplo.

Supongamos que puedes viajar al pasado y logras traer de vuelta

a un tiranosaurio rex como mascota, si te fijas bien en su

comportamiento, te darás cuenta de que tu nueva mascota, entre

todas las cosas que hace, come bastante y además camina y ruge,

fíjate además que para cada una de esas acciones que realiza, la

nueva mascota utiliza energía, sólo puede realizar las acciones

antes descrita si la cantidad de energía es mayor a 0. Ahora bien

cada vez que realiza una acción, la cantidad de energía se

disminuye una cierta cantidad de unidades, pero cuando come, la

cantidad de energía acumulada aumenta. Con esto vemos que los

atributos o características de una clase se ven modificados por las

acciones o métodos, de la misma forma, si el dinosaurio mascota

no se alimenta, su cantidad de energía será 0 y por lo tanto no

podrá realizar ninguna de las acciones antes descritas.

Muy bien, ahora te debes estar preguntando ¿Y que paso con los

gráficos del diagrama?, ahora vamos a eso, en UML, la

representación de las clases, sus atributos y sus métodos se

realiza mediante una representación gráfica que muestra un

rectángulo dividido en 3 partes, la superior contiene el nombre de

la clase, la parte central la definición de los atributos de las clases

y la parte inferior los métodos o comportamiento de la clase. Para

muestra un ejemplo:


Fíjate que cada una de las secciones posee ciertas características

con respecto a la forma en que éstas se definen.

Nombre de la clase: Esta se debe escribir centrada en la página y

con formato de texto ennegrecido, adicionalmente existe una

nomenclatura para la escritura de los nombres que si bien no es

estándar es la que se recomienda. Consiste en escribir el nombre

con un formato conocido como PascalCasing, este formato nos

solicita que escribamos el nombre con la primera letra en

mayúsculas y el resto en minúsculas, por ejemplo “Alumno”, ahora

si el nombre es un nombre compuesto, sugiere que las primeras

letras de cada una de las palabras tengan este formato, por

ejemplo “MascotaSaurio”.

Atributos: Los atributos se definen dentro de la clase utilizando un

formato llamado camelCasing, este formato define que la primera

letra se escriba en minúsculas al igual que todas las otras, a

menos que tengas que crear un atributo compuesto que en este

caso solicita que la primera palabra la escribas en minúsculas pero

la primera letra de la segunda palabra la escribas con mayúsculas,

esta misma lógica se da si tienes más de dos palabras, por

ejemplo “edad”, fechaNacimiento”, tamañoPueraTrasera”.


Además cada atributo debe definir su tipo, en UML existen algunos

tipos de datos primitivos por ejemplo Integer, String, Boolean, etc,

pero también se pueden agregar otros tipos que permitan

aumentar la capacidad de tu modelo, esto se hace en función

generalmente del lenguaje de programación con el que se vaya a

generar el software al final.

Otra cosa que debes tener presente es que los atributos y los

métodos poseen niveles de visibilidad que determinan si un

atributo o método es visible desde fuera de la clase, esto es lo que

se denomina como la interfaz de una clase, es decir el conjunto de

atributos y de métodos con los cuales el objeto se comunica con su

ambiente, el siguiente ejemplo lo puede clarificar.

Lo más probable es que alguna vez hayas utilizado un reproductor

de DVD, el uso general indica que el reproductor se enciende, se

abre la bandeja, se pone el DVD en el interior y si todo esta

correctamente conectado, se comenzará a reproducir el contenido

del DVD. Ahora fíjate que tú interactuaste con el reproductor de

varias formas, pero algunas otras quedaron ocultas, ¿tú encendiste

el láser del DVD, realizaste la demultiplexión de la señal óptica

para ser transformada en audio y video?, lo más probable es que

no, tú sólo interactuaste con los botones del equipo y con el disco

en cuestión, pero el resto del proceso se realizó sin tu

intervención. En este caso la interfaz del DVD es el conjunto de

botones con los cuales tú puedes hacer que este funcione. Todos

los objetos con los cuales interactuamos presentan una interfaz y

poseen un conjunto de métodos y propiedades con las que no

podemos interactuar pues están ocultas para nosotros. Esta

característica de ocultar comportamiento y acceso a las

propiedades de una clase se realiza por un tema de seguridad,


pues te imaginas cuantos ojos quemados existirían si te

permitieran manipular el láser o encender la chispa para prender

un motor,

De esta forma el atributo se define con el siguiente formato:

Nombre_atributo: tipo_dato=valor_inicial

Si te acuerdas del tema de la visibilidad, los atributos de las clases

se clasifican en privados (-) o públicos (+), para entender de que

se trata esto, piensa en lo siguiente, cuando enciendes el DVD, la

velocidad del motor que mueve el DVD es imposible que la

podamos acelerar o disminuir desde afuera, en este caso la

velocidad del motor es una atributo privado para la clase es decir

sólo se puede modificar desde dentro de la propia clase y se le

anota un signo - delante. Sin embargo, cuando por ejemplo

apagamos el interruptor de la ampolleta, la estamos apagando y

por lo tanto estamos modificando desde afuera una característica

de esta clase, en este caso la propiedad se define como pública y

se le anota un signo + delante del atributo.

De esta forma los atributos de la clase se anotan de la siguiente

forma:

-energiaZombi: Integer=100;

-escudoProtector: Integer=20;

Los métodos de la clase también tienen una nomenclatura

específica, en este caso los métodos se anotan de la siguiente

forma:

NombreMetodo(atributo:tipoDato)


En este caso también debemos explicar algunas cosas respecto al

formato, el nombre del método representa el nombre del

comportamiento de la clase, este nombre debe ser significativo o

sea que te permita saber fácilmente que es lo que el método hace,

sólo con leer su nombre, por ejemplo, que es más fácil de

determinar, el comportamiento de un método que se llama

liquidarZombi(), o un método llamado x25rst45(), si te fijas, el

primer método se explica por si sólo, mientras que el segundo no.

Adicionalmente al nombre si te fijas entre paréntesis aparecen

variables, es decir valores que se identifican con un nombre y que

son de un tipo de dato específico, estas variables el método las

ocupa para poder tener información adicional que es parte del

mensaje que el objeto recibe para poder ejecutar el método. Los

objetos no hacen nada a menos que otro objeto se los pida, por

ejemplo el control remoto no enciende el televisor a menos que

nosotros se lo solicitemos, o por ejemplo el vehículo no se mueve

a menos que nosotros presionemos el pedal del acelerador, en este

caso la cantidad de presión que apliquemos al pedal será la

velocidad de salida del automóvil, si te fijas en este caso lo

podemos representar de la siguiente forma:

+acelerar(fuerza:Integer)

Por lo tanto ahora podemos representar clases como corresponde,

es decir:


Relación entre las clases y las

tablas de un modelo entidad

relación.

Como podemos observar, al crear y definir las clases, estas se

pueden analizar como un conjunto de datos sobre los cuales se

aplican un conjunto de métodos.

Este análisis de los procesos agrupando primero los datos, se

parece mucho al análisis que se realiza en la disciplina de base de

datos para crear las “entidades” de datos que nos van a permitir

agrupar los datos en registros que a su vez construyen lo que se

conoce como bases de datos.

Las bases de datos no son más que un conjunto de datos

agrupados alrededor de un concepto, o una idea (igual que las

clases). Si bien las estructuras se parecen, estas no son iguales y a

veces esto lleva a los programadores a cometer algunos errores.

Por ejemplo, si te enfrentas a un problema que implique el

modelar el comportamiento de un alumno en un sistema de

matrícula, entonces, el modelo de la clase se podría graficar de la

siguiente forma:


Ahora fíjate en el modelo de la entidad que se puede crear para la

misma estructura.

Si te fijas, los dos elementos se parecen mucho en su definición, la

diferencia está en que la clase posee los métodos de la clase y

adicionalmente, la forma en que se relacionan los elementos son

distintos.

ADOO Clase 13 Manual

Documents

Transcript of ADOO Clase 13 Manual