GUIAS DE CONCEPTUALIZACION ACERCA DE PROGRAMACIÓN

ORIENTADA A OBJETOS Y LENGUAJE UML

Presentado Por:
Ivan Ricardo Silva Ruiz

Presentado a:
Ing. Raul Ortiz

Centro Nacional de Aprendizaje SENA

Gestión Comercial y Teleinformática
Bogota, Colombia
2005
 OBJETIVOS

• Identificar y analizar aspectos generales y sobresalientes de la

programación orientada a objetos y desarrollo de lenguaje UML en
cuanto a conceptualizacion se refiere, para una mejor comprensión de
los mismos.
Actualmente una de las áreas más sobresalientes en la industria y en el sector
académico es la orientación a objetos. La orientación a objetos promete
mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento
del software ofreciendo una solución a largo plazo a los problemas y
preocupaciones que han existido desde el comienzo en el desarrollo software:
la falta de portabilidad del código, código que es difícil de modificar, aparte
de mejoras en la abstracción de procesos para la solución de problemas.

Un lenguaje orientado a objetos ataca estos problemas. Tiene tres

características básicas: debe estar basado en objetos, basado en clases y capaz
de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos
puntos; muchos menos cumplen los tres.

El elemento fundamental de la POO es, como su nombre lo indica, es el

objeto. Se puede definir un objeto como un conjunto complejo de datos y
programas que poseen estructura y forman parte de una organización.
Lo cual quiere decir que un objeto no es un dato simple, sino que contiene en
su interior cierto número de componentes bien estructurados. En segundo
lugar, cada objeto no es un ente aislado, sino que forma parte de una
organización jerárquica o de otro tipo.

ESTRUCTURA DE UN OBJETO

Un objeto puede considerarse como una especie de cápsula dividida en tres

partes:
1 - Clase
2 - Atributos
3 - Métodos
Cada uno de estos componentes desempeña un papel totalmente
independiente:

Las Clases permiten que el objeto se inserte en la organización (pertenezca a

un conjunto en particular).
Las Atributos distinguen un objeto determinado de los restantes que forman
parte de la misma organización y tiene valores que dependen de la Clase de
que se trate. Los Atributos de un objeto pueden ser heredadas a sus
descendientes en la organización.
Los Métodos son las operaciones que pueden realizarse sobre el objeto, que
normalmente estarán incorporados en forma de programas (código) que el
objeto es capaz de ejecutar y que también pone a disposición de sus
descendientes a través de la herencia.

Encapsulamiento y ocultación

Cada objeto es una estructura compleja en cuyo interior hay datos y

programas, todos ellos relacionados entre sí, como si estuvieran encerrados
conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de
las características fundamentales en la POO.
Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o
incluso los programadores conozcan cómo está distribuida la información o
qué información hay disponible. Esta propiedad de los objetos se denomina
ocultación de la información.

Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario
respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran
cosa con él. Lo que sucede es que las peticiones de información a un objeto.
deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la
operación pertinente. La respuesta a estas ordenes será la información
requerida, siempre que el objeto considere que quien envía el mensaje está
autorizado para obtenerla.

El hecho de que cada objeto sea una cápsula facilita enormemente que un
objeto determinado pueda ser transportado a otro punto de la organización, o
incluso a otra organización totalmente diferente que precise de él. Si el objeto
ha sido bien construido, sus métodos seguirán funcionando en el nuevo
entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la
reutilización de programas.

CLASES

Las relaciones entre objetos son, precisamente, los enlaces que permiten a un
objeto relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:
-Relaciones jerárquicas. Son esenciales para la existencia misma de la
aplicación porque la construyen.
Son bidireccionales, es decir, un objeto es padre de otro cuando el primer
objeto se encuentra situado inmediatamente encima del segundo en la
organización en la que ambos forman parte; asimismo, si un objeto es padre de
otro, el segundo es hijo del primero.
Una organización jerárquica simple puede definirse como aquella en la que un
objeto puede tener un solo padre, mientras que en una organización jerárquica
compleja un hijo puede tener varios padres.

ATRIBUTOS

Todo objeto puede tener cierto número de propiedades, cada una de las cuales
tendrá, a su vez, uno o varios valores. En POO, las propiedades corresponden
a las clásicas "variables" de la programación estructurada. Son, por lo tanto,
datos encapsulados dentro del objeto, junto con los métodos (programas) y las
relaciones (punteros a otros objetos). Las propiedades de un objeto pueden
tener un valor único o pueden contener un conjunto de valores mas o menos
estructurados (matrices, vectores, listas, etc.). Además, los valores pueden ser
de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo
permite.
Pero existe una diferencia con las "variables", y es que los atributos se pueden
heredar de unos objetos a otros. En consecuencia, un objeto puede tener una
atributo de maneras diferentes:
-Atributos propios: Están formadas dentro de la cápsula del objeto.
-Atributos heredados: Están definidas en un objeto diferente, antepasado de
éste (padre,"abuelo", etc.). A veces estas propiedades se llaman propiedades
miembro porque el objeto las posee por el mero hecho de ser miembro de una
clase.

METODOS

Una operación que realiza acceso a los datos. Podemos definir método como
un programa procedimental escrito en cualquier lenguaje, que está asociado a
un objeto determinado y cuya ejecución sólo puede desencadenarse a través de
un mensaje recibido por éste o por sus descendientes.
Son sinónimos de 'método' todos aquellos términos que se han aplicado
tradicionalmente a los programas, como procedimiento, función, rutina, etc.
Sin embargo, es conveniente utilizar el término 'método' para que se distingan
claramente las propiedades especiales que adquiere un programa en el entorno
POO, que afectan fundamentalmente a la forma de invocarlo (únicamente a
través de un mensaje) y a su campo de acción, limitado a un objeto y a sus
descendientes, aunque posiblemente no a todos.

Si los métodos son programas, se deduce que podrían tener argumentos, o

parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros,
un objeto puede disponer de un método de dos maneras diferentes:
-Métodos propios. Están incluidas dentro de la cápsula del objeto.
-Métodos heredados. Están definidos en un objeto diferente, antepasado de
éste (padre,"abuelo", etc.). A veces estos métodos se llaman métodos miembro
porque el objeto los posee solo por el hecho de ser miembro de una clase.

Polimorfismo

Una de las características fundamentales de la POO es el polimorfismo, que

no es otra cosa que la posibilidad de construir varios métodos con el mismo
nombre, pero con relación a la clase a la que pertenece cada uno, con
comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo
mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo
mensaje global pero responderían a él de formas diferentes; por ejemplo, un
mensaje "+" a un objeto ENTERO significaría suma, mientras que para un
objeto STRING significaría concatenación ("pegar" strings uno seguido al
otro)

Modularidad

En la programación por módulos, los procedimientos con una funcionalidad

común son agrupados en módulos separados. Un programa por consiguiente,
ya no consiste solamente de una sección. Ahora está dividido en varias
secciones más pequeñas que interactúan a través de llamadas a procedimientos
y que integran el programa en su totalidad.
Cada módulo puede contener sus propios datos. Esto permite que cada módulo
maneje un estado interno que es modificado por las llamadas a procedimientos
de ese módulo.
 UML

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling

Language) es un lenguaje gráfico para visualizar, especificar y documentar
cada una de las partes que comprende el desarrollo de software u cualquier
otra situación que no sea necesariamente del tipo informatico.

Una parte del UML define, entonces, una abstracción con significado de un
lenguaje para expresar otros modelos (es decir, otras abstracciones de un
sistema, o conjunto de unidades conectadas que se organizan para conseguir
un propósito). Lo que en principio puede parecer complicado no lo es tanto si
pensamos que uno de los objetivos del UML es llegar a convertirse en una
manera de definir modelos, no sólo establecer una forma de modelo, de esta
forma simplemente estamos diciendo que UML, además, define un lenguaje
con el que podemos abstraer cualquier tipo de modelo.

El UML es una técnica de modelado de objetos y como tal supone una

abstracción de un sistema para llegar a construirlo en términos concretos. El
modelado no es más que la construcción de un modelo a partir de una
especificación.

Un modelo es una abstracción de algo, que se elabora para comprender ese

algo antes de construirlo. El modelo omite detalles que no resultan esenciales
para la comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana: antes de

construir una casa el arquitecto utiliza un plano, los músicos representan la
música en forma de notas musicales, los artistas pintan sobre el lienzo con
carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen
una realidad compleja sobre unos bocetos, modelos al fin y al cabo.

Los modelos además, al no ser una representación que incluya todos los
detalles de los originales, permiten probar más fácilmente los sistemas que
modelan y determinar los errores. Es posible enseñar al cliente una posible
aproximación de lo que será el producto final.
· Proporcionan una primera aproximación al problema que permite visualizar
cómo quedará el resultado.
· Reducen la complejidad del original en subconjuntos que son fácilmente
tratables por separado.

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista

de la realidad que modela mediante los distintos tipos de diagramas que posee.
Con la creación del UML se persigue obtener un lenguaje que sea capaz de
abstraer cualquier tipo de sistema, sea informático o no, mediante los
diagramas, es decir, mediante representaciones gráficas que contienen toda la
información relevante del sistema.
Un diagrama es una representación gráfica de una colección de elementos del
modelo, que habitualmente toma forma de grafo donde los arcos que conectan
sus vértices son las relaciones entre los objetos y los vértices se corresponden
con los elementos del modelo. Los distintos puntos de vista de un sistema real
que se quieren representar para obtener el modelo se dibuja dé forma que se
resaltan los detalles necesarios para entender el sistema.

· Funcional: Muestra la funcionalidad del sistema desde el punto de vista del

usuario, incluye:
o Diagramas de caso de uso

· Objetos: Muestra la estructura y la subestructura del sistema usando objetos,

atributos, operaciones y asociaciones, incluye:
o Diagramas de clase

· Dinámico: Muestra el comportamiento interno del sistema, incluye:

o Diagramas de secuencia

Artefactos para el desarrollo de proyectos

Un artefacto es una información que es utilizada o producida mediante un

proceso de desarrollo de software. Pueden ser artefactos un modelo, una
descripción o un software. Los artefactos de UML se especifican en forma de
diagramas, éstos, junto con la documentación sobre el sistema constituyen los
artefactos principales que el modelador puede observar.

Se necesita más de un punto de vista para llegar a representar un sistema.

UML utiliza los diagramas gráficos para obtener estos distintos puntos de
vista de un sistema:
· Diagramas de Implementación.
· Diagramas de Comportamiento o Interacción.
· Diagramas de Casos de uso.
· Diagramas de Clases.

Diagramas de interacción o comportamiento

Muestran las interacciones entre objetos ocurridas en un escenario (parte) del

sistema. Hay de varios tipos
· Diagrama de secuencia
· Diagrama de colaboración
· Diagrama de estado
· Diagrama de actividad

Muestran las interacciones entre un conjunto de objetos, ordenadas según el

tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos,
que tienen un significado parecido al de los objetos representados en los
diagramas de colaboración, es decir son instancias concretas de una clase que
participa en la interacción. El objeto puede existir sólo durante la ejecución de
la interacción, se puede crear o puede ser destruido durante la ejecución de la
interacción. Un diagrama de secuencia representa una forma de indicar el
período durante el que un objeto está desarrollando una acción directamente o
a través de un procedimiento.
En este tipo de diagramas también intervienen los mensajes, que son la forma
en que se comunican los objetos: el objeto origen solicita (llama a) una
operación del objeto destino. Existen distintos tipos de mensajes según cómo
se producen en el tiempo:simples,sincronos, y asíncronos.

Los diagramas de secuencia permiten indicar cuál es el momento en el que se

envía o se completa un mensaje mediante el tiempo de transición, que se
especifica en el diagrama.
Diagrama de colaboración

la interacción entre varios objetos y los enlaces que existen entre ellos.
Representa las interacciones entre objetos organizadas alrededor de los objetos
y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama
de colaboraciones muestra las relaciones entre los objetos, no la secuencia en
el tiempo en que se producen los mensajes.
Los diagramas de secuencias y los diagramas de colaboraciones expresan
información similar, pero en una forma diferente.

Un enlace es una instancia de una asociación que conecta dos objetos de un

diagrama de colaboración. El enlace puede ser reflexivo si conecta a un
elemento consigo mismo. La existencia de un enlace entre dos objetos indica
que puede existir un intercambio de mensajes entre los objetos conectados.
Diagramas de estado

Representan la secuencia de estados por los que un objeto o una interacción

entre objetos pasa durante su tiempo de vida en respuesta a estímulos
(eventos) recibidos. Representa lo que podemos denominar en conjunto una
máquina de estados. Un estado en UML es cuando un objeto o una interacción
satisface una condición, desarrolla alguna acción o se encuentra esperando un
evento.

Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia

de un evento se dice que ha sufrido una transición, existen varios tipos de
transiciones entre objetos: simples (normales y reflexivas) y complejas.
Además una transición puede ser interna si el estado del que parte el objeto o
interacción es el mismo que al que llega, no se provoca un cambio de estado y
se representan dentro del estado, no de la transición. Como en todas las
metodologías OO se envían mensajes, en este caso es la acción de la que
puede enviar mensajes a uno o a varios objetos.

Diagramas de casos de uso

Unos casos de uso es una secuencia de transacciones que son desarrolladas por
un sistema en respuesta a un evento que inicia un actor sobre el propio
sistema. Los diagramas de casos de uso sirven para especificar la
funcionalidad y el comportamiento de un sistema mediante su interacción con
los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la
relación entre los actores y los casos de uso en un sistema. Una relación es una
conexión entre los elementos del modelo, por ejemplo la relación y la
generalización son relaciones.

Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del
sistema al mostrar como reacciona una respuesta a eventos que se producen en
el mismo.
En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es
una entidad externa al sistema que se modela y que puede interactuar con él;
un ejemplo de actor podría ser un usuario o cualquier otro sistema. Las
relaciones entre casos de uso y actores pueden ser las siguientes:
· Un actor se comunica con un caso de uso.
· Un caso de uso extiende otro caso de uso. <<Extend>>
· Un caso de uso usa otro caso de uso <<Use>>
Ejemplo de diagrama de caso de uso

Los casos de uso son los óvalos y las figuras con forma "humana" son los
actores.

Diagramas de clases

Los diagramas de clases representan un conjunto de elementos del modelo que

son estáticos, como las clases y los tipos, sus contenidos y las relaciones que
se establecen entre ellos
Algunos de los elementos que se pueden clasificar como estáticos son los
siguientes:

Paquete: Es el mecanismo de que dispone UML para organizar sus elementos ,

se representa un grupo de elementos del modelo. Un sistema es un único
paquete que contiene el resto del sistema, por lo tanto, un paquete debe
anidarse, permitiéndose que un paquete contenga otro paquete.

Clases: Una clase representa un conjunto de objetos que tienen una estructura,
un comportamiento y unas relaciones con propiedades parecidas. Describe un
conjunto de objetos que comparte los mismos atributos, operaciones, métodos,
relaciones y significado.
En UML una clase es una implementación de un tipo.
Los componentes de una clase son::

Atributo. Se corresponde con las propiedades de una clase o un tipo. Se

identifica mediante un nombre. Existen atributos simples y complejos.
Operación. También conocido como método.

Ejemplo de diagrama de clases

Ejemplo de diagrama de secuencia

Diagrama de secuencia. Este diagrama describe la secuencia (simplificada) de

mensajes de un sistema de restaurante. El diagrama representa a un cliente
pidiendo comida y pagando.
Las líneas punteadas extendiéndose hacia abajo indican la línea de tiempo de
cada objeto. Las flechas representan mensajes (estímulos) de un "actor" u
objeto a otros objetos.