Unidad 4 - Modelado de Aplicaciones

INSTITUTO TECNOLGICO SUPERIOR DE LA SIERRA NORTE DE PUEBLA
Ingeniera Informtica.
Fundamentos de Programacin.
Unidad 4. Modelado de aplicaciones utilizando el enfoque orientado a

objetos.
Introduccin.
El objetivo de esta unidad es proporcionar un panorama general de UML, especficamente de
los diagramas que nos ayudarn a modelar un programa orientado a objetos, el nivel del
escrito es bsico y muestra a travs de pequeos ejemplos, los diagramas UML que nos
pueden ser de mayor utilidad.
4.1 Importancia del modelado.
Modelado.
Para producir software que cumpla su propsito hay que obtener los requisitos del sistema,
esto se consigue conociendo de una forma disciplinada a los usuarios y hacindolos participar
de manera activa para que no queden cabos sueltos. Para conseguir un software de calidad,
que sea duradero y fcil de mantener hay que idear una slida base arquitectnica que sea
flexible al cambio. Para desarrollar software rpida y eficientemente, minimizando el trabajo
de recodificacin y evitando crear miles de lneas de cdigo intil hay que disponer, adems de
la gente y las herramientas necesarias, de un enfoque apropiado.
Para conseguir, que a la hora de desarrollar software de manera industrial se obtenga un
producto de calidad, es completamente necesario seguir ciertas pautas y no abordar los
problemas de manera somera, con el fin de obtener un modelo que represente lo
suficientemente bien el problema que hemos de abordar. El modelado es la espina dorsal del
desarrollo de software de calidad. Se construyen modelos para poder comunicarnos con otros,
para explicar el comportamiento del sistema a desarrollar, para comprender, nosotros
mismos, mejor ese sistema, para controlar el riesgo y en definitiva para poder atacar
problemas que sin el modelado su resolucin seria imposible, tanto desde el punto de vista de
los desarrolladores (no se pueden cumplir los plazos estimados, no se consigue ajustar los
presupuestos, etc.) como desde el punto de vista del cliente, el cual, si finalmente se le entrega
el producto del desarrollo, se encontrar con infinidad de problemas, desde que no se
cumplen las especificaciones hasta fallos que dejan inutilizable el sistema.
Cuando nos referimos al desarrollo de software en el mbito industrial, no se pretende que la
capacidad de modelar se reduzca a empresas que disponen de gran nmero de empleados
empresas que han de abordar proyectos eminentemente grandiosos, si no que nos referimos a
la capacidad de obtener un producto comercial (sea cual sea su costo tamao) que cumpla lo
que en la industria se suele denominar como calidad total y que adems pueda reportar
beneficios a corto medio plazo, evitando, por ejemplo, implantaciones casi eternas debido a
la falta de previsin al haber abordado los problemas muy a la ligera.
Por todas estas razones es inevitable el uso de modelos. Pero, qu es un modelo? La
respuesta es bien sencilla, un modelo es una simplificacin de la realidad. El modelo nos
proporciona los planos de un sistema, desde los ms generales, que proporcionan una visin
global del sistema, hasta los ms detallados. En un modelo se han de incluir los elementos que
tengan ms relevancia y omitir los que no son interesantes para el nivel de abstraccin que se
ha elegido. A travs del modelado conseguimos cuatro objetivos:

Los modelos nos ayudan a visualizar cmo es? cmo queremos? que sea un
sistema.
Los modelos nos permiten especificar la estructura el comportamiento de un
sistema.
Los modelos nos proporcionan plantillas que nos guan en la construccin de un
sistema.
Los modelos documentan las decisiones que hemos tomado.
Calidad total: se refiere a niveles de calidad tan altos en todas las fases de la vida de un
proyecto (ya sea mecnico, industrial, civil, etc.) que no haya que estar modificando en las
fases siguientes debido a errores que se deban haber detectado previamente.
4.2 Identificar y plantear el problema.
Antes de poder iniciar con cualquier tipo de anlisis y/o modelado, es necesario realizar el
planteamiento del problema.
El planteamiento consiste en obtener la informacin necesaria para poder tener una visin
clara de la situacin y de esa forma conseguir realizar un anlisis efectivo.
Para el planteamiento del problema es necesario recopilar informacin de las siguientes 4
categoras:
1. De negocio: El tipo de informacin que se requiere aqu es toda la relacionada a como
el negocio funciona, incluyendo informacin acerca de los objetivos, productos,
servicios y definicin de los procesos crticos del negocio.
2. De aplicacin: sta informacin comprende la forma en como funciona el negocio a
travs de toda la organizacin, identificando a los tipos de usuarios, as como las
diferentes actividades que se realizan para llevar a cabo los procesos del negocio. Aqu
se identifican todas las tareas manuales y automticas, adems de las diferentes
herramientas (programas, utileras, etc.) que se usan para determinada accin.
3. De operacin: Toda la informacin referente a los datos que necesita la organizacin
para realizar sus procesos de negocio, incluyendo modelo de datos, polticas para el
manejo de datos, identificacin de los patrones de consumo de informacin.
Es importante identificar quien origina la informacin, quien es el propietario y quien
la consume, adems de la relacin que esta tiene con los procesos clave de la
organizacin.
4. De tecnologa: Aqu se definen todos los servicios tcnicos necesarios para soportar la
actividad del negocio, desde topologas de red, ambientes de desarrollo, interfaces de
programacin, seguridad, servicios de redes, servicios de base de datos, hardware,
sistemas operativos, etc.
Hay varias formas de obtener esta informacin, dentro de las ms comunes estn:
Acudir a las reas de trabajo y observar/preguntar acerca de las actividades

que se estn realizando en ese momento.
Conformacin de grupos de discusin en donde junto con los usuarios se
obtiene la informacin deseada.
2

Entrevista directa y personal con los usuarios claves para ciertos procesos.
La aplicacin de estas tcnicas para identificar la informacin que se necesita, no es

excluyente, normalmente para realizar el planteamiento del problema es necesario aplicar ms
de una a la vez.
Principios bsicos de modelado de objetos.
Existen cuatro principios bsicos, estos principios son fruto de la experiencia en todas las
ramas de la ingeniera.
a) La eleccin de qu modelos se creen influye directamente sobre cmo se acomete el
problema. Hay que seleccionar el modelo adecuado para cada momento y dependiendo de
que modelo se elija se obtendrn diferentes beneficios y diferentes costos. En la industria del
software se ha comprobado que un modelado orientado a objetos proporciona las
arquitecturas ms flexibles y re adaptables que otros por ejemplo orientados a la
funcionalidad o a los datos.
b) Todo modelo puede ser expresado a diferentes niveles de precisin. Esto es, es necesario
poder seleccionar el nivel de detalle que se desea ya que en diferentes partes de un proyecto y
en diferentes etapas se tendrn determinadas necesidades.
c) Los mejores modelos estn ligados a la realidad. Lo principal es tener modelos que nos
permitan representar la realidad lo ms claramente posible, pero no slo esto, tenemos que
saber, exactamente cuando se apartan de la realidad para no caer en la ocultacin de ningn
detalle importante.
d) Un nico modelo no es suficiente. Cualquier sistema que no sea trivial se afronta mejor
desde pequeos modelos casi independientes, que los podamos construir y estudiar
independientemente y que nos representen las partes ms diferenciadas del sistema y sus
interrelaciones.
Introduccin a un lenguaje de modelado.
Qu es UML?
El lenguaje unificado de modelacin (UML Unified Modeling Language), es un lenguaje no
propietario de tercera generacin para modelado y definicin de especificaciones.
El UML proporciona una forma sencilla, mediante diagramas e iconografas, de definir y
trasmitir ideas complejas.
Se tiene la concepcin de que el UML es un lenguaje destinado para el diseo de software,
especficamente enfocado a los arquitectos de software, lo cual es incorrecto, ya que UML
tambin puede ser utilizado para el modelado de procesos de negocios, as como estructuras
organizacionales.
El UML es manejado y controlado por un consorcio (el Object Management Group OMG), el
cual esta conformado principalmente por grandes compaas de la industria de la
computacin. A travs de este consorcio se controla la forma en como el UML evoluciona
mediante el consenso de la junta de directores, con la finalidad de crear y mantener una
especificacin nica.
3

Aplicacin.
La aplicacin de UML, como se coment anteriormente es muy extensa, ya que UML puede ser
utilizado por personas con o sin conocimientos tcnicos, para realizar modelos fsicos y
conceptuales de diversa ndole.
Diseo de software: Quizs sta es una de las reas en que el UML tiene una mayor
aceptacin, ya que a travs de l, se puede pasar de un modelo conceptual de un
software en particular, al detalle de implementacin y finalmente realizar el modelo
de despliegue fsico de una aplicacin.
Para sta tarea, el UML proporciona los siguientes tipos de diagramas:
Casos de uso.
Clases.
Secuencia.
Colaboracin.
Estado.
Actividad.
Despliegue.
Bases de datos.
Modelado de procesos de negocio: El UML permite a personas no tcnicas el modelar

como se realiza o se debe de realizar un proceso determinado de negocio,
proporcionando una forma potente y sencilla de poder comunicar las ideas a las
personas que se encargan de ejecutar dicho proceso.
Para este tipo de modelaje se utilizan los siguientes diagramas:
Casos de uso.
Secuencia.
Colaboracin.
Estado.
Actividad.
Origen.
Ya desde mediados de los 70s hasta ya muy tarde en los 80s aparecieron una serie de
lenguajes de modelado de programas orientados a objetos, ya para mediados de los 90s haba
ms de 50 lenguajes y metodologas que satisfacan caractersticas muy especificas de
modelado provocando que los usuarios tuviesen problemas para satisfacer sus necesidades
con una u otra metodologa.
En 1994 el desarrollo de UML fue iniciado por Grady Booch y Jim Rumbaugh de Rational
Software Corporation, con la unificacin de las metodologas Booch y OMT (Object Modeling
Technique), en el otoo del 95 Ivar Jacobson se uni junto con su compaa Objetory a
Rational, con la finalidad de unificar esfuerzos, integrando la metodologa OOSE (ObjectOriented Software Engineering).
En el mismo 1995 Ivar Jacobson empuj el UML al Object Management Group OMG, con la
finalidad de alcanzar un estndar con respecto a la notacin UML.
4

Para octubre de 1996 sali la especificacin 0.91 de UML, de la cual Rational obtuvo
retroalimentacin de la industria, quienes comenzaban a ver al UML como una herramienta
estratgica para sus negocios. Y es as como con la ayuda de empresas como Digital Equipment
Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle,
Rational Software, TI y Unisys; se genera la especificacin 1.0 de UML para principios de 1997,
especificacin que fue definida como: expresiva, poderosa y de aplicacin general.
Para el otoo de 1997 se libero la especificacin 1.1, la cual bsicamente incorporo mejoras
para una mayor claridad de la semntica sobre la especificacin 1.0.
Actualmente la especificacin oficial del OMG es la 1.5 liberada a principios del 2003. La
especificacin 2.0 se encuentra bajo desarrollo.
UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse
para visualizar, especificar, construir y documentar todos los artefactos que componen un
sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de
informacin hasta aplicaciones distribuidas basadas en Web, pasando por sistemas
empotrados de tiempo real. UML es solamente un lenguaje por lo que es slo una parte de un
mtodo de desarrollo de software, es independiente del proceso aunque para que sea ptimo
debe usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.
UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, adems es
un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la
representacin conceptual y fsica del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o
mediante texto obteniendo modelos explcitos que ayudan a la comunicacin durante el
desarrollo ya que al ser estndar, los modelos podrn ser interpretados por personas que no
participaron en su diseo (e incluso por herramientas) sin ninguna ambigedad. En ste
contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos.
Debido a su estandarizacin y su definicin completa no ambigua, y aunque no sea un lenguaje
de programacin, UML se puede conectar de manera directa a lenguajes de programacin
como Java, C++ Visual Basic, sta correspondencia permite lo que se denomina como
ingeniera directa (obtener el cdigo fuente partiendo de los modelos) pero adems es posible
reconstruir un modelo en UML partiendo de la implementacin, o sea, la ingeniera inversa.
Vista general de UML.
Para conocer la estructura de UML, en la Figura 4.1 vemos una vista general de todos sus
componentes, esto har que nos resulte ms fcil la comprensin de cada uno de ellos.
El lenguaje UML se compone de tres elementos bsicos, los bloques de construccin, las reglas
y algunos mecanismos comunes. Estos elementos interactan entre s para dar a UML el
carcter de completitud y no ambigedad que antes comentbamos.
Los bloques de construccin se dividen en tres partes: Elementos, que son las abstracciones
de primer nivel, Relaciones, que unen a los elementos entre s, y los Diagramas, que son
agrupaciones interesantes de elementos.
5

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:
elementos estructurales, elementos de comportamiento, elementos de agrupacin y elementos
de anotacin.
Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que
se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de
dependencia, relaciones de asociacin, relaciones de generalizacin y relaciones de realizacin.
Se utilizan diferentes diagramas dependiendo de qu, nos interese representar en cada
momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de
detalle, etc., por sta razn UML soporta un gran nmero de diagramas diferentes aunque, en
la prctica, slo se utilicen un pequeo nmero de combinaciones.
Vista general de UML
Bloques de Construccin
Reglas
Elementos
Diagramas
Afectan
Estructurales
Clases
Comportamiento
Objetos
* Agrupacin
Casos de Uso
* Anotacin
Secuencia
Nombres
Alcance
* Visibilidad
* Integridad
Afectan
Diagramas
* Colaboracin
* Estados
Relaciones
Mecanismos
* Componentes
Actan
Dependencia
* Despliegue
Especificaciones
Adornos
Asociacin
* Divisiones Comunes
* Generalizacin
* Extensibilidad
* Realizacin
Figura 4.1 Vista general de los elementos de UML.
UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones
entre objetos para poder obtener modelos bien formados, estas son reglas semnticas que
afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por
otros, a la integridad de unos elementos con otros y a la ejecucin, o sea la vista dinmica del
sistema.
UML proporciona una serie de mecanismos comunes que sirven para que cada persona o
entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo
unas ciertas reglas para que en el trasfondo de la adaptacin no se pierda la semntica propia
de UML. Dentro de estos mecanismos estn las especificaciones, que proporcionan la
explicacin textual de la sintaxis y semntica de los bloques de construccin. Otro mecanismo
es el de los adornos que sirven para conferir a los modelos de ms semntica, los adornos son
elementos secundarios ya que proporcionan ms nivel de detalle, que quiz en un primer
6

momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos se
dividan al menos en un par de formas diferentes para facilitar la comprensin desde distintos
puntos de vista, en primer lugar tenemos la divisin entre clase y objeto (clase es una
abstraccin y objeto es una manifestacin de esa abstraccin), en segundo lugar tenemos la
divisin interfaz / implementacin donde la interfaz presenta un contrato (algo que se va a
cumplir de una determinada manera) mientras que la implementacin es la manera en que se
cumple dicho contrato. Por ltimo, los mecanismos de extensibilidad que UML proporciona
sirven para evitar posibles problemas que puedan surgir debido a la necesidad de poder
representar ciertos matices, por sta razn UML incluye los estereotipos, para poder extender
el vocabulario con nuevos bloques de construccin, los valores etiquetados, para extender las
propiedades de un bloque, y las restricciones, para extender la semntica.
De sta manera UML es un lenguaje estndar abierto cerrado siendo posible extender el
lenguaje de manera controlada.
Bloques de construccin de UML.
A continuacin se van a describir todos los elementos que componen los bloques estructurales
de UML, as como su notacin, para que nos sirva de introduccin y se vaya generando un
esquema conceptual sobre UML.
Elementos Estructurales.
Los elementos estructurales en UML, en su mayora, son las partes estticas del modelo y
representan cosas que son conceptuales materiales.
Clases.
Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica. Una clase implementa una ms interfaces.
Grficamente se representa como un rectngulo que incluye su nombre, sus atributos y sus
operaciones (Figura 4.2).
Ventana
-origen
-tamao
+abrir()
+cerrar()
+mover()
+dibujar()
Figura 4.2 Clases.
Interfaz.
Una interfaz es una coleccin de operaciones que especifican un servicio de una determinada
clase o componente. Una interfaz describe el comportamiento visible externamente de ese
elemento, puede mostrar el comportamiento completo o slo una parte del mismo. Una
interfaz describe un conjunto de especificaciones de operaciones (o sea su firma) pero nunca
7

su implementacin. Se representa con un crculo, como podemos ver en la Figura 4.3, y rara
vez se encuentra aislada sino que ms bien conectada a la clase o componente que realiza.
IOrtografia
Figura 4.3 Interfaz.
Colaboracin.
Define una interaccin y es una sociedad de roles y otros elementos que colaboran para
proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de
sus elementos. Las colaboraciones tienen una dimensin tanto estructural como de
comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las
colaboraciones representan la implementacin de patrones que forman un sistema. Se
representa mediante una elipse con borde discontinuo, como en la Figura 4.4.
Cadena de
responsabilidad
Figura 4.4 Colaboracin.
Casos de Uso.
Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta y que
produce un determinado resultado que es de inters para un actor particular. Un caso de uso
se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es
realizado por una colaboracin. Se representa como en la Figura 4.5, una elipse con borde
continuo.
Realizar Pedido
Figura 4.5 Casos de Uso.
Clase Activa.
Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por lo tanto pueden
dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que sus
objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Se
representa igual que una clase (Figura 4.2), pero con lneas ms gruesas (Figura 4.6).

Gestor de Eventos
suspender()
vaciarCola()
Figura 4.6 Clases Activas.
Componentes.
Un componente es una parte fsica y reemplazable de un sistema que conforma un conjunto
de interfaces y proporciona la implementacin de dicho conjunto. Un componente representa
tpicamente el empaquetamiento fsico de diferentes elementos lgicos, como clases,
interfaces y colaboraciones.
orderForm.java
Figura 4.7 Componentes.
Nodos.
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso
computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de
capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.
Servidor
Figura 4.8 Nodos.
Estos siete elementos vistos son los elementos estructurales bsicos que se pueden incluir en
un modelo UML. Existen variaciones sobre estos elementos bsicos, tales como actores,
seales, utilidades (tipos de clases), procesos e hilos (tipos de clases activas) y aplicaciones,
documentos, archivos, bibliotecas, pginas y tablas (tipos de componentes).
Relaciones.
Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia,
asociacin, generalizacin y realizacin, estas se describen a continuacin:
9

Dependencia.
Es una relacin semntica entre dos elementos en la cual un cambio a un elemento (el
elemento independiente) puede afectar a la semntica del otro elemento (elemento
dependiente). Se representa como una lnea discontinua (Figura 4.9), posiblemente dirigida, y
a veces incluye una etiqueta.
Figura 4.9 Dependencias.
Asociacin.
Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones
entre objetos. La agregacin es un tipo especial de asociacin y representa una relacin
estructural entre un todo y sus partes. La asociacin se representa con una lnea continua,
posiblemente dirigida, que a veces tiene una etiqueta. A menudo se incluyen otros adornos
para indicar la multiplicidad y roles de los objetos involucrados, como podemos ver en la
Figura 4.10.
0..1
patrn
*
empleado
Figura 4.10 Asociaciones.
Generalizacin.
Es una relacin de especializacin/generalizacin en la cual los objetos del elemento
especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De sta
forma, el hijo comparte la estructura y el comportamiento del padre. Grficamente, la
generalizacin se representa con una lnea con punta de flecha vaca (Figura 4.11).
Figura 4.11 Generalizacin.
Realizacin.
Es una relacin semntica entre clasificadores, donde un clasificador especifica un contrato
que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en
dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso
y las colaboraciones que los realizan. La realizacin se representa como una mezcla entre la
generalizacin (Figura 4.11) y la dependencia (Figura 4.9), esto es, una lnea discontinua con
una punta de flecha vaca (Figura 4.12).
Figura 4.12 Realizacin.
10

Diagramas.
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que
un diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas
que normalmente se usan en pequeos subconjuntos para poder representar las cinco vistas
principales de la arquitectura de un sistema.
4.3 Identificacin y especificacin de clases.

A la hora de modelar un sistema es necesario identificar las cosas ms importantes eligiendo
un nivel de abstraccin capaz de identificar todas las partes relevantes del sistema y sus
interacciones. En ste primer acercamiento no debemos contar con los detalles particulares de
las cosas que hemos identificado como importantes, estos detalles se atacarn posteriormente
en cada una de las partes elegidas.
Por ejemplo, si estuvisemos trabajando en una tienda que vende computadoras como
proveedor final y nuestro jefe nos pidiera que montramos una computadora, directamente la
divisin que tendramos es la siguiente: necesitamos un monitor, un teclado, un ratn y un
CPU, sin importarnos (inicialmente, claro) que el CPU est compuesto por varios elementos
ms. Una vez que tenemos claro que partes forman una computadora nos daramos cuenta
que tanto el teclado, como el ratn y el monitor son partes ms o menos atmicas ya que,
aunque estos tres objetos estn compuestos por un montn de componentes electrnicos, la
composicin de estos no nos interesa para el nivel de abstraccin que estamos trabajando (el
de proveedor final). Al darnos cuenta de esto prepararamos el monitor, el teclado y el ratn,
pero en nuestro almacn tenemos monitores de 15 y 17 pulgadas, teclados ergonmicos y
estndares y ratones de diferentes tamaos, colores, etc. Una vez que hemos determinado las
propiedades de cada uno de ellos pasaramos a preocuparnos por el CPU, ahora es cuando
veramos que para montar el CPU nos hacen falta una placa base, un microprocesador, una
disquetera, un disco duro y un CD-ROM, cada uno de estos elementos con sus propiedades,
disquetera de 1,44 Mb, disco duro de 4 Gb, microprocesador a 500 MHz y un CD-ROM 32x.
Una vez que tenemos todo el material en el banco de trabajo tendramos que montar la
computadora sabiendo que cada una de las partes interacta con el resto de alguna manera,
en el CPU la disquetera, el CD-ROM y el disco duro van conectados al bus de datos, ste
adems est conectado a la placa base y el micro tiene un lugar bien definido tambin en la
placa base, despus conectaramos el teclado, el monitor y el ratn al CPU y ya esta!, nuestra
computadora est montada.
El modelado estructural es la parte de UML que se ocupa de identificar todas las partes
importantes de un sistema as como sus interacciones. Para modelar las partes importantes del
vocabulario del sistema se utilizan las clases, que nos permiten: identificacin y representacin
de sus propiedades y sus operaciones mediante el mecanismo de abstraccin. Las relaciones se
utilizan para poder modelar las interacciones entre las clases.
Representacin de las Clases en UML.

Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica. Hay que hacer una especial diferenciacin para no
confundir el concepto de clase con el de objeto. Un objeto es una instancia individual de una
11

clase, as podramos tener una clase que fueran los monitores y un objeto de la clase
monitores que fuera un monitor marca A de 17 pulgadas, con la pantalla plana. En UML se
usan un rectngulo para representar las clases, con distintos compartimentos para indicar sus
atributos y sus operaciones.
Una clase se identifica por un nombre que la distingue del resto, el nombre es una cadena de
texto. Ese nombre slo se denomina nombre simple; un nombre de camino consta del nombre
de la clase precedido del nombre del paquete en el que se encuentra incluida. En las figuras
4.13 y 4.14 podemos ver la estructura de una clase y distintos nombres de camino y nombres
simples.
Monitor
-marca
-modelo
Nombre
Atributos
+encender()
Operaciones
Figura 4.13 Representacin de Clases.
Cliente
Figura
Nombres simples
Computadoras::Monitor
java::awt::Rectangle
Nombres de camino
Figura 4.14 Tipos de nombres.
Un atributo es una propiedad de una clase identificada con un nombre. Describe un rango de
valores que pueden tomar las instancias de la propiedad. Los atributos representan
propiedades comunes a todos los objetos de una determinada clase, por ejemplo todos los
monitores tienen la propiedad dimensin, que se suele medir en pulgadas. Un cliente tiene las
propiedades nombre, apellidos, direccin, telfono, etc. Los atributos son propiedades
interesantes de las clases. Una instancia de una determinada clase tendr valores concretos
para sus atributos, mientras que las clases tienen rangos de valores que pueden admitir sus
atributos.
El nombre de los atributos es un texto que normalmente se escribe en minsculas si slo es
una palabra o la primera palabra del nombre del atributo en minsculas y el resto de las
palabras con la primera letra en maysculas, por ejemplo, nombrePropietario.
Una operacin es una implementacin de un servicio que puede ser requerido a cualquier
objeto de la clase para que muestre su comportamiento. Una operacin representa algo que el
objeto puede hacer. Por ejemplo, un comportamiento esperado por cualquier usuario de un
12

monitor es que ste se pueda encender y apagar. El nombre de las operaciones sigue las
mismas reglas de notacin que los atributos pero suelen ser verbos cortos que indican una
accin o comportamiento de la clase.
Como norma general, cuando se dibuja una clase no hay que mostrar todos sus atributos ni
todas sus operaciones, slo se deben mostrar los subconjuntos ms relevantes y una buena
prctica es utilizar estereotipos para organizar los atributos y las operaciones.
AgenteFraudes
<<constructor>>
nuevo()
nuevo(p: Poltica)
Estereotipos
<<process>>
procesar(o: Pedido)
...
Figura 4.15 Estereotipos para caractersticas de las clases.
Para modelar el vocabulario del sistema hay que identificar aquellas cosas que utilizan los
usuarios o programadores para describir el problema, para conseguir esto se sugiere un
anlisis basado en casos de uso. Para cada clase hay que determinar un conjunto de
responsabilidades y posteriormente determinar los atributos y las operaciones necesarias para
llevar a cabo las responsabilidades de la clase.
A veces, las cosas que tenemos que modelar no tienen equivalente en software, como por
ejemplo, gente que emite facturas o robots que empaquetan automticamente los pedidos,
pueden formar parte del flujo de trabajo que se intenta modelar. Para modelar cosas que no
son software hay que obtener abstracciones para poder representar esas cosas como clases y,
si lo que se est modelando es algn tipo de hardware que contiene software se tiene que
considerar modelarlo como un tipo de Nodo, de manera que ms tarde se pueda completar su
estructura.
En ocasiones puede resultar necesario especificar ms aun sobre las caractersticas de las
operaciones o atributos como por ejemplo, tipos de datos que utilizan, visibilidad,
caractersticas concretas del lenguaje que utilizan, excepciones que puede producir, etc. UML
proporciona una notacin concreta para estas caractersticas avanzadas pero no se tratarn en
este escrito ya que estn fuera de los objetivos de esta introduccin al modelado orientado a
objetos con UML.
Responsabilidades.
Una responsabilidad es un contrato u obligacin de una clase, es decir, el fin para el que es
creada.
13

Cuando creamos una clase se est expresando que todos los objetos de la clase tienen el
mismo tipo de estado y el mismo tipo de comportamiento. Los atributos y las operaciones son
caractersticas de la clase que le permiten llevar a cabo sus responsabilidades. Al iniciar el
modelado de clases es una buena prctica iniciar especificando las responsabilidades de cada
clase. Una clase puede tener cualquier nmero de responsabilidades pero en la prctica el
nmero se reduce a una o a unas pocas.
Cuando se van refinando los modelos las responsabilidades se van convirtiendo en atributos y
operaciones, se puede decir que las responsabilidades de una clase estn en un nivel ms alto
de abstraccin que los atributos y las operaciones. Para representar responsabilidades se
utiliza un cuarto compartimiento en el bloque de construccin de la clase, en el cual se
especifican mediante frases cortas de texto libre las responsabilidades que ha de cumplir la
clase.
Monitor
Responsabilidades
-- Visualizar caracteres e
Figura 4.16 Responsabilidades.
A la hora de determinar las responsabilidades, y su distribucin, que tiene que cumplir un

sistema en su conjunto, hemos de identificar un grupo de clases que colaboren entre s para
llevar a cabo algn tipo de comportamiento. Hay que determinar un conjunto de
responsabilidades para cada una de esas clases teniendo cuidado de no dar demasiadas
responsabilidades a una sola clase ni obtener clases con muy pocas responsabilidades. De sta
manera, clases con muchas responsabilidades se dividen en varias abstracciones menores y las
clases con responsabilidades triviales se introducen en otras mayores.
4.4 Relaciones entre clases.
Relaciones.
Como ya hemos comentado, las relaciones son la manera de representar las interacciones
entre las clases. Siguiendo con el ejemplo del montaje de la computadora, cada pieza
interacta con otra de una determinada manera y aunque por si solas no tienen sentido, todas
juntas forman una computadora, esto es lo que se denomina una relacin de asociacin, pero
adems hay unas que no pueden funcionar si no estn conectadas a otras como por ejemplo
un teclado, el cual, sin estar conectado a el CPU es totalmente intil, adems si el CPU
cambiase su conector de teclado, ste ya no se podra conectar, a no ser que cambiase el
tambin, esto se puede representar mediante una relacin de dependencia. Es ms, tenemos
una disquetera de 1,44 Mb, un disco duro, un CD-ROM.
Para referirnos a todos estos tipos de discos podramos generalizar diciendo que tenemos una
serie de discos con ciertas propiedades comunes, como pueden ser la capacidad, la tasa de
transferencia en lectura y escritura, etc., esto es lo que se denomina una relacin de
generalizacin. La construccin de relaciones no difiere mucho de la distribucin de
14

responsabilidades entre las clases. Si se modela en exceso se obtendrn diagramas con un alto
nivel de dificultad para poder leerlos debido principalmente al lo que se forma con las
relaciones, por el contrario, si se modela insuficientemente se obtendrn diagramas carentes
de semntica.
Para poder representar con UML cmo se conectan las cosas entre s, ya sea lgica
fsicamente, utilizamos las relaciones. Existen tres tipos de relaciones muy importantes:
dependencias, generalizaciones y asociaciones. Una relacin se define como una conexin
entre elementos. A continuacin describiremos los tres tipos ms importantes de relaciones:
Relacin de Dependencia.
Es una relacin de uso entre dos elementos de manera que un cambio en la especificacin del
elemento independiente puede afectar al otro elemento implicado en la relacin.
Determinamos el elemento dependiente como aquel que necesita del otro elemento
implicado en la relacin (el independiente) para poder cumplir sus responsabilidades. Por
ejemplo, supongamos que tenemos una clase que representa un aparato reproductor de
Vdeo, con sus funciones y sus propiedades. Bien, para utilizar el mtodo grabar() de la clase
video, dependemos directamente de la clase Canal ya que grabaremos un canal u otro
dependiendo de cual tenga seleccionado el aparato de vdeo. A su vez la clase Televisin
tambin depende de la clase Canal para poder visualizar un determinado canal.
Video
-cabezales
-tipoReproduccin
+poner()
+pasar()
+rebobinar()
+parar()
+grabar(c: Canal)
Television
Canal
-frecuencia
+buscar()
+fijar()
-pulgadas
-numCanales
+encender()
+apagar()
+cambiar(c: Canal)
Figura 4.17 Ejemplo de dependencias.
En la Figura 4.17 podemos observar un ejemplo de relacin de dependencia. Si en algn

momento la clase Canal cambiar (se modificar o aadiera nueva funcionalidad) las clases
Video y Televisin (que dependen de ella) podran verse afectadas por el cambio y dejar de
funcionar. Como podemos observar en sta figura tanto al mtodo grabar() de la clase video,
como al mtodo cambiar() de la clase Televisin se le ha aadido ms semntica
representando el parmetro c de tipo Canal. ste es un mecanismo comn en UML de diseo
avanzado de clases. Cuando queremos aportar ms informacin sobre una clase y sus mtodos
existe una nomenclatura bien definida para determinar ms los atributos y mtodos de la clase
indicando si son ocultos o pblicos, sus tipos de datos, parmetros que utilizan y los tipos que
retornan.
Normalmente, mediante una dependencia simple sin adornos suele bastar para representar la
mayora de las relaciones de uso que nos aparecen, sin embargo, existen casos avanzados en
los que es conveniente dotar al diagrama de ms semntica, para estos casos UML
proporciona estereotipos concretos.
15

Relacin de Asociacin.
Una asociacin es una relacin estructural que especifica que los objetos de un elemento
estn conectados con los objetos de otro. Dada una asociacin entre dos clases, se puede
navegar desde un objeto de una de ellas hasta uno de los objetos de la otra, y viceversa. Es
posible que la asociacin se d de manera recursiva en un objeto, esto significa que dado un
objeto de la clase se puede conectar con otros objetos de la misma clase. Tambin es posible,
aunque menos frecuente, que se conecten ms de dos clases, stas se suelen llamar
asociaciones n arias. Las relaciones de asociaciones se utilizan cuando se quieren representar
relaciones estructurales.
A parte de la forma bsica de representar las asociaciones, mediante una lnea continua entre
las clases involucradas en la relacin, existen cuatro adornos que se aplican a las asociaciones
para facilitar su comprensin:
Nombre: Se utiliza para describir la naturaleza de la relacin. Para que no exista
ambigedad en su significado se le puede dar una direccin al nombre por medio de
una flecha que apunte en la direccin que se pretende que el nombre sea ledo.
Rol: Cuando una clase participa en una asociacin sta tiene un rol especfico que
juega en dicha asociacin. El rol es la cara que dicha clase presenta a la clase que se
encuentra en el otro extremo. Las clases pueden jugar el mismo diferentes roles en
otras asociaciones.
Multiplicidad: En muchas situaciones del modelado es conveniente sealar cuantos
objetos se pueden conectar a travs de una instancia de la asociacin. ste cuantos
se denomina multiplicidad del rol en la asociacin y se expresa como un rango de
valores o un valor explicito. Cuando se indica multiplicidad en un extremo de una
asociacin se est indicando que, para cada objeto de la clase en el extremo opuesto
debe haber tantos objetos en ese extremo. Se puede indicar una multiplicidad de
exactamente uno (1), cero uno (0..1), muchos (0..*), uno o ms (1..*) e incluso un
nmero exacto (por ejemplo, 5).
Agregacin: Una asociacin normal entre dos clases representa una relacin
estructural entre iguales, es decir, ambas clases estn conceptualmente al mismo
nivel. A veces interesa representar relaciones del tipo todo/parte, en las cuales una
cosa representa la cosa grande (el todo) que consta de elementos ms pequeos (las
partes). ste tipo de relacin se denomina de agregacin la cual representa una
relacin del tipo tiene un.
Una agregacin es slo un tipo especial de asociacin, sta se especifica aadiendo
simplemente un rombo vaco en la parte del todo.
Composicin.
Composicin: Es una variacin de la agregacin simple que aade una semntica
importante. La composicin es una forma de agregacin, con una fuerte relacin de
pertenencia y vidas coincidentes de la parte del todo. Las partes con una multiplicidad
no fijada pueden crearse despus de la parte que representa el todo (la parte
compuesta), una vez creadas pertenecen a ella de manera que viven y mueren con
ella. Las partes pueden ser eliminadas antes que el todo sea destruido, pero una vez
16

que ste se elimine todas sus partes sern destruidas. El todo, adems, se ha de
encargar de toda la gestin de sus partes, creacin, mantenimiento, disposicin.
En la Figura 4.20 vemos una relacin de composicin donde un marco pertenece a una
ventana, pero ese marco no es compartido por ninguna otra ventana, esto contrasta
con la agregacin simple en la que una parte puede ser compartida por varios objetos
agregados. Por ejemplo una pared puede estar compartida por varias habitaciones.
Figura 4.18 Ejemplo de asociacin y sus partes.
Figura 4.19 Ejemplo de agregacin.
Figura 4.20 Ejemplo de composicin.
Relacin de Generalizacin.
Es una relacin entre un elemento general (llamado superclase o padre) y un caso ms
especfico de ese elemento (llamado subclase o hijo). La generalizacin a veces es llamada
relacin es un tipo de, es decir, un elemento (por ejemplo, una clase Rectngulo) es
un tipo de un elemento ms general (por ejemplo, la clase figura). La generalizacin implica
que los objetos hijo se pueden utilizar en cualquier lugar donde aparece el padre, pero no a la
inversa. La clase hijo siempre hereda todos los atributos y mtodos de sus clases padre y a
menudo (no siempre) el hijo extiende los atributos y operaciones del padre. Una operacin de
un hijo puede tener la misma firma que en el padre pero la operacin puede ser redefinida por
el hijo; esto es lo que se conoce como polimorfismo.
La generalizacin se representa mediante una flecha dirigida con la punta hueca. Una clase
puede tener ninguno, uno o varios padres. Una clase sin padres y uno o ms hijos se denomina
clase raz o clase base. Una clase sin hijos se denomina clase hoja. Una clase con un nico
padre se dice que utiliza herencia simple y una clase con varios padres se dice que utiliza
herencia mltiple. UML utiliza las relaciones de generalizacin para el modelado de clases e
17

interfaces, pero tambin se utilizan para establecer generalizaciones entre otros elementos
como por ejemplo los paquetes.
Figura
-origen
+mover()
+cambiarTamao()
+dibujar()
Rectangulo
-esquina: Punto
Circulo
-Radio: Float
Poligono
+puntos: Lista
+dibujar()
Cuadrado
Figura 4.21 Ejemplo de generalizacin.
Mediante las relaciones de generalizacin podemos ver que un Cuadrado es un tipo de

Rectngulo que a su vez es un tipo de figura. Con esta relacin podemos representar la
herencia, de ste modo, la clase cuadrado, simplemente por herencia sabemos que tiene dos
atributos, esquina (heredado de su padre Rectngulo) y origen (heredado del padre de
Rectngulo, la clase figura, que se puede decir que es su abuelo). Lo mismo ocurre con las
operaciones, la clase Cuadrado dispone de las operaciones mover(), cambiarTamao() y
dibujar(), heredadas todas desde figura.
Normalmente la herencia simple es suficiente para modelar los problemas a los que nos
enfrentamos pero en ciertas ocasiones conviene modelar mediante herencia mltiple aunque
vistos en sta situacin se ha de ser extremadamente cuidadoso en no realizar herencia
mltiple desde padres que solapen su estructura o comportamiento. La herencia mltiple se
representa en UML simplemente haciendo llegar flechas (iguales que las de la generalizacin)
de un determinado hijo a todos los padres de los que hereda.
En el siguiente ejemplo podemos observar como se puede usar la herencia mltiple para
representar especializaciones cuyos padres son inherentemente disjuntos pero existen hijos
con propiedades de ambos.
En el caso de los Vehculos, estos se pueden dividir dependiendo de por donde circulen, as
tendremos Vehculos areos, terrestres y acuticos. Esta divisin parece que nos cubre
completamente todas las necesidades, y as es. Dentro de los vehculos terrestres tendremos
especializaciones como coches, motos, bicicletas, etc. Dentro de los acuticos tendremos, por
ejemplo, barcos, submarinos, etc. Dentro de los areos tendremos por ejemplo, aviones,
globos, zeppelines, etc. En ste momento tenemos una clasificacin bastante clara de los
18

vehculos, pero que ocurre con los vehculos que pueden circular tanto por tierra como por
agua, es decir, vehculos anfibios, como por ejemplo un tanque de combate preparado para tal
efecto, en ste caso podemos pensar en utilizar un mecanismo de herencia mltiple para
representar que dicho tanque rene capacidades, atributos y operaciones tanto de vehculo
terrestre como acutico.
Vehculo
VehculoTerrestre
Coche
Moto
VehculoAcutico
VehculoAnfibio
Barco
Submarino
VehculoAreo
Avin
Globo
Tanque
Figura 4.22 Ejemplo de herencia mltiple.
4.5 Diseo de mtodos.

En la vida cotidiana:
Mtodo: procedimiento para la accin prctica y terica del hombre que se orienta a asimilar
un objeto. En la produccin se trata del procedimiento que se utiliza para elaborar las cosas,
para cultivar las plantas o criar animales, etc. En la ciencia el modo de alcanzar nuevos
resultados en el pensamiento. Slo aquel mtodo que se base en el conocimiento acerca de un
objeto y de sus leyes puede proporcionar resultados tiles en la teora y en la prctica. De ah
que la premisa del mtodo sea una teora cientfica.
La necesidad del mtodo reside en remitir, a travs de ciertas reglas, todo conocimiento a la
certeza. El mtodo no es sino un camino seguro para llegar a la verdad y evitar el error.
En la programacin:
Un mtodo es un conjunto de instrucciones a las que se les da un determinado nombre de tal
manera que sea posible ejecutarlas en cualquier momento sin tenerlas que rescribir sino
usando slo su nombre. A estas instrucciones se les denomina cuerpo del mtodo, y a su
ejecucin a travs de su nombre se le denomina llamada al mtodo.
La ejecucin de las instrucciones de un mtodo puede producir como resultado un objeto de
cualquier tipo. A ste objeto se le llama valor de retorno del mtodo y es completamente
opcional, pudindose escribir mtodos que no devuelvan ninguno.
19

La ejecucin de las instrucciones de un mtodo puede depender del valor de unas variables
especiales denominadas parmetros del mtodo, de manera que en funcin del valor que se
d a estas variables en cada llamada la ejecucin del mtodo se pueda realizar de una u otra
forma y podr producir uno u otro valor de retorno.
Al conjunto formado por el nombre de un mtodo y el nmero y tipo de sus parmetros se le
conoce como firma del mtodo. La firma de un mtodo es lo que verdaderamente lo
identifica, de modo que es posible definir en un mismo tipo varios mtodos con idntico
nombre, siempre y cuando, tengan distintos parmetros. Cuando esto ocurre se dice que el
mtodo que tiene ese nombre est sobrecargado.
4.6 Comunicacin entre objetos.
Mensaje.
Un nico objeto por s slo no es demasiado til. En general, un objeto es un componente ms
de un programa o una aplicacin que contiene otros muchos objetos. Con sta interaccin los
programadores consiguen una funcionalidad de mayor orden y pueden modelar
comportamientos mucho ms complejos.
Por ejemplo, una Ambulancia estacionada no es ms que una chapa por s sola, es incapaz de
desarrollar ninguna actividad. Es til cuando otro objeto (conductor, por ejemplo) la conduce.
Los objetos de un programa interactan y se comunican entre ellos por medio de mensajes.
Cuando un objeto A quiere que otro objeto B ejecute una de sus funciones miembro (mtodos
de B), el objeto A manda un mensaje al objeto B.
A veces el objeto que recibe el mensaje necesita ms informacin, si le decimos que queremos
subir la velocidad, deberamos adems, decirle la velocidad exacta, por ejemplo. sta
informacin se pasa junto con el mensaje en forma de parmetro.
Partes del mensaje si quisiramos por ejemplo decirle a la Ambulancia que suba la velocidad en
10 km/h:
1. El objeto al cual se manda el mensaje (Ambulancia).
2. El mtodo o funcin miembro que debe ejecutar (subirVelocidad()).
3. Los parmetros que necesita ese mtodo (10).
stas tres partes del mensaje (objeto destinatario, mtodo y parmetros) son suficiente
informacin para que el objeto que recibe el mensaje ejecute el mtodo o la funcin miembro
solicitada.
Los mensajes proporcionan dos ventajas importantes:
El comportamiento de un objeto est completamente determinado (a excepcin del

acceso directo a variables miembro pblicas) por sus mtodos, as que los mensajes
representan todas las posibles interacciones que pueden realizarse entre objetos.
20

Los objetos no necesitan formar parte del mismo proceso, ni siquiera residir en una
misma computadora para mandarse mensajes entre ellos (y de sta forma
interactuar).
En resumen:
Los mensajes (en la POO) son la comunicacin entre los objetos, sin estos, los objetos tendran
que actuar solos, por tanto, no podramos hacer productivo el uso de la programacin
orientada a objetos.
4.7 Diseo de la clase de prueba.
Prueba unitaria.
En programacin, una prueba unitaria es una forma de probar el correcto funcionamiento de
un mdulo de cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione
correctamente por separado. Luego, con las Pruebas de Integracin, se podr asegurar el
correcto funcionamiento del sistema o subsistema en cuestin.
La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo, de
forma que cada caso sea independiente del resto.
Caractersticas.
Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:
Automatizable: No debera requerirse una intervencin manual. Esto es

especialmente til para integracin continua.
Completas: Deben cubrir la mayor cantidad de cdigo.
Repetibles o Reutilizables: No se deben crear pruebas que slo puedan ser ejecutadas
una sola vez. Tambin es til para integracin continua.
Independientes: La ejecucin de una prueba no debe afectar a la ejecucin de otra.
Profesionales: Las pruebas deben ser consideradas igual que el cdigo, con la misma
profesionalidad, documentacin, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos
o de lo contrario las pruebas pierden parte de su funcin.
Ventajas.
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes
individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo debe
satisfacer. Estas pruebas aisladas proporcionan cinco ventajas bsicas:
1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el
cdigo para mejorar su estructura (lo que se ha dado en llamar refactorizacin),
puesto que permiten hacer pruebas sobre los cambios y as asegurarse de que los
nuevos cambios no han introducido errores.
21

2. Simplifican la integracin: Puesto que permiten llegar a la fase de integracin con un

grado alto de seguridad de que el cdigo est funcionando correctamente. De sta
manera se facilitan las pruebas de integracin.
3. Documentan el cdigo: Las propias pruebas son documentacin del cdigo puesto que
ah se puede ver cmo utilizarlo.
4. Separacin de la interfaz y la implementacin: Dado que la nica interaccin entre los
casos de prueba y las unidades bajo prueba son las interfaces de estas ltimas, se
puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock
(mock object) para simular el comportamiento de objetos complejos.
5. Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos
pruebas unitarias que pueden desenmascararlos.
Limitaciones.
Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores del
cdigo. Por definicin, slo prueban las unidades por s solas. Por lo tanto, no descubrirn
errores de integracin, problemas de rendimiento y otros problemas que afectan a todo el
sistema en su conjunto. Adems, puede no ser trivial anticipar todos los casos especiales de
entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas
unitarias slo son efectivas si se usan en conjunto con otras pruebas de software.
Referencias:
Alarcn Ral, Diseo Orientado a Objetos con UML. Madrid Espaa 2000, Grupo EIDOS. (pags.
27 34 y 45 49).
Wikipedia, Mtodo (Informtica), Wikipedia.org, 12 de Noviembre de 2010, [en lnea]:
http://es.wikipedia.org/wiki/M%C3%A9todo_(inform%C3%A1tica),
Consultado:
15
de
Noviembre de 2010.
Ballester Joan, Mensaje. Blog personal. 24 de Octubre 2008, [en lnea]:
http://www.joanballestermoragues.com/programacion-desarrollo/programacion-orientada-aobjetos-mensaje.html, Consultado: 16 de Noviembre de 2010.
Wikipedia, Prueba unitaria. Wikipedia.org, 25 de Octubre de 2010, [en lnea]:
http://es.wikipedia.org/wiki/Prueba_unitaria, Consultado: 16 de Noviembre de 2010.
22

Unidad 4 - Modelado de Aplicaciones

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unidad 4 - Modelado de Aplicaciones

Uploaded by

Copyright:

Available Formats

INSTITUTO TECNOLGICO SUPERIOR DE LA SIERRA NORTE DE PUEBLA