UNIVERSIDAD DE EL SALVADOR

FACULTAD DE INGENIERIA Y ARQUITECTURA

ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS
PROGRAMACION I
Ciclo II-2012

UNIDAD VI: INTRODUCCIN A LA PROGRAMACIN ORIENTADA A

OBJETOS
Objetivo de la Unidad: Conocer los conceptos bsicos de la Programacin Orientada a
Objetos, estudiar sus tcnicas y aplicarlas en la solucin de problemas.

Contenido de la Unidad:

6.1 Programacin Orientada a Objetos

6.2 PE frente a POO
6.3 Terminologa Bsica
6.4 Tcnicas de la POO
6.5 Lenguaje de Modelado UML

Introduccin
Los conceptos de la Programacin Orientada a Objetos (POO) tienen origen en Simula 67, un
lenguaje diseado para hacer simulaciones con naves areas. La idea surgi al agrupar los diversos
tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir
sus propios datos y comportamientos. Fueron refinados ms tarde en Smalltalk, desarrollado en
Simula en Xerox PARC (cuya primera versin fue escrita sobre BASIC) pero diseado para ser un
sistema completamente dinmico en el cual los objetos se podran crear y modificar en tiempo de
ejecucin en lugar de tener un sistema basado en programas estticos.
La Programacin Orientada a Objetos se fue convirtiendo en el estilo de programacin dominante a
mediados de los aos ochenta, en gran parte debido a la influencia de C++, una extensin del
lenguaje de programacin C. Su dominacin fue consolidada gracias al auge de las Interfaces
Grficas de Usuario (GUI), para las cuales la programacin orientada a objetos est particularmente
bien adaptada.

6.1 Programacin Orientada a Objetos

La Programacin Orientada a Objetos es un enfoque conceptual especfico para disear programas.
Es una forma de programar diferente concentrndose sobre todo en lo que se requiere obtener y no
en cmo obtenerlo.
Esta tcnica, se basa en la representacin del problema en modelos de objetos fsicos o simulados;
aunque la idea es abstracta y parece muy complicada, cuando se aplica a objetos fsicos en trminos
de sus clases, componentes, propiedades y comportamiento se vuelve ms clara.
La idea fundamental de la orientacin a objetos y de los lenguajes que implementan este paradigma
de programacin es combinar (encapsular) en una sola unidad tanto los datos como las funciones
que operan (manipulan) sobre los datos. Esta caracterstica permite representar los objetos del
mundo real, mucho ms eficientemente que con funciones y datos de forma separada o
independiente (como lo hace la Programacin Estructurada, PE).
La POO (Programacin Orientada a Objetos), es un paradigma que utiliza objetos como elementos
fundamentales en la construccin de una solucin. Un objeto es una abstraccin de algn hecho
ente del mundo real que tiene atributos que representan sus caractersticas y propiedades; y
mtodos que representan su comportamiento. Todas las propiedades y mtodos comunes entre
objetos se encapsulan o se agrupan en clases.

Las propiedades ms importantes (tcnicas) de la POO son:

Abstraccin

Encapsulamiento y Ocultacin de datos

Polimorfismo

Herencia

Reusabilidad o Reutilizacin de Cdigo

6.2 Programacin Estructurada Frente a Programacin Orientada a Objetos

La POO difiere de la Programacin Estructurada Tradicional, en la forma en son manejados los
datos y los procedimientos, en PE (datos y procedimientos) estn separados y sin ninguna
relacin entre ellos; ya que lo nico que se busca es el procesamiento de unos datos de
entrada para obtener otros de salida.
La Programacin Estructurada anima al programador a pensar sobre todo en trminos de
procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos
procedimientos manejan. Con esta tcnica de programacin, se disean mdulos (o
funciones), que procesan datos.
Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles
mensajes solicitndoles que realicen sus mtodos por s mismos.
Para realizar una comparacin, se listarn las ventajas y desventajas de estas dos formas de
programacin:
Tcnica de
programacin
Orientada
Objetos
(POO)

Estructurada (PE)

Ventajas

Desventajas

Fomenta la reutilizacin del

cdigo
Facilita
la
creacin
de
programas visuales
Agiliza el desarrollo de software
Permite crear sistemas ms
complejos
Son ms fciles de entender

Mayor complejidad para

adaptarse
Depuracin de cdigo ms
compleja

La estructura de los programas

es clara
El mantenimiento es fcil
Los bloques de cdigo son casi
auto explicativos
Programas ms sencillos y
rpidos de confeccionar
Es ms fcil realizar pruebas y

Cuando crece el cdigo se

dificulta el manejo del
cdigo fuente
La reutilizacin de cdigo
no se explota tanto como
en la POO

depuracin de los bloques

La Programacin Estructurada es la primera tcnica formal de programacin (naci a inicios de los
aos 60s), sigue estando en vigencia y es muy utilizada para iniciar el aprendizaje de la
programacin.
La Programacin Orientada a Objetos es una mejora de la Programacin Estructurada; sin embargo,
la mayor diferencia que existe entre ambas es la forma en que se organizan los programas.
En la actualidad se ha notado que muchas personas desean aprender POO dejando de lado la PE,
esto es un error, ya que PE es la base de POO ya que esta ltima utiliza tcnicas como:
modularidad, estructura de datos entre otras. Por lo tanto si se desea aprender POO primero hay
que dominar la PE.
La Programacin Estructurada es ideal para realizar programas sencillos y para iniciar la
programacin. La Programacin Orientada a Objetos es recomendada para resolver problemas ms
complejos y requiere un mayor nivel de abstraccin del problema.

6.3 Terminologa Bsica

A continuacin se definen algunos elementos bsicos de la Programacin Orientada a Objetos con el
objetivo de familiarizarse con esta forma de programacin:
a) Objeto: es el centro de la Programacin Orientada a Objetos. Un objeto es algo que se visualiza,
se utiliza y que juega un papel o un rol. En POO el objeto representa alguna entidad de la vida
real. A travs del estudio de ellos se adquiere el conocimiento necesario para (mediante la
abstraccin y la generalizacin) agruparlos segn sus caractersticas en conjuntos.
Un objeto es cualquier elemento del medio ambiente real del problema que se va a resolver; posee
caractersticas fundamentales:
Identidad: En programacin la identidad de los objetos sirve para verificar mediante sus
caractersticas si dos objetos son iguales o no.

Comportamiento: El comportamiento de un objeto est directamente relacionado con

su funcionalidad y determina las operaciones que este puede realizar o a las que puede
responder ante mensajes enviados por otros objetos.

Estado: El estado de un objeto se refiere al conjunto de los valores de sus atributos en

un instante de tiempo dado. El comportamiento de un objeto puede modificar el estado de
ste. Cuando una operacin de un objeto modifica su estado se dice que esta tiene
"efecto colateral".

b) Atributos: son las caractersticas individuales que diferencian un objeto de otro y determinan su
apariencia, estado u otras cualidades; son propiedades del objeto. Por ejemplo, para el objeto
automvil, algunos de sus atributos son: propietario, marca, ao de matrcula, potencia etc.
Atributos son los datos o variables que caracterizan el objeto y cuyos valores indican en un momento
dado su estado. Para el objeto estudiante algunos de sus atributos podran ser: carnet, nombre,
carrera, asignaturas aprobadas, etc.
La identidad y estado de los objetos, tienen que ver con los atributos, y estos pueden ser modificados
por el comportamiento de los objetos.

c) Clase: es la representacin de un conjunto de objetos del mismo tipo, es decir que los distinguen
los mismos atributos y las mismas funciones (o comportamiento).
Es la definicin (o implantacin) de un tipo abstracto de datos; es decir que una clase describe no
slo los atributos de los objetos que la forman, sino que tambin incluye sus procesos (funciones o
comportamiento).
Segn Luis Joyanes Aguilar, una clase es una caracterizacin abstracta de un conjunto de objetos.
d) Mtodos: son las operaciones (acciones o funciones) definidas para los objetos, y permiten
crearlos, cambiar su estado o consultar el valor de los atributos. Cuando se llama a una
operacin de un objeto se interpreta como el envo de mensaje a dicho objeto. En otras
palabras, un mtodo es una subrutina asociada a una clase.
Algunos de los diferentes tipos de mtodo que existen son los siguientes:
Mtodo Get (para ver o consultar valores de atributos)
Mtodo Set (para asignar valores de atributos)
Mtodos de actualizacin (para cambiar valores por medio de clculos)
e) Relaciones entre Clases: los objetos del medio ambiente no permanecen aislados y
separados unos de los otros, todo lo contrario se comunican entre s para poder apoyarse y ayudarse
entre s. De la misma forma las clases que forman parte del ambiente de un problema se relacionan
entre s y con ello se permite que los objetos colaboren entre s e intercambien informacin.
Las relaciones entre clases pueden ser las siguientes:
Asociacin: Es la relacin ms importante y comn entre clases. Refleja una relacin
entre dos clases independientes que se mantiene durante la vida de los objetos de
dichas clases o al menos durante un tiempo prolongado.

Agregacin: Es un tipo especial de asociacin en el que la clase de donde parte la

relacin representa el todo y las clases relacionadas a sta las partes. Es decir que
las partes pueden seguir funcionando an sin el todo.

Composicin: Este tipo de relacin entre clases indica dependencia entre ellas, indica
que una clase es parte esencial de otra; es una relacin mucho ms fuerte que la
agregacin ya que de eliminarse una clase, deja de existir la otra. Dicho de otra forma, si
la clase origen el todo se elimina o destruye, las otras clases (o las partes) tambin se
destruyen.

Dependencia: Esta relacin indica la necesidad de una clase hacia otra, es decir que la
implantacin de una clase depende de otra; los mtodos u operaciones de una clase
requiere de los atributos de los objetos de la otra clase.

Herencia: Indica que una Subclase hereda los mtodos y atributos especificados por
una Superclase, por ende la Subclase adems de poseer sus propios mtodos y atributos,
poseer las caractersticas y atributos visibles de la Superclase.

6.4 Tcnicas de la POO

6.4.1 Abstraccin
Una forma de reducir la complejidad de un problema o situacin es la abstraccin. Las caractersticas
y procesos de cualquier sistema se resumen en los aspectos ms esenciales y relevantes.
En computacin, la abstraccin es el proceso crucial de representar la informacin en trminos de su
interfaz con el usuario.
Un ejemplo de abstraccin expresada de diferentes formas segn la aplicacin a desarrollar, puede
ser un auto.

Un auto es la composicin de diferentes partes (motor, ruedas, puertas, asientos etc.)

Un auto es un trmino comn que define a tipos diferentes de automviles, es decir es una
categora que puede servir para agrupar, por ejemplo las diferentes marcas (BMW, Seat,
Toyota entre otras) o por su categora (deportivos, clsicos, pick-up, etc).

Si los miembros de autos o las diferencias entre autos individuales no son relevantes, entonces se
utilizan expresiones y operaciones tales como: se fabrican autos, se usan autos para trasladarse de
un lado a otro, se descompone el auto en sus partes, etc.

6.4.2 Encapsulamiento y Ocultacin de Datos

La encapsulacin es la reunin en una cierta estructura, de todos los elementos que a un cierto nivel
de abstraccin se pueden considerar pertenecientes a una misma entidad y tambin es el proceso de
agrupamiento de datos y operaciones relacionadas bajo una misma unidad de programacin, lo que
permite aumentar la cohesin de los componentes del sistema.
Todos estos objetos que presentan caractersticas y comportamientos similares, se agrupan en
clases las cuales son utilizadas para encapsular los datos

6.4.3 Polimorfismo
Es la capacidad del cdigo de un programa para ser utilizado con diferentes tipos de datos u objetos.
Tambin se puede aplicar a la propiedad que poseen algunas operaciones de tener un
comportamiento diferente, dependiendo del objeto (o tipo de dato) sobre el que se aplican. As, en
un lenguaje de programacin el operador + representa la suma de dos nmeros ( x + y ) de
diferentes tipos: enteros, flotantes. Pero tambin, el mismo operador puede definir la operacin de
sumar dos cadenas: concatenacin. De modo similar, suponiendo un nmero de figuras geomtricas
que responden todas al mensaje CalcularArea; cada objeto reacciona a este mensaje haciendo el
clculo correspondiente de la superficie, el cual difiere de una figura a otra:

6.4.4 Herencia
Proporciona la facilidad de heredarle caractersticas de una Superclase a una Subclase y es
comnmente utilizada en la POO. La idea principal es crear una clase que encapsule todos los
elementos o caractersticas generales que pueda y a partir de sta, heredarle parcial o totalmente las
caractersticas a objetos de una subclase.

6.4.5 Reusabilidad o Reutilizacin de Cdigo

Se refiere al comportamiento y a las tcnicas que garantizan que una parte o la totalidad de un
programa informtico existente se pueda emplear en la construccin de otro programa. De esta
forma se aprovecha el trabajo anterior, se economiza tiempo, y se reduce la redundancia.
La manera ms fcil de reutilizar cdigo es copiarlo total o parcialmente desde el programa antiguo al
programa en desarrollo. Pero es trabajoso mantener mltiples copias del mismo cdigo, por lo que
en general se elimina la redundancia dejando el cdigo reusable en un nico lugar, y llamndolo
desde los diferentes programas. Este proceso se conoce como abstraccin. La abstraccin puede
verse claramente en las bibliotecas de software, en las que se agrupan varias operaciones comunes
a cierto dominio para facilitar el desarrollo de programas nuevos. Hay bibliotecas para convertir
informacin entre diferentes formatos conocidos, acceder a dispositivos de almacenamiento
externos, proporcionar una interfaz con otros programas, manipular informacin de manera conocida
(como nmeros, fechas, o cadenas de texto).
Para que el cdigo existente se pueda reutilizar, debe definir alguna forma de comunicacin o
interfaz. Esto se puede dar por llamadas a una subrutina, a un objeto, o a una clase.

6.5

Lenguaje de Modelado UML

El lenguaje utilizado para el modelado de los sistemas utilizando la Programacin Orientada a

Objetos es el UML. A continuacin se encuentran los conceptos bsicos del Lenguaje UML.
En la primera mitad de la dcada de los 90s, los lenguajes de modelado que imperaban eran OMT-2
(Object Modeling Technique), creado por James Rumbaugh, OOSE (Object Oriented Software
Engineering), creado por Ivan Jacobson y Booch93, creado por Grady Booch.
Grady Booch llam a James Rumbaugh y formaron equipo en una nueva Rational Corporation (cuyo
propietario era Grady) con el objetivo de fusionar sus dos mtodos. En octubre de 1994, Grady y

James comenzaron a trabajar en la unificacin de ambos mtodos produciendo una versin en

borrador llamada 0.8 y nombre Unified Method. A partir de 1995 Jacobson se une. El primer fruto
de su trabajo colectivo se lanz en enero de 1997 y fue presentado como versin 1.0 de UML. La
gran ventaja de UML es que fue recogiendo aportaciones de los grandes gurs de objetos: David
Hasel con sus diagramas de estado; partes de la notacin de Fusion, el criterio de responsabilidadcolaboracin y los diagramas de Rebeca Wirfs-Brock, y el trabajo de patrones y documentacin de
Gamma-Helm-Johnson-Ulissides.
En 1997 OMG acept UML como estndar (versin 1.1) y naci el primer lenguaje de modelado
visual orientado a objetos como estndar abierto de la industria. En 1998, OMG lanz dos revisiones
ms, 1.2 y 1.3. En el ao 2000 se present UML 1.4 con la importante aportacin de la semntica de
accin, que describe el comportamiento de un conjunto de acciones permitidas que se pueden
implementar mediante lenguajes de accin. La versin 1.5 sigui a las ya citadas.
En 2004 finaliz la versin 2.0 con su especificacin completa. UML 2 es ya un lenguaje de
modelado muy maduro. UML 2 ha incorporado numerosas mejoras a UML 1.x. Los cambios ms
importantes se han realizado en el metamodelo (generador de modelos), conservando los principios
fundamentales y evolutivos de las ltimas versiones. Los diseadores de UML 2.0 han tenido mucho
cuidado en asegurar que fuera totalmente compatible con las versiones anteriores para que los
usuarios de stas no tuvieran problemas de adaptacin. La versin UML 2.0 ha evolucionado para
superar los nuevos retos a los cuales se enfrentan el software y los nuevos desarrolladores de
modelos.
UML significa Lenguaje Unificado de Modelado (Unified Model Language) y es el lenguaje estndar
para el desarrollo de sistemas y de software utilizando POO. El lenguaje UML tiene una gran
aplicacin en la representacin y modelado de la informacin que se utiliza en las fases de anlisis y
diseo del ciclo de vida de los sistemas.
Un modelo es una abstraccin de cosas reales, es decir es una simplificacin del sistema real; en
pocas palabras es la representacin grfica de una situacin real, mediante una simbologa que
esquematiza clases, objetos, relaciones, etc. Entonces, si un modelo es la representacin grfica de
una situacin real; por lo tanto, modelado implica realizar un esquema (grfico o dibujo).
Con un lenguaje formal de modelado, el lenguaje es abstracto aunque tan preciso como un lenguaje
de programacin. Esta precisin permite que un lenguaje sea legible y que pueda ser interpretado,
ejecutado y transformado entre sistemas.
La siguiente figura presenta una forma de clasificacin de los diferentes diagramas UML:

Los diagramas estructurados se utilizan para capturar la organizacin fsica de las cosas del sistema.
Por ejemplo, cmo se relacionan unos objetos con otros. Mientras que, los diagramas de
comportamiento se centran en el comportamiento de los elementos de un sistema.
El Modelo Conceptual se ha diseado para proporcionar un marco de referencia, estructurado y
claramente definido para relacionar los datos con las necesidades de los usuarios.
La metodologa utilizada en la construccin de este Modelo tiene como primer paso, la identificacin
de los principales objetos que son de inters para los usuarios de la informacin en un dominio
particular. Cada uno de estos objetos clave, o entidades, sirve, por tanto, como foco de un grupo de
datos. Un modelo desarrollado usando estas tcnicas tambin representa la relacin entre diferentes
tipos de entidad.
Una vez que se ha establecido la estructura de alto nivel para el modelo mediante la identificacin de
las entidades y las relaciones entre , el siguiente paso es identificar las principales caractersticas o
atributos de cada entidad. A un nivel ms concreto, el modelo tambin puede describir la relacin
que pueda existir entre instancias.
En el diseo de cualquier modelo conceptual, dilucidar si algo es un atributo o una entidad
independiente es una decisin clave. El resultado de esta decisin depende del futuro uso del
atributo o entidad. Generalmente, las personas y los entes corporativos son entidades
independientes que podran relacionarse con las otras entidades establecidas en el citado modelo.
Convenciones Utilizadas en los Diagramas

a) Un rectngulo de lnea contnua representa una entidad (es decir, un objeto de inters para
los usuarios).
b) Un rectngulo de lnea punteada alrededor de un grupo de dos o ms entidades indica que
una relacin representada por una flecha contigua a la lnea de puntos puede aplicarse a
todas y cada una de las entidades representadas en el rectngulo.
c) Una flecha de una punta sobre una lnea representa una relacin en la que cada instancia de
la entidad del otro extremo de la lnea puede estar asociada con una sola instancia de la
entidad a la que apunta la flecha.
El objetivo de la Primera Etapa del Anlisis de Sistemas Orientado a Objetos es desarrollar un
Modelo Conceptual o Cualitativo, del sistema de inters. Una vez que se hayan definido claramente
los objetivos del proyecto, se usan como base para abstraer del sistema real aquellos componentes
que son relevantes para abordar las preguntas generadas.
A medida que se van seleccionando ciertos componentes y excluyendo otros, se van definiendo los
lmites del sistema de inters. Luego, se clasifican los componentes del modelo de acuerdo con el rol
especfico que tienen en la descripcin de la estructura del sistema y se identifican las relaciones
entre los componentes que generan la dinmica del sistema.
Posteriormente, se representa formalmente el modelo conceptual resultante usando un diagrama de
cajas y flechas. Las cajas representan los puntos de acumulacin de material y las flechas
representan las rutas a travs de las cuales el material fluye en el sistema.
Finalmente, se describen los patrones esperados del comportamiento del modelo por medio de
grficos que representan los cambios a lo largo del tiempo en los valores de las variables del sistema
que se consideran ms importantes.
En muchos aspectos el desarrollo del modelo conceptual es la etapa del anlisis de sistemas que
presenta el mayor desafo intelectual. La mejor base para tomar decisiones (las que a menudo son
subjetivas) acerca de cules componentes se deben incluir en el modelo est dada por el
conocimiento acerca del sistema real.
Existen dos estrategias generales para identificar los componentes del modelo: una de ellas consiste
en incluir pocos componentes y posteriormente aadir aquellos componentes crticos que
inicialmente fueron omitidos; la otra consiste en incluir todos los componentes que podran ser de
importancia en la etapa inicial, para luego descartar aquellos que parecen superfluos.
Tericamente el resultado final de las dos estrategias debera ser un modelo conceptual con el grado
mnimo de complejidad que permita abordar el problema. En la prctica es mejor comenzar con un
modelo que sea lo ms simple posible.
Etapas del Desarrollo del Modelo Conceptual
1. Definir los Objetivos del Modelo
2. Definir los Lmites del Sistema de Inters
3. Clasificar los Componentes del Sistema de Inters
4. Identificar las Relaciones entre los Componentes del Sistema
5. Representacin Formal del Modelo Conceptual
6. Describir los Patrones Esperados del Comportamiento del Modelo

Un Diagrama de Clases es una representacin grfica de las clases de un sistema. Sirve para
modelar el sistema en trminos de sus clases, atributos y las relaciones entre estos elementos.
En el diagrama se representan los requerimientos y la arquitectura general del sistema en
estudio. Se utiliza para capturar las relaciones estticas del software. Este tipo de diagramas
proporcionan un medio de capturar la estructura fsica de un sistema.
Este diagrama se utiliza en la etapa de anlisis del problema y diseo de la solucin. Los smbolos
ms utilizados en este diagrama son:
RECTANGULO: representa una clase, dividido en tres partes, una para el nombre de la clase, otra
para los atributos y la ltima para los mtodos o funciones.
NombreCla
se
Atri
but
os

FLECHAS: indican la relacin que existe entre dos clases. Las flechas pueden ser continuas o
punteadas, pueden tener punta o no y puede ser sustituda por rombos, segn sea la relacin que
Mt
indique, como se ver ms adelante:
odo
s

Multiplicidad o Cardinalidad en las Relaciones de Clases: indica el grado y nivel de

dependencia, se anotan en cada extremo de la relacin y stas pueden ser:
uno a muchos :
1..* (1..n)
0 a muchos :
0..* (0..n)
nmero fijo :
m (m denota el nmero).
Reglas para Nombrar Clases, Atributos y Mtodos.
Para poder distinguir una clase de otra, siempre es importante y necesario identificarlos con un
nombre que las diferencie entre s, para los atributos y mtodos debe hacerse tambin esta
distincin. Existen las siguientes reglas bsicas o convenciones que guardar para nombrarlos:
1. Se usan letras preferiblemente, no se deben utilizar smbolos.
2. La primera siempre va en maysculas, las dems en minsculas.
3. Si se utilizan dos o ms palabras, se escriben unidas, sin espacio y las iniciales con
maysculas (EstiloCamel).
4. Los nombres siempre van en singular.
5. Los nombres de atributos y mtodos, se escriben con letras minsculas.
Para poder ejemplificar un diagrama de clases, que incluye las clases y sus relaciones, se va a
ampliar un poco ms sobre las relaciones de asociacin y agregacin, que son las que se utilizan
con frecuencia:

Asociacin
Esta relacin se establece cuando dos clases tienen una dependencia de utilizacin, es decir que
una clase utiliza atributos y/o mtodos de otra clase para funcionar, ambas clases tienen la misma
jerarqua, es decir que ninguna es parte de la otra. La relacin entre clases conocida como
Asociacin, permite asociar objetos que colaboran entre s. Ejemplo:
Notar que las dos clases estn unidas por una
lnea y no por una flecha, porque: Cuando las
flechas van de izquierda a derecha y de
arriba hacia abajo, se puede omitir la
punta de la flecha.
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una Orden de Compra
slo puede tener asociado a un cliente.
Agregacin
Con este tipo de relacin se indica que un objeto forma parte de otro objeto; por ejemplo si se tiene el
objeto: computadora, esta tiene un monitor, que es otro objeto; el monitor forma parte de la
computadora; por lo tanto tienen una relacin de agregacin. Esta relacin tambin es conocida
como forma parte de

Ejemplo:

Aqu las flechas tienen punta ya que estn

inclinadas.
El rombo vacio indica una relacin de
agregacin (siendo la clase Almacen
el todo y la clase cliente representa
la parte).
El rombo relleno indica una relacin de
composicin, otro tipo de relacin.

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias, es
decir el objeto que est formado por los otros: el todo y las partes). Cuando se destruye el Objeto
Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los
objetos Cliente asociados.
Pasos para Crear el Diagrama de Clases (Sin Mtodos)
1. Listar clases candidatas
2. Representar las clases en un diagrama de clases
3. Agregar asociaciones
4. Agregar atributos necesarios
Ejemplo de Creacin de un Diagrama de Clases:
Enunciado: En un juego de dados, un jugador toma dos dados y los lanza. Luego, se suman los
valores de las caras superiores de los dados. Si el valor es 7 gana el juego, de lo contrario pierde.
1. Listar clases:
Juego de Dados, Jugador, Dado

Atributo de cada Dado: Valor de la cara

Resultado es la suma de las caras
2. Representar Clases en un Diagrama de Clases

3. Agregar asociaciones:

Jugador lanza Dados

Jugador juega Juego de Dados
Dados son parte del Juego de Dados
Jugador utiliza Dado

4. Agregar atributos:
Jugador: nombre del jugador
Dado: valor de la cara
De esta manera el Diagrama de clases, nicamente con atributos y relaciones, queda as:

Un Caso de Uso es una descripcin de los pasos o las actividades que debern realizarse para
llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso se
denominan actores.
Un Caso de Uso es una secuencia de interacciones que se desarrollarn entre un sistema y sus
actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.

Los Diagramas de Casos de Uso (DCU) sirven para especificar la comunicacin y el comportamiento
de un sistema mediante su interaccin con los usuarios y/u otros sistemas. O lo que es igual, un
diagrama que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es
una conexin entre los elementos del modelo, por ejemplo la especializacin y la generalizacin son
relaciones.
Los DCU se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona a eventos
que se producen en su mbito o en l mismo.
A continuacin se presenta la Notacin de los DCU:

En el siguiente cuadro se encuentra la Simbologa de los elementos bsicos para el diseo UML.