Mdulo 1

Modelos y Proceso
de desarrollo de
Software.

1.1- Modelos,
conceptos.
Qu es un modelo y por qu
modelamos?
Los proyectos de software que fracasan lo hacen por circunstancias
propias, pero todos los proyectos con xito se parecen en muchos
aspectos. Entre todos los aspectos que hacen que un proyecto tenga xito
uno en comn es el uso del modelado.
El modelado es una tcnica de Ingeniera probada y bien aceptada. Se
construyen modelos arquitectnicos de casas y edificios para ayudar a sus
usuarios a visualizar el producto final antes que el mismo est construido.
Incluso podemos elaborar modelos matemticos para analizar los efectos
de vientos o terremotos sobre los edificios.
Un modelo es una simplificacin de la realidad. Un modelo proporciona los
planos de un sistema. Pueden ser planos generales, que ofrecen una visin
global del sistema en consideracin, as como planos detallados. Un buen
modelo incluye, para un nivel de abstraccin dado, los elementos que
tienen gran influencia y omite aquellos menores que no son relevantes.
Todo sistema puede ser caracterizado desde diferentes perspectivas,
utilizando diferentes modelos. Un modelo puede ser estructural resaltando
la organizacin del sistema o puede ser de comportamiento, destacando su
dinmica.
Se construyen modelos para comprender mejor el sistema que estamos
desarrollando. A travs del modelado se persiguen los siguientes objetivos:

Los modelos ayudan a visualizar cmo es, o queremos que sea un

sistema.

Los modelos permiten especificar

comportamiento de un sistema.

Los modelos proporcionan plantillas que sirven de gua en la

construccin de un programa.

la

estructura

el

Los modelos documentan las decisiones que se han adoptado.

Construimos modelos de sistemas complejos porque es difcil comprender

el sistema en su totalidad. El ser humano tiene una capacidad limitada para
comprender y abordar la complejidad, por ello a travs del modelado
podemos reducir el problema que se est estudiando y enfocarnos en un
aspecto a la vez.
En general, an en el proyecto ms simple, los desarrolladores siempre
realizan alguna actividad de modelado como un bosquejo en hoja de papel
o en algn software graficador. Sin embargo, estos modelos informales no
proporcionan frecuentemente un lenguaje comn que pueda compartirse
entre todos los desarrolladores y no siempre queda debidamente
documentado.
As como existe un lenguaje comn para realizar planos en la industria de la
construccin, en la Ingeniera Civil, Elctrica, entre otros, tambin es
beneficioso para una empresa de software que todos sus desarrolladores
utilicen un lenguaje comn para el modelado del software.

Principios bsicos de modelado

Como se plantea en el libro El lenguaje Unificado de Modelado, la
experiencia en el uso del modelado sugiere los siguientes cuatro principios
bsicos (Booch G., Rumbaugh J. y Jacobson I., 1999, pgs. 7,8):

La eleccin de los modelos a crear tiene mucha influencia sobre

cmo se aborda el problema y cmo de da forma a la solucin.

Esto quiere decir que hay que elegir bien los modelos. Los modelos
adecuados pueden arrojar mucha luz sobre los problemas de desarrollo
ms complicados, brindando una comprensin que no podramos obtener
de otra manera. Ahora bien, si se incurre en la utilizacin de modelos
errneos o inadecuados, stos desorientarn haciendo que uno se centre
en cuestiones irrelevantes.

Todo modelo puede ser expresado a distintos niveles de precisin.

Los mejores tipos de modelos son aquellos que permiten elegir el grado de
detalle dependiendo de quin est viendo el sistema y por qu necesita
verlo. Lo que un usuario final espera de un modelo del sistema no es lo
mismo que necesita un diseador. Un analista o un usuario final se
centrarn en qu hace el sistema; un diseador/desarrollador se

centrar en el cmo. Tanto unos como otros querrn visualizar un

sistema a diferentes niveles de detalle en diferentes momentos.

Los mejores modelos son los que estn ligados a la realidad.

Todos los modelos simplifican la realidad; lo importante es que esta

simplificacin no enmascare ningn detalle importante. Es mejor tener
modelos que tengan una clara conexin con la realidad y donde esta
conexin sea dbil saber concretamente cmo se apartan estos modelos
del mundo real.

No es suficiente confeccionar un nico modelo. Todo sistema no

trivial se aborda mejor a travs de un conjunto de modelos casi
independientes.

Si por ejemplo, se estuviera realizando la construccin de una casa, no hay

un nico conjunto de planos que indiquen todos sus detalles sino que se
necesitarn planos de planta, de electricidad, de lozas, de agua, entre
otros. Lo mismo se aplica para los sistemas de software. Para comprender
la arquitectura de tales sistemas se necesitan varias vistas
complementarias y entrelazadas. Cuando se habla de modelos casi
independientes se refiere a tener modelos que podemos construir y
estudiar separadamente pero que estn interrelacionados.

1.2- Tipos de
metodologas
Concepto de Metodologa.
En principio podemos definir una metodologa como ... un conjunto de
filosofas, fases, procedimientos, reglas, tcnicas, herramientas,
documentacin y aspectos de formacin para los desarrolladores de
sistemas de informacin 2, segn lo expresa Piattini (2004, pg. 79)citando a Maddison - . De acuerdo a esta definicin, una metodologa es
entonces un conjunto de componentes que especifican:

Cmo dividir un proyecto en etapas.

Las tareas que se llevan a cabo en cada etapa.

3

Las salidas que se producen y cundo se deben producir.

Las restricciones se aplican.

Las herramientas que se van a utilizar.

Cmo se gestiona y controla un proyecto.

Considerando una definicin ms genrica, podemos decir que una

metodologa de desarrollo es un conjunto de procedimientos, tcnicas,
herramientas y un soporte documental que ayuda a los desarrolladores a
realizar un nuevo software. Normalmente consistir en una serie de fases
descompuestas en subfases (mdulos, etapas, pasos, entre otras formas de
denominacin). Esta descomposicin del proceso de desarrollo gua a los
desarrolladores en la eleccin de las tcnicas que debe elegir para cada
estado del proyecto, as como facilita la planificacin, gestin, control y
evaluacin de los proyectos.
Una metodologa, por lo tanto, representa el camino para desarrollar
software de manera sistemtica.
Se mencionan a continuacin algunos conceptos relacionados con las
metodologas:
Mtodos: Indican cmo construir tcnicamente un sistema. Abarcan un
amplio espectro de tareas que incluyen la comunicacin, el anlisis de los
requisitos, el modelado de diseo, la construccin de programas, la
realizacin de pruebas y el soporte. Se basan en un conjunto de principios
bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de
modelado y otras tcnicas descriptivas.
Tcnica: Es un mtodo estructurado y repetible para lograr una tarea
especfica.
Herramientas: Suministran un soporte automatizado o semiautomatizado
para el proceso y los mtodos. Cuando se integran herramientas para que
la informacin creada por una herramienta la pueda utilizar otra, se
establece un sistema de soporte para el desarrollo del software llamada
Ingeniera de Software Asistido por Computadora (CASE).

Objetivos de las Metodologas.

Se pueden identificar, de forma general, tres necesidades principales que
se intentan cubrir con una metodologa:

Mejores aplicaciones. De todos modos hay que tener en cuenta

que el seguimiento de una metodologa no basta para asegurar la
calidad del producto, sino que esto depende de muchos pequeos
factores.

Un mejor proceso de desarrollo que identifica las salidas o

productos intermedios de cada fase, lo que permite planificar y
controlar el proyecto.

Un proceso estndar en la organizacin, lo que aporta entre otros

beneficios una mayor integracin entre los proyectos de sistemas
en marcha y una mayor facilidad en el cambio de personal de un
proyecto a otro.

Entre los objetivos que pueden tener las metodologas, podemos

mencionar:

Registrar los requisitos de un sistema de informacin de manera

apropiada.

Proporcionar un mtodo sistemtico de desarrollo de forma que se

pueda controlar su progreso.

Construir un sistema de informacin dentro de un tiempo

apropiado y costos aceptables.

Construir un sistema bien documentado y que sea fcil de

mantener.

Ayudar a identificar lo ms pronto posible cualquier cambio que

sea necesario a realizar dentro del proceso de desarrollo.

Proporcionar un sistema que satisfaga a todas las personas

afectadas por el mismo, ya sean clientes, directivos, auditores,
usuarios.

Caractersticas deseables en una

buena Metodologa.
Entre las caractersticas deseables que debera incluir una metodologa se
pueden destacar las siguientes:

Existencia de reglas predefinidas: La metodologa debera indicar

formalmente reglas que definan sus fases, las tareas, productos
intermedios, tcnicas y herramientas a utilizar.

Cobertura total del ciclo de desarrollo: Debe indicar los pasos a

seguir para cubrir desde el planteamiento de un sistema hasta su
mantenimiento.

Verificaciones intermedias: Debe contemplar la realizacin de

verificaciones sobre los productos generados en cada fase para
comprobar su correccin.

Enlace con procesos de gestin: Debe proporcionar una forma de

desarrollar software de manera planificada, controlada y de
calidad.

Comunicacin efectiva: Debera proporcionar un medio de

comunicacin efectiva entre los desarrolladores para facilitar el
trabajo en grupo y con los usuarios.

Utilizacin sobre un abanico amplio de proyectos: Debe ser

flexible para poder emplearse en proyectos de diverso tamao,
variedad y entorno.

Fcil formacin: La organizacin debe formar a su personal en

todos los procedimientos y tcnicas definidos por la metodologa.

Uso de herramientas CASE: La metodologa debe ser soportada por

herramientas automatizadas que mejoren la productividad del
equipo de desarrollo y la calidad de los productos obtenidos.

Contener actividades que mejoren el proceso de desarrollo: Es

necesario definir mediciones que indiquen la calidad y el costo
asociado a cada etapa del proceso. Estos datos se utilizarn para
analizar y modificar el proceso para su mejora.

Soporte al mantenimiento: El campo de la evolucin del software

debera ser tenido en cuenta por las metodologas para facilitar las
modificaciones sobre los sistemas existentes.

Soporte de la reutilizacin de software: Se deberan incluir

procedimientos para la creacin, mantenimiento y recuperacin de
componentes reutilizables que no se limiten slo al cdigo. La
aplicacin de patrones de software en las distintas etapas del
proceso de desarrollo ayuda a la reutilizacin de soluciones de
anlisis y diseo.

Tipos de Modelos de Proceso

Como ya se mencion anteriormente, una metodologa debe cubrir todo el
ciclo de desarrollo de un sistema de software desde su planteamiento
hasta su evolucin. Dentro de este ciclo de vida una porcin muy
importante lo constituye el desarrollo del sistema de software.
Cualquier organizacin de ingeniera de software debe describir un
conjunto nico de actividades para el proceso de software que adopte para
el desarrollo del sistema. Tambin debe completar cada actividad con un
conjunto de acciones de ingeniera de software y definir cada accin en
cuanto a un conjunto de tareas que identifique el trabajo y los productos
del trabajo que deben completarse para alcanzar las metas de desarrollo.
Despus, la organizacin debe adaptar el modelo de proceso resultante y
ajustarlo a la naturaleza especfica de cada proyecto, a las personas que lo
realizarn y el ambiente en el que se ejecutar el trabajo.
Se mencionan a continuacin algunos de los modelos prescriptivos de
proceso que consideramos ms representativos tal como los presenta
Roger Pressman (2006) en su libro Ingeniera de Software (ver
Bibliografa), sin que esta enumeracin sea exhaustiva ni la nica manera
de clasificar los mismos. Luego en la Unidad 2 se presentar el Proceso
Unificado de Desarrollo.

El ciclo de vida clsico o en cascada.

El modelo en cascada, llamado tambin el ciclo de vida clsico, sugiere un
enfoque sistemtico, secuencial hacia el desarrollo de software tal como se
visualiza en la siguiente figura:

Fuente: Libro Ingeniera del Software Roger Pressman (2006), Pg. 50.

El modelo en cascada es el ms antiguo para la Ingeniera de software, sin

embargo las crticas realizadas a este modelo durante las dcadas
precedentes ocasionaron que an sus ms fervientes seguidores se hayan
cuestionado su eficacia.
Entre los problemas que presenta el modelo en cascada podemos
enunciar:

Los proyectos reales rara vez siguen el flujo secuencial que

propone el modelo.

Frecuentemente es difcil para el cliente definir todos los requisitos

de manera explcita en el inicio del proyecto.

Una versin funcional de los programas slo estar disponible

cuando el proyecto est bastante avanzado, por lo que el cliente
deber tener paciencia.

La naturaleza lineal del modelo en cascada conduce a situaciones en las

cuales algunos miembros del equipo de trabajo deben esperar a otros para
terminar tareas dependientes, lo cual bloquea el avance del proyecto. Sin
embargo, este modelo de proceso puede resultar til en casos donde los
requerimientos estn fijos y donde el trabajo se realice en forma lineal
hasta su conclusin.
Modelos de procesos incrementales.
Muchas veces los requisitos iniciales del software estn bien definidos de
manera razonable, pero el enfoque global del esfuerzo de desarrollo
excluye un proceso puramente lineal. Adems, es probable que sea
necesario proporcionar de manera rpida un conjunto limitado de
funcionalidad para el usuario y luego refinarla y expandirla en las entregas
posteriores del software. En estos casos es conveniente elegir un modelo
de proceso diseado para producir el software de manera incremental.
Se presentan a continuacin dos modelos de proceso de este tipo.
a) El modelo incremental.
El modelo incremental combina elementos del modelo en cascada aplicado
en forma iterativa. Como se muestra en la siguiente figura, este modelo
aplica secuencias lineales de manera escalonada conforme avanza el
tiempo en el calendario.

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 52.

Cada secuencia lineal produce incrementos en el software. Con frecuencia,

el primer incremento es un producto esencial, es decir se consideran los
requisitos bsicos pero muchas caractersticas complementarias an no se
incorporan. El producto producido se muestra al cliente y como resultado
de la evaluacin se desarrolla un plan para el incremento siguiente que
afronta la modificacin del producto esencial a fin de satisfacer mejor las
necesidades del cliente e incorporar caractersticas y funcionalidades
adicionales.
Este proceso se repite despus de la entrega de cada incremento hasta
producir el producto completo.
El desarrollo incremental es til cuando el personal necesario para una
implementacin completa no est disponible; si el producto esencial es
bien recibido se agrega el personal necesario para implementar el
incremento siguiente. Adems los incrementos se pueden planear para
manejar los riesgos tcnicos; por ejemplo, cierta funcionalidad puede
requerir el uso de un hardware nuevo que an no est disponible entonces
se planean los primeros incrementos de manera que se evite el uso de este
hardware.
b) El modelo DRA.
El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso
incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una
adaptacin a alta velocidad del modelo en cascada en el que se logra el
desarrollo rpido mediante un enfoque de construccin basado en
componentes. Con una buena comprensin de los requisitos y se limita el
mbito del proyecto, el proceso DRA permite que un equipo de desarrollo

obtenga el producto de software completamente funcional dentro de un

perodo muy corto, por ejemplo entre 60 y 90 das.
En la siguiente figura se ilustra el proceso DRA:

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 54.

Si una aplicacin de negocios se puede modular de modo que cada gran

funcin se pueda completar en menos de tres meses es una candidata para
aplicar DRA. Cada gran funcin se puede abordar por un equipo separado
aplicando DRA, luego se integran y se forma el todo.
Como todos los modelos de proceso, este enfoque presenta algunos
inconvenientes:

Para proyectos grandes escalables se necesitan suficientes recursos

humanos para crear el nmero correcto de equipos DRA.

Los proyectos DRA pueden fracasar si los desarrolladores y clientes

no se comprometen con las actividades rpidas necesarias para
completar el sistema en tiempo breve.

Es problemtica la construccin de los componentes necesarios

para el DRA si el sistema no se puede modular en forma apropiada.

Si el alto rendimiento es un aspecto importante y se alcanzar al

convertir interfaces en componentes del sistema, este enfoque
puede no funcionar.

10

El modelo DRA no es apropiado cuando los riesgos tcnicos son

altos, por ejemplo cuando la nueva aplicacin requerir muchas
nuevas tecnologas.

Modelos de procesos evolutivos.

Al igual que todos los sistemas complejos, el software evoluciona con el
tiempo. Los requisitos del negocio y productos frecuentemente cambian
durante el proceso de desarrollo; en estos casos una ruta lineal que
conduzca al producto final no ser real. En estas situaciones los ingenieros
de software necesitan un modelo de proceso que haya sido diseado de
manera explcita para incluir un producto que evolucione con el tiempo.
Los modelos evolutivos son iterativos y se caracterizan por la forma en que
permiten que se desarrollen versiones cada vez ms completas del
software.
Se presentan a continuacin dos modelos de proceso de este tipo:
a) Construccin de prototipos.
Frecuentemente los clientes definen un conjunto de objetivos generales
para el software pero no identifican los requisitos detallados de entrada,
proceso o salida. En estos casos y en muchas otras situaciones un modelo
de construccin de prototipos puede ser de utilidad.
En este modelo el proceso se inicia con la comunicacin, en la cual el
ingeniero de software y el cliente encuentran y definen los objetivos
globales para el software, identifican los requisitos conocidos y las reas
del esquema en las que se necesita ms definicin. Se plantea entonces
con rapidez una iteracin de construccin de prototipos y se presenta el
modelado en forma de un diseo rpido. Este diseo rpido se centra en
una representacin de los aspectos del software que sern visible para el
usuario final y conduce a la construccin de un prototipo. El cliente/usuario
evala el prototipo y con la retroalimentacin se refinan los requisitos del
software que se desarrollar. La iteracin ocurre cuando el prototipo se
ajusta para satisfacer las necesidades del cliente.

11

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 55.

Si bien la construccin de prototipos se puede utilizar como un modelo de

proceso independiente, se emplea ms comnmente como una tcnica
que puede implementarse dentro del contexto de cualquiera de los
modelos de proceso expuestos.
La construccin de prototipos tambin plantea algunos inconvenientes:

El cliente ve lo que parece una versin en funcionamiento del

software sin saber que por la prisa de hacer funcionar el prototipo
no se ha considerado la calidad del software global o la facilidad de
mantenimiento a futuro y le cuesta comprender que debe
construirse otra vez para mantener los altos niveles de calidad.

Muchas veces el desarrollador establece compromisos de

implementacin para lograr que el prototipo funcione con rapidez y
luego se familiariza con las selecciones realizadas y se olvidan las
razones por las que son inapropiadas.
b) El modelo en espiral

El modelo en espiral que fue propuesto originalmente por B. Boehm es un

modelo de proceso de software evolutivo que combina la naturaleza
iterativa de la construccin de prototipos con los aspectos controlados y
sistemticos del modelo en cascada.
Cuando se aplica este modelo el software se desarrolla en una serie de
entregas evolutivas. Durante las primeras iteraciones la entrega tal vez
consista en un documento del modelo del sistema o un prototipo, luego

12

durante las ltimas iteraciones se obtienen versiones cada vez ms

completas del producto de software.
El modelo en espiral que se expone a continuacin es una variacin del
modelo original, presentada en el libro Ingeniera de Software de Roger
Pressman (2006) (ver Bibliografa).

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 58.

En el primer circuito del espiral quiz se genere la especificacin del

producto y los pasos siguientes alrededor del espiral producirn el
desarrollo de un prototipo y luego progresivamente, versiones ms
elaboradas del software. En cada paso sobre la regin de planeacin se
producen ajustes al plan del proyecto.
A diferencia de otros modelos de proceso que terminan cuando se entrega
el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de
todo el ciclo de vida del producto de software siguiendo la evolucin del
mismo.
El modelo en espiral mantiene el enfoque sistemtico de los pasos que
sugiere el modelo en cascada pero lo incorpora al marco de trabajo
iterativo que se adapta menor al mundo real. Asimismo, permite a los
desarrolladores aplicar la construccin de prototipos como un mecanismo
para reducir riesgos y en general en cualquier etapa evolutiva del producto.
De todos modos este modelo, al igual que otros, no est libre de
inconvenientes. Es difcil convencer a los clientes de que el enfoque
evolutivo es controlable; si un riesgo importante no se descubre y
administra apropiadamente, surgirn problemas.

13

1.3- Caractersticas de
los Modelos Orientados
a Objetos
El Paradigma Orientado a Objetos
En los Modelos Orientados a Objetos, el sistema se puede ver (en trminos
de percepcin) como una coleccin de objetos que colaboran entre s para
obtener un objetivo comn. Las operaciones que modifican el estado de los
objetos son sencillas; los objetos se construyen a partir de otros objetos lo
que lleva a que los sistemas se puedan construir a partir de componentes
probados.
Por lo enunciado anteriormente, las tcnicas orientadas a objetos se
pueden utilizar como medios para el diseo sencillo de sistemas complejos.
La orientacin a objetos es muy poderosa cuando se combinan varias
tecnologas: metodologas de Anlisis y Diseo Orientado a Objetos,
herramientas CASE (Ingeniera de Software Asistida por Computadora),
Programacin Visual, Generadores de Cdigo, entre otras.
El anlisis y diseo orientado a objetos tiene algunas caractersticas
importantes:

Cambian nuestra forma de pensar sobre los sistemas. Para la

mayora de las personas la forma de pensar OO es ms natural.
Comenzamos a aprender sobre ellos desde la infancia (por ejemplo,
al agitar un sonajero ste hace ruido). Desde una etapa muy
temprana categorizamos los objetos y descubrimos su
comportamiento.

Los sistemas suelen construirse a partir de objetos ya existentes.

Esto lleva a un alto grado de reutilizacin, a una disminucin de
costos, un menor tiempo de desarrollo y una mayor confiabilidad
del sistema.

La complejidad de los objetos que podemos utilizar sigue en

aumento, puesto que nuevos objetos se construyen a partir de

14

otros, que a su vez estn constituidos por otros objetos, y as

sucesivamente.

Ayuda a explotar la potencia expresiva de los lenguajes de

programacin basados en objetos y orientados a objetos.

Elementos del Modelo de Objetos

Para todo lo que se considere orientado a objetos (un lenguaje de
programacin, un herramienta CASE, tcnicas de modelado, un proceso de
desarrollo, por ejemplo) el marco de referencia conceptual es el modelo de
objetos. Hay cuatro elementos fundamentales en este modelo:

Abstraccin

Encapsulamiento

Modularidad

Jerarqua

Al decir fundamentales se quiere significar que cualquier modelo que

carezca de alguno de estos elementos no se considera orientado a
objetos.
Desarrollamos a continuacin el concepto de cada uno de los elementos
fundamentales.

Abstraccin

Como la define Grady Booch, la abstraccin denota las caractersticas

esenciales de un objeto que lo distinguen de todos los dems tipos de
objeto y proporciona as fronteras conceptuales ntidamente definidas
respecto a la perspectiva del observador. (Booch Grady, 1996, pg. 46).
Una abstraccin se centra en la visin externa de un objeto y sirve para
separar el comportamiento esencial de un objeto de su forma de
implementacin.
En el desarrollo del modelo de objetos de un sistema se tratar de
construir abstracciones de entidades que imiten directamente el
vocabulario de un determinado dominio de problema.

15

Se puede caracterizar el comportamiento de un objeto considerando los

servicios que presta a otros objetos, as como las operaciones que puede
realizar sobre otros objetos. Este punto de vista nos lleva a concentrarnos
en la visin exterior del objeto, lo que algunos llaman el modelo
contractual; la vista exterior de cada objeto define un contrato del que
pueden depender otros objetos y que a su vez es llevado a cabo por la vista
interior del propio objeto (a menudo en colaboracin con otros objetos).
Este contrato abarca las responsabilidades de un objeto, es decir el
comportamiento del que se le considera responsable.
Por ejemplo, en un banco uno de los servicios ofrecidos es del de Caja de
Ahorro. Desde una vista externa una caja de ahorro en un objeto que sabe
cul es su nmero de cuenta, a quin pertenece y cul es su saldo (de
manera simplificada). Qu es su nmero de cuenta? Un valor numrico de
ocho dgitos y su saldo ser un valor que represente el monto de dinero
actualmente depositado en ella. Sus responsabilidades sern, entre otras:
Conocer su saldo actual
Conocer su nmero
Incrementar su saldo por un depsito
Disminuir su saldo por una extraccin
Conocer quin es su titular
Mostrar sus dato
Conocer su fecha de cierre

Encapsulamiento

La abstraccin y el encapsulamiento son conceptos complementarios: la

abstraccin se centra en el comportamiento observable de un objeto,
mientras el encapsulamiento se centra en la implementacin que da lugar
a este comportamiento. El encapsulamiento se consigue mediante la
ocultacin de informacin, por el cual se ocultan todos los aspectos de un
objeto que no contribuyen a sus caractersticas esenciales. Normalmente lo
que se oculta es la estructura de datos de un objeto as como la
implementacin o codificacin de sus mtodos.
Grady Booch define el encapsulamiento como el proceso de almacenar en
un mismo compartimiento los elementos de una abstraccin que
constituyen su estructura y su comportamiento; sirve para separar la

16

interfaz contractual de una abstraccin y su implantacin. (Booch Grady,

1996, pg. 54,56).
En nuestro ejemplo de la caja de ahorro, por ejemplo, la propiedad saldo
podra estar internamente almacenada como:

Saldo: campo de tipo real con dos decimales

O podra estar almacenada de la siguiente manera:

Importe entero: campo entero que almacena la cantidad entera del

saldo

Importe decimal: campo entero que almacena la cantidad decimal

del saldo

Cualquier objeto titular que solicite a caja de ahorro que muestre su

saldo recibir como respuesta, por ejemplo, $ 100,50 y nunca se enterar
de qu manera est internamente guardado este dato, as como tampoco
sabr cmo operan los mtodos de caja de ahorro para mostrar este saldo.
De igual manera, cuando a un objeto titular le llega una solicitud de
servicio (mensaje) por el cual se le pide mostrar su nombre, ste retornar
una cadena de caracteres en la que figuran su apellido, primer nombre y
segundo nombre, si lo tuviera. El objeto que hizo la solicitud no sabe si el
objeto titular tiene:
Un atributo apellidoYNombre
Dos atributos: apellido
nombre
Tres atributos: apellido
primerNombre
segundoNombre
De este modo el encapsulamiento permite que se pueda cambiar la
implementacin de un objeto y que ninguna otra parte del sistema deba
ser modificada siempre que no modifique su interfaz (abstraccin), que es
lo que los otros objetos conocen para poder comunicarse con este objeto.

Modularidad

Como afirma Booch citando a Liskov la modularizacin consiste en

dividir un programa en mdulos que pueden compilarse separadamente,
pero que tienen conexiones con otros mdulos. (Booch Grady, 1996, pg.
61).

17

En algunos lenguajes las clases y objetos forman la estructura lgica de un

sistema; se sitan, entonces, estas abstracciones en mdulos para producir
la arquitectura fsica del sistema.
Los mdulos sirven como contenedores fsicos en los que se declaran las
clases y objetos del diseo lgico realizado. Especialmente para
aplicaciones grandes en las que puede haber varios cientos de clases el uso
de mdulos es esencial para ayudar a manejar la complejidad. Para
problemas muy pequeos el desarrollador podra decidir declarar todas las
clases en el mismo paquete. Para cualquier situacin que se salga de lo
trivial, es mejor solucin agrupar las clases que se relacionan lgicamente
en el mismo mdulo.
Desde nuestra perspectiva, concluye Booch, la modularidad es la
propiedad que tiene un sistema que ha sido descompuesto en un conjunto
de mdulos cohesivos y dbilmente acoplados. (Booch Grady, 1996, pg.
61).

Jerarqua

La jerarqua es una forma de clasificar u ordenar las abstracciones.

Frecuentemente un conjunto de abstracciones forma una jerarqua y la
identificacin de estas jerarquas en el anlisis y diseo simplifica en gran
medida la comprensin del problema.
Las dos jerarquas ms importantes son:

Su estructura de clases: la jerarqua de clases est dada por la

herencia.

Su estructura de objetos: la jerarqua de objetos est dada por la

agregacin.

No desarrollamos aqu estos conceptos porque se vern ms adelante en

las secciones Relaciones entre Clases y Relaciones entre Objetos.

Objetos y Clases
OBJETO.

Concepto

Como lo plantea Booch, desde la perspectiva de la cognicin humana un

objeto puede ser:

18

- Una cosa tangible y/o visible.

- Algo que puede comprenderse intelectualmente.
- Algo hacia lo que se dirige un pensamiento o accin. (Booch Grady, 1996,
pg. 96).
A esta definicin informal podemos agregar que un objeto modela alguna
parte de la realidad y es por lo tanto algo que existe en el tiempo y en el
espacio.
Ahora bien, los objetos del mundo real no son el nico tipo de objeto de
inters en el desarrollo de software. Existen otros tipos importantes de
objetos que son invenciones del proceso de diseo cuyas colaboraciones
con objetos semejantes sirven como mecanismos para desempear algn
comportamiento de nivel superior. Esto nos lleva a una definicin
mejorada segn la cual un objeto representa un elemento, unidad o
entidad individual e identificable, ya sea real o abstracta, con un papel bien
definido en el dominio del problema.
Un objeto tiene estado, comportamiento e identidad; la estructura y
comportamiento de objetos similares estn definidos en su clase comn.

Estado:

Booch nos proporciona la siguiente definicin el estado de un objeto

abarca todas las propiedades (normalmente estticas) del mismo ms los
valores actuales (normalmente dinmicos) de cada una de esas
propiedades. (Booch Grady, 1996, pg. 98).
Una propiedad es una caracterstica inherente o distintiva, un rasgo o
cualidad que hace que ese objeto sea ese y no otro. Las propiedades suelen
ser estticas porque estos atributos suelen ser inmutables y fundamentales
para la naturaleza del objeto.
Todas las propiedades tienen algn valor. Este valor puede ser una mera
cantidad o puede denotar otro objeto. Se dice que los valores son
normalmente dinmicos porque en algunos casos los valores son
estticos, como en nuestro ejemplo de Caja de Ahorro la propiedad (o
atributo) nmero no cambia, va a cambiar seguramente el valor del
atributo saldo y probablemente el del atributo fechaDeCierre...
Siguiendo con este ejemplo el estado de un objeto caja de ahorro estar
dado por los valores que adopte la propiedad saldo y fechaDeCierre. As los
estados posibles sern:

19

Con saldo: si el valor de saldo es mayor a cero

Sin saldo: si el valor de saldo es igual a cero

Cerrada: si el valor de fechaDeCierre es distinto a vaco.

Comportamiento:

Ningn objeto existe de forma aislada. Los objetos reciben acciones y ellos
mismos actan sobre otros objetos.
El comportamiento es cmo acta y reacciona un objeto, en trminos de
sus cambios de estado y paso de mensajes (Booch Grady, 1996, pg. 101).
es decir, el comportamiento de un objeto representa su actividad visible y
comprobable exteriormente. Una operacin representa un servicio que
todos los objetos de una clase ofrecen a sus clientes. Se reconocen cinco
tipos de operaciones sobre un objeto. Los tres tipos ms comunes de
operaciones son los siguientes:
Modificador: Una operacin que altera el estado de un objeto
(modifica el valor de alguno/s de sus atributos. Por ejemplo:
depositar, extraer, transferir para un objeto cajaDeAhorro.
Selector: Una operacin que accede al estado de un objeto (a
alguno/s de sus atributos) pero no altera ese estado. Por ejemplo:
mostrarTitular, mostrarSaldo, mostrarNumeroCuenta.
Iterador: Una operacin que permite acceder a todas las partes de
un objeto en algn orden perfectamente establecido. Por ejemplo,
si un objeto Titular tiene una propiedad nroTelfono con mltiples
valores (para el telfono particular, laboral, celular) la operacin
mostrarTelfono ser una operacin iteradota.
Hay otros dos tipos de operaciones habituales, que representan la
infraestructura necesaria para crear y destruir objetos (instancias de una
clase):
Constructor: Una operacin que crea un objeto y/o inicializa su
estado.
Destructor: Una operacin que libera el estado de un objeto y/o
destruye el propio objeto.
Unificando las definiciones de estado y comportamiento, Rebecca WirfsBrock defini las responsabilidades de un objeto de manera que stas
incluyen el conocimiento que un objeto mantiene y las acciones que puede
llevar a cabo.
20

Las responsabilidades de un objeto son todos los servicios que ste

proporciona.

Identidad:

En el paradigma orientado a objetos, la identidad es la propiedad que tiene

un objeto que le permite distinguirse de todos los dems objetos. La
mayora de los sistemas de bases de datos utilizan claves de identificacin
para distinguir objetos persistentes, mezclando el valor de un dato con la
identidad.
En el mundo de los objetos podemos tener dos de ellos con valores iguales
en todas sus propiedades y seguir siendo dos objetos distintos cada uno
con su propia identidad. Por ejemplo, puede haber dos objetos Persona
que tengan exactamente el mismo nombre, apellido, direccin y telfono,
pero eso no significa que sean la misma persona (tenemos muchos casos
conocidos de padres e hijos con los mismos nombres y mientras vivan en la
misma casa tambin la misma direccin); en el paradigma orientado a
objetos cada uno de esos objetos tiene su propia identidad y son
perfectamente identificables.
Los sistemas de bases de datos relacionales son incapaces de distinguir
entre dos objetos o instancias con valores iguales, por ello se hace
indispensable contar con una clave identificatoria, que en nuestro ejemplo
de padre e hijo sera por ejemplo el nmero de documento. Esta ser una
cuestin importante a considerar si llegado el momento de decidir la forma
de persistencia de nuestro modelo orientado a objetos la elegida es una
base de datos relacional. En este momento habr que disponer de un
mecanismo que salve las diferencias de ambos esquemas de
representacin.

CLASE

Concepto:

Los conceptos de clase y objeto estn estrechamente relacionados, porque

no puede hablarse de un objeto sin atencin a su clase. Sin embargo,
existen diferencias entre ambos trminos. Mientras que un objeto es una
entidad concreta que existe en el tiempo y en el espacio, una clase
representa slo una abstraccin, la esencia de un objeto.
En el contexto del anlisis y diseo orientado a objetos, Booch define una
clase como un conjunto de objetos que comparten una estructura comn
y un comportamiento comn (Booch Grady, 1996). Esto significa que una

21

clase es una descripcin de un conjunto de objetos que comparten los

mismos atributos, operaciones, relaciones y semntica.
Las clases son los bloques de construccin ms importantes de cualquier
sistema orientado a objetos. Se pueden utilizar para capturar el
vocabulario del sistema que se est desarrollando. Estas clases pueden
incluir abstracciones que formen parte del dominio del problema, as como
clases que constituyen el dominio de una determinada solucin
tecnolgica. Se pueden utilizar clases para representar cosas que sean
software, hardware o puramente conceptuales.

Responsabilidades de una clase:

Una responsabilidad es un contrato o una obligacin de una clase. Al crear

una clase, se est expresando que todos los objetos de esa clase tienen el
mismo tipo de estado y el mismo tipo de comportamiento. A un nivel ms
abstracto, estos atributos y operaciones son simplemente las
caractersticas por medio de las cuales se llevan a cabo las
responsabilidades de una clase.
Al modelar clases, un buen comienzo consiste en especificar las
responsabilidades de los elementos del vocabulario. Una clase puede tener
cualquier nmero de responsabilidades, aunque en la prctica cada clase
bien estructurada tiene al menos una responsabilidad y a lo sumo unas
pocas. Al ir refinando el modelo se traducirn estas responsabilidades en el
conjunto de atributos y operaciones que mejor satisfagan las
responsabilidades de la clase.
Las responsabilidades se enuncian como texto libre: una frase, una
sentencia o, como mucho, un prrafo corto.

Vistas de una clase:

Debemos distinguir entre la visin externa (interfaz), y la visin interna,

(implementacin), de una clase.
La interfaz de una clase proporciona su visin externa y por lo tanto
enfatiza la abstraccin a la vez que oculta su estructura y su
comportamiento. Esta interfaz se compone principalmente de las
declaraciones de todas las operaciones aplicables a instancias de esta clase
(objetos), pero tambin puede incluir la declaracin de constantes,
variables y excepciones que se necesiten para completar la abstraccin.

22

Por otro lado, la implementacin de una clase es su visin interna, que

engloba los secretos de su comportamiento. La implementacin de una
clase se compone de la implementacin de todas las operaciones definidas
en la interfaz de la misma.
Se puede especificar la interfaz de una clase con cualquiera de los tres
niveles de visibilidad disponibles:
Pblica: Una declaracin accesible a todos los clientes de esa clase.
Protegida: Una declaracin accesible slo a la propia clase, sus
subclases y clases amigas.
Privada: Una declaracin accesible slo a la propia clase y sus clases
amigas.
A lo que nos indica la bibliografa clsica podemos agregar un tipo ms de
visibilidad generalmente soportado por los lenguajes orientados a objetos
y las herramientas automatizadas de modelado que es la visibilidad de
paquete, esto significa que el elemento el pblico dentro del paquete o
subsistema en el que se encuentre alojado.
La implementacin de estas caractersticas depender de cmo lo maneje
el lenguaje de programacin elegido.
A continuacin se muestra una forma de representacin grfica para una
clase, utilizada en UML (Lenguaje Unificado de Modelado, ver Unidad 2 de
este mdulo)

Nombre: Cada clase ha de tener un nombre que la distinga de otras

clases. Una clase puede dibujarse mostrando slo su nombre, como
se muestra a continuacin:

23

Atributos: Un atributo es una propiedad de una clase identificada

con un nombre, que describe un rango de valores que pueden
tomar las instancias de la propiedad. Una clase puede tener
cualquier nmero de atributos o no tener ninguno. Un atributo
representa alguna propiedad del elemento que se est modelando
que es compartida por todos los objetos de esa clase. Un atributo
es una abstraccin de un tipo de dato o estado que puede incluir un
objeto de la clase.
Operaciones: Una operacin es la implementacin de un servicio
que puede ser requerido a cualquier objeto de la clase para que
muestre su comportamiento, es decir, una operacin es una
abstraccin de algo que se puede hacer a un objeto y que es
compartido por todos los objetos de la clase. Una clase puede tener
cualquier nmero de operaciones y por lo menos una operacin. A
menudo, pero no necesariamente, la invocacin de una operacin
sobre un objeto cambia los datos o el estado del objeto. En nuestro
ejemplo sera el caso de las operaciones depositar() y extraer().
Dependiendo del nivel de abstraccin en que se est modelando
nos referiremos a responsabilidades (a nivel modelado de requisitos
y anlisis), operaciones (en general a nivel diseo) y mtodos
(normalmente durante la etapa de implementacin/codificacin),
para referirnos a los servicios que prestan los objetos de una clase.

RELACIONES ENTRE OBJETOS

Un objeto por s mismo no es demasiado interesante. Los objetos
contribuyen al comportamiento de un sistema colaborando con otros. Hay
dos tipos de relaciones que se pueden dar entre objetos: enlaces y
agregacin.

Enlaces:

Como nos cita Booch el trmino enlace es definido por Rumbaugh como
una conexin fsica o conceptual entre objetos. (Booch Grady, 1996).
Un objeto colabora con otros a travs de sus enlaces con stos. Esto
quiere decir que un enlace denota la asociacin especfica por la cual un

24

objeto (el cliente) utiliza los servicios de otro objeto (el servidor) o a travs
de la cual un objeto puede comunicarse con otro.
Un concepto esencial en el paradigma orientado a objetos, es el hecho de
que los objetos colaboran entre s para llevar a cabo un comportamiento
superior.
Una colaboracin representa la solicitud de un servicio desde un objeto
cliente a un objeto servidor para cumplir una responsabilidad del cliente.
Los objetos de una clase pueden cumplir una responsabilidad por s solos o
pueden requerir la asistencia de otros objetos (de otras clases).
Se dice que un objeto S colabora con otro objeto C, si el objeto C para
cumplir con una responsabilidad, necesita enviar algn mensaje a S
solicitndole un servicio. Desde el punto de vista del cliente, C, cada una
de sus colaboraciones estn asociadas con una responsabilidad particular
implementada por el servidor, S.
Un mensaje enviado de un objeto a otro representa la existencia de un
enlace entre ambos. Los mensajes se muestran como lneas dirigidas, que
representan su direccin, con una etiqueta que nombra al propio mensaje.
Aunque el paso de mensajes es iniciado por el cliente y dirigido hacia el
servidor los datos pueden fluir en ambas direcciones a travs de un enlace:
del cliente al servidor: parmetros
del servidor al cliente: respuesta
Supongamos que el objeto cajaDeAhorro, que conoce quin es su
titular, como parte de su responsabilidad de mostrar sus datos
completos debe mostrar el nombre del titular. Entonces necesita pedirle al
objeto Titular que le retorne su nombre, para ello le enviar un mensaje
indicndole tal solicitud. El objeto Titular responder retornndole su
nombre. As se manifiesta el enlace entre ambos objetos. Esto puede
representarse grficamente de la siguiente manera:

El grfico donde se muestran los enlaces entre objetos se denomina

Diagrama de Colaboraciones y en general se utiliza durante el modelado
de anlisis.

25

Agregacin:

La agregacin denota una jerarqua todo/parte, en la cual un objeto del

todo tiene o contiene objetos de la parte.
La agregacin puede o no denotar contencin fsica. Por ejemplo, un
aeroplano se compone de alas, motores, tren de aterrizaje: es un caso de
contencin fsica. En otro ejemplo, un accionista tiene acciones, pero las
acciones no son de ninguna manera parte fsica del accionista. Esta ltima
relacin todo/parte es ms conceptual y por lo tanto menos directa que la
agregacin fsica de las partes que forman un aeroplano.
Se desarrolla este tema con ms detalle en el punto siguiente, Relaciones
entre Clases.

RELACIONES ENTRE CLASES

Las clases, al igual que los objetos, no existen aisladamente. Antes bien,
para un dominio de problema especfico las abstracciones clave suelen
estar relacionadas por vas muy diversas e interesantes, formando la
estructura de clases.
Existen tres tipos bsicos de relaciones entre clases, en UML:
Generalizacin/Especializacin, que denota una relacin del tipo es
un, padre/hijo, conocida como herencia.

Asociacin, que denota alguna dependencia semntica entre clases

de otro modo independientes.

Dependencia, es una relacin de uso, se usarn cuando se quiera

indicar que un elemento utiliza a otro. Uno de los usos ms
frecuentes de la dependencia es para modelar una visibilidad
temporal desde los objetos de una clase hacia los objetos de otra.

Herencia:

La herencia es una implantacin de la generalizacin. La generalizacin

establece que las propiedades de un tipo se aplican a sus subtipos. La
herencia hace que la estructura de datos y operaciones de una clase
(padre) estn disponibles para su reutilizacin por parte de sus subclases

26

(hijos). La herencia de las operaciones de una superclase permite que las

clases compartan el cdigo (en vez de volverlo a definir). La herencia de
estructura de datos permite la reutilizacin de la estructura.
En trminos sencillos, la herencia es una relacin entre clases en la que una
clase comparte la estructura y/o el comportamiento definidos en una
(herencia simple) o ms clases (herencia mltiple). La clase de la que otras
heredan se denomina superclase o clase padre y la clase que hereda de
otra o ms clases se denomina subclase o clase hija.
A menudo, una subclase aade atributos y operaciones a los que hereda de
sus padres, pero tambin puede redefinir el comportamiento heredado.
Una operacin de un hijo con la misma signatura (nombre, parmetros y
valor de retorno) que una operacin del padre, redefine la operacin
heredada del padre; esto se conoce como polimorfismo, haciendo alusin a
una operacin que adopta varias formas de implementacin segn haya
sido redefinida en las clases hijas.
Una clase puede tener uno o ms padres o bien no tener ninguno. Una
clase sin padres y uno o ms hijos se denomina raz o clase base. Una clase
sin hijos se denomina clase hoja. Una clase con un nico padre se dice que
utiliza herencia simple; una clase con ms de un padre se dice que utiliza
herencia mltiple.
Las clases hojas son de las que se espera que existan instancias, es decir
objetos, por ello se las denomina tambin clases concretas. Las clases sin
instancias se llaman clases abstractas. Una clase abstracta se redacta con la
idea de que las subclases aadan elementos a su estructura y
comportamiento, usualmente completando la implementacin de sus
mtodos. De modo que nunca existirn objetos de una clase abstracta.
Grficamente, la generalizacin se representa como una lnea dirigida
continua, con una punta de flecha vaca apuntando al padre, como se
muestra en el siguiente ejemplo:

27

Observacin: La simbologa que se est utilizando para graficar las relaciones entre clases es
la establecida por UML.

Asociacin:

Una asociacin es una relacin estructural que especifica que los objetos
de una clase estn conectados con los objetos de otra. Una asociacin slo
denota una dependencia semntica entre dos clases pero no establece la
forma exacta en que una clase se relaciona con la otra; slo puede
denotarse esa semntica nombrando el papel que desempea cada clase
en relacin con la otra.
Dada una asociacin entre dos clases se puede navegar desde un objeto de
una clase hasta un objeto de la otra.
Grficamente, una asociacin se representa como una lnea continua que
conecta la misma o diferentes clases:

28

Un concepto importante a modelar respecto de una asociacin es la

navegacin. La navegacin de una asociacin especfica que dado un
objeto perteneciente a la clase de un extremo se puede llegar fcil y
directamente a los objetos de la clase del otro extremo, normalmente
debido a que el objeto inicial almacena algunas referencias a los objetos en
el destino. La direccin de la navegacin indica qu clase es la que
contiene la referencia hacia la otra (determina quin conoce a quin).

Puede ocurrir que en algunos casos la asociacin necesite ser navegable en

ambos sentidos. Por ejemplo:
Para mostrar los datos completos de una factura es necesario que
factura conozca al cliente al que corresponde.
Para mostrar un resumen de cuenta de un cliente es necesario que
cliente conozca las facturas que le corresponden.
Esta situacin se modela de la siguiente manera:

29

O tambin se puede modelar as:

Es legal que ambos extremos de una asociacin estn conectados a la

misma clase. Esto significa que, dado un objeto de una clase, se puede
conectar con otro/s objeto/s de la misma clase. A este tipo de asociaciones
se les denomina reflexivas. Por ejemplo:

En este ejemplo se recurri a otro elemento con el que podemos adornar

una asociacin: la definicin de un rol. Cuando una clase participa en una
asociacin, tiene un rol especfico que juega en la asociacin; un rol es
simplemente la cara que la clase de un extremo de la asociacin presenta a
la clase del otro extremo.
En muchas situaciones de modelado, es importante sealar cuntos
objetos pueden conectarse a travs de una instancia de la asociacin. Este
cuntos se denomina multiplicidad de la asociacin y se escribe como
una expresin que se evala a un rango de valores o a un valor explcito.
Cuando se indica una multiplicidad en un extremo de una asociacin se
est especificando que para cada objeto de la clase en el extremo opuesto

30

debe haber tantos objetos en este extremo. Se puede indicar una

multiplicidad de exactamente uno (1), cero (0), muchos (*), uno o ms
(1..*) o un valor exacto (por ejemplo, 5). La multiplicidad se indica en el
extremo que corresponde a la navegacin.

Agregacin:

La agregacin es un tipo especial de asociacin. Las relaciones de

agregacin entre clases tienen un paralelismo directo con las relaciones de
agregacin entre los objetos correspondientes a esas clases. La agregacin
es una relacin todo/parte en la cual una clase representa una cosa
grande (el todo), que consta de elementos ms pequeos (las partes).
Representa una relacin del tipo tiene un, o sea, un objeto del todo tiene
objetos de la parte.
Grficamente la agregacin se representa como se muestra a continuacin:

La agregacin puede o no denotar contencin fsica. Tenemos entonces

dos posibilidades en cuanto a la relacin de agregacin:

31

Agregacin por Valor: Es un tipo de relacin, en la que el tiempo de

vida del objeto incluido est condicionado por el tiempo de vida del
que lo incluye. Este tipo de relacin es tambin llamada
Composicin (el Objeto base se construye a partir del objeto
incluido, es decir, es "parte/todo").
En este tipo de relacin el objeto parte no existe
independientemente del objeto todo que lo contiene. Esto
significa que el tiempo de vida de ambos objetos est ntimamente
relacionado: cuando se crea una instancia del todo, se crea tambin
por lo menos una instancia de la parte; cuando se destruye el
objeto todo esto implica la destruccin de todos los objetos
parte relacionados a l.
En el ejemplo, cuando se crea una instancia de Pedido (un objeto
pedido) es porque existe al menos una instancia (objeto) de la clase
DetallePedido.

Agregacin por Referencia: Es un tipo de relacin, en donde el

tiempo de vida del objeto incluido es independiente del que lo
incluye. Este tipo de relacin es comnmente llamada Agregacin
(el objeto base utiliza al incluido para su funcionamiento). Algunos
autores llaman tambin a esta forma de agregacin compartida
porque es posible que un objeto parte o contenido corresponda a
ms de un objeto todo o contenedor Por ejemplo:
Esta forma de graficar la agregacin es opcional. No es obligatorio
determinar el tipo de agregacin sobre todo durante el modelado
de requerimientos o anlisis, pero es til comprender el significado
de ambas y es ms til determinar concretamente el tipo de
agregacin en la actividad de diseo.

32

Dependencia:

Este tipo de relacin se define en el libro de UML como una relacin de

uso que declara que un cambio en la especificacin de un elemento puede
afectar a otro elemento que la utiliza, esto representa la dependencia que
tiene una clase de otra. (Booch, Rumbaugh y Jacobson, 1999)
Generalmente las dependencias se utilizan para indicar que una clase
utiliza a otra como argumento en la signatura de una operacin, esto
significa que la clase dependiente obtiene visibilidad de la otra clase
porque recibe un objeto como parmetro de alguna operacin. Esto es
claramente una relacin de uso: si la clase utilizada cambia, la operacin de
la otra clase puede verse tambin afectada, porque la clase utilizada puede
presentar ahora una interfaz o comportamientos diferentes.
Grficamente estas relaciones se representan con una lnea discontinua
dirigida hacia la clase de la cual se depende, como se muestra a
continuacin:

La dependencia se utiliza para representar la visibilidad de parmetro. En

nuestro ejemplo CondicionPago se hace visible para Cuota porque un
objeto de esta ltima clase recibir como parmetro de entrada para su
operacin calcularRecargo, un objeto de la clase CondicionPago.

DIAGRAMA DE CLASES
Los diagramas de clases son los ms utilizados en el modelado de sistemas
orientados a objetos. Un diagrama de clases muestra un conjunto de clases
as como sus relaciones.
Los diagramas de clases se utilizan para modelar la vista de diseo esttica
de un sistema (ver el punto 2.1 Vistas de UML en este mismo mdulo).
Principalmente esto incluye modelar el vocabulario del sistema. Un

33

diagrama de clases se puede utilizar para modelar las clases lgicas, que
son tpicamente la clase de cosas de las que habla la gente de negocios de
una organizacin (los usuarios). En este caso se usa el diagrama de clases
para modelar el dominio del problema pero tambin se utiliza el
diagrama de clases para mostrar las clases de implementacin, que son las
cosas con las que trabajan los programadores. Este enfoque se aplica a
partir de la actividad de Diseo de un sistema.
En un diagrama de clases podemos encontrar:
Clases
Relaciones: herencia,
dependencia.

asociacin

(su

variante:

agregacin),

Indicadores de multiplicidad y navegabilidad

Nombre de Rol
En este diagrama podemos representar las clases indicando slo su nombre
(en este caso sera un diagrama abreviado) o mostrando tambin los
atributos y/o operaciones.
A continuacin se muestra un fragmento de un diagrama de clases uniendo
algunos de los ejemplos individuales ya vistos:

Simbologa del Diagrama de Clases

En el grfico que figura a continuacin, se resumen todos los elementos

que pueden estar presentes en un diagrama de clases:

34

1.4- Metodologas
estructuradas vs.
Metodologas
Orientadas a Objetos
El tema del carcter del software es tratado por Grady Booch entre otros
autores, al explicar que la complejidad innata del software se deriva de:

35

La complejidad del dominio del problema.

La dificultad de gestionar el proceso de desarrollo.

La flexibilidad que se puede alcanzar a travs del software.

Los problemas de caracterizar el comportamiento de sistemas

discretos.

La tcnica para dominar la complejidad de un sistema es descomponerlo

en partes ms y ms pequeas, cada una de las cuales se puede refinar en
forma independiente. Tenemos dos formas de descomponer un sistema
complejo:

Descomposicin algortmica: Es la forma de descomposicin

sustentada por el anlisis y diseo estructurado. En este caso se
divide el sistema en elementos funcionales relacionados
estructuralmente entre s. Esta visin enfatiza el orden de los
eventos.

Descomposicin orientada a objetos: En este caso la

descomposicin consiste en determinar un conjunto de agentes
autnomos (objetos) que colaboran para llevar a cabo algn
comportamiento de nivel superior. Esta visin resalta los agentes
que causan acciones o son sujetos de estas acciones.

En el libro Lenguaje Unificado de Modelado (ver bibliografa) se plantea

que una de las debilidades de las tcnicas de anlisis y diseo estructurado
es el hecho de que hay una desconexin bsica entre el modelo de anlisis
y el modelo de diseo del sistema; no poder salvar este abismo genera que
el sistema concebido y el sistema construido difieran a medida que
transcurre el tiempo. En los sistemas orientados a objetos, es posible
conectar todas las vistas casi independientes de un sistema en un todo
semntico.
Los mtodos de diseo estructurado surgieron para guiar a los
desarrolladores que intentaban construir sistemas complejos utilizando los
algoritmos como bloques fundamentales para su construccin. El diseo
estructurado tiene un enfoque descendente: la unidad fundamental de
descomposicin es el subprograma y se va modelando en forma de un
rbol de modo que cada subprograma realiza su funcin llamando a otros
subprogramas.
Por otro lado, el diseo estructurado no contempla los problemas de
abstraccin de datos y ocultacin de informacin, tampoco responde bien
al cambio de tamao cuando se aplica a sistemas muy complejos.

36

Los mtodos de diseo orientado a objetos surgieron para ayudar a los

desarrolladores a aprovechar la potencialidad de la programacin
orientada a objetos que utiliza las clases y objetos como bloques bsicos de
construccin. La descomposicin orientada a objetos produce sistemas
ms pequeos a travs de la reutilizacin de mecanismos comunes; a su
vez los sistemas orientados a objetos son tambin ms resistentes al
cambio y por lo tanto estn mejor preparados para evolucionar en el
tiempo ya que su diseo est basado en formas intermedias estables.

2.1- Vistas de UML

Qu es UML?
Como lo presentan sus creadores, Grady Booch, James Rumbaugh e Ivar
Jacobson, el Lenguaje Unificado de Modelado (Unified Modeling Languaje,
UML) es un lenguaje estndar para escribir planos de software. UML
puede utilizarse para visualizar, especificar, construir y documentar los
artefactos de un sistema que involucra una gran cantidad de software.
UML, como lo establecen sus autores, es apropiado para modelar desde
sistemas de informacin en empresas hasta aplicaciones distribuidas
basadas en la Web.
UML, es slo un lenguaje (no es una metodologa) y, por lo tanto, es slo
una parte de un mtodo de desarrollo de software; fue diseado de forma
independiente del modelo de proceso de software a aplicar, aunque para
utilizarlo ptimamente, sus autores aconsejan utilizar un proceso que sea:
dirigido por los casos de uso, centrado en la arquitectura, iterativo e
incremental.
Cuando decimos que UML es un lenguaje nos referimos a que un lenguaje
proporciona un vocabulario y las reglas para combinar palabras de ese
vocabulario con el objetivo de posibilitar la comunicacin. Un lenguaje de
modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representacin conceptual y fsica de un sistema. El modelado proporciona
una comprensin de un sistema. Nunca es suficiente con un nico modelo,
a menudo se necesitan mltiples modelos conectados entre s. El
vocabulario y las reglas de UML indican cmo crear y leer modelos bien
formados, pero no dicen qu modelos se deben crear ni cundo se
deberan crear. sta es la tarea del proceso de desarrollo de software. Un

37

proceso bien definido guiar a los desarrolladores a decidir qu artefactos

producir, qu actividades y qu personal se emplea para crearlos y
gestionarlos.
UML es un lenguaje que permite:

Visualizar: Un modelo explcito facilita la comunicacin. Algunas

cosas se modelan mejor textualmente, otras se modelan mejor de
forma grfica. En todos los sistemas hay estructuras que
trascienden lo que puede ser representado en un lenguaje de
programacin. UML es uno de estos lenguajes grficos, es algo ms
que un conjunto de smbolos grficos. Detrs de cada smbolo en la
notacin UML hay una semntica bien definida. As, un
desarrollador puede construir un modelo en UML y otro
desarrollador o incluso otra herramienta, puede interpretar ese
modelo sin ambigedad.

Especificar: En este contexto especificar significa construir modelos

precisos, no ambiguos y completos. UML cubre la especificacin de
todas las decisiones de anlisis, diseo e implementacin que
deben realizarse al desarrollar y desplegar un sistema con gran
cantidad de software.

Construir: UML no es un lenguaje de programacin visual, pero sus

modelos pueden conectarse de forma directa a una gran variedad
de lenguajes de programacin. Esto significa que es posible hacer
correspondencias desde un modelo UML a un lenguaje de
programacin como Java, C++ o Visual Basic, incluso a tablas en una
base de datos relacional o al almacenamiento persistente de una
base de datos orientada a objetos. Esta correspondencia permite
ingeniera directa: la generacin de cdigo a partir de un modelo
UML en un lenguaje de programacin.

Documentar: Una organizacin de software que trabaje bien

produce toda clase de artefactos adems de cdigo ejecutable.
Estos artefactos incluyen, entre otros: requisitos, arquitectura,
diseo, cdigo fuente, planificacin de proyectos, pruebas,
prototipos, versiones. Artefacto es un trmino general para
cualquier tipo de informacin creada, cambiada o utilizada por los
trabajadores en el desarrollo del sistema.

38

Principales elementos del lenguaje

Los tres elementos principales de UML son: los bloques bsicos de
construccin de UML, las reglas que dictan cmo pueden combinarse esos
bloques y algunos mecanismos comunes que se aplican a lo largo del
lenguaje.
En los siguientes cuadros se resumen los elementos principales de UML.

Los elementos estructurales, en su mayora, son las partes estticas de un

modelo y representan cosas que son conceptuales o materiales:

39

40

Los elementos de comportamiento son las partes dinmicas de los

modelos UML, representan comportamiento en el tiempo y el espacio:

Los elementos de agrupacin, son las partes organizativas de los modelos

UML, representan las cajas en las que puede descomponerse un modelo.
Hay un elemento de agrupacin principal: los paquetes, que representan
un mecanismo de propsito general para organizar elementos en grupos.
Un paquete es puramente conceptual, slo existe en tiempo de desarrollo.
Grficamente se visualiza como una carpeta:

Los elementos de anotacin, son las partes explicativas de los modelos

UML, son comentarios que se pueden aplicar para hacer observaciones
sobre cualquier elemento del modelo. Hay un tipo principal de elemento
de anotacin llamado nota, que se grafica de la siguiente manera:

En el siguiente cuadro se explica brevemente el concepto de cada uno de

los tipos de relaciones en UML:

41

A continuacin se explica brevemente el concepto de cada uno de los tipos

de diagramas en UML:

42

Vistas de un sistema con UML

Cada uno de los involucrados en el proyecto de desarrollo (usuarios finales,
analistas, desarrolladores, integradores de sistemas, encargados de las
pruebas, encargados de la documentacin, jefes de proyecto, entre otros)
realizan diferentes actividades a lo largo del proyecto y cada uno mira al
sistema de formas diferentes.
La arquitectura de un sistema es el artefacto ms importante que se puede
emplear para manejar estos distintos puntos de vista. Tal como se plantea
en el libro de UML, entendemos por arquitectura el conjunto de decisiones
significativas sobre:

La organizacin de un sistema de software.

La seleccin de elementos estructurales y sus interfaces.

Su comportamiento (colaboraciones entre esos elementos).

La composicin de los elementos estructurales

comportamiento en subsistemas cada vez ms grandes.

de

43

El estilo arquitectnico que gua esta organizacin (los elementos

estticos y dinmicos y sus interfaces, colaboraciones y su
composicin).

La arquitectura de un sistema se puede describir a travs de cinco vistas

relacionadas entre s, como se muestra en el siguiente grfico:

Grfico de las vistas 4+1 Fuente: Libro El Lenguaje Unificado de Modelado Grady
Booch y otros (1999), Pg. 27.

44

2.2- El proceso
unificado de desarrollo
Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo.
En la ingeniera de software el objetivo es construir un producto de
software o mejorar uno existente de modo que satisfaga las necesidades
del usuario de forma eficiente y predecible.
Un proceso de desarrollo de software es el conjunto de actividades
necesarias para transformar los requisitos de un usuario en un sistema
software.

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros

(2000), pg.4.

La comunidad de desarrolladores necesita una forma coordinada de

trabajar. Necesita un proceso que integre las mltiples facetas del
desarrollo. Necesita un mtodo comn, un proceso que:

Proporcione una gua para ordenar las actividades de un equipo.

Dirija las tareas de cada desarrollador por separado y del equipo

como un todo.

Especifique los artefactos que deben desarrollarse.

Ofrezca criterios para el control y la medicin de los productos y

actividades del proyecto.

El Proceso Unificado es un proceso de desarrollo de software que utiliza

el Lenguaje Unificado de Modelado (UML) para preparar todos los
esquemas de un sistema de software y fue propuesto por los mismos
creadores de UML: Grady Boock, James Rumbaugh e Ivar Jacobson.
UML, como ya se ha mencionado es bastante independiente del proceso, lo
que significa que se puede utilizar con diferentes procesos de ingeniera de

45

software. El Proceso Unificado es uno de los procesos de desarrollo que se

adapta especialmente bien a UML.
Los aspectos definitorios del Proceso Unificado se resumen en tres frases
claves: est dirigido por casos de uso, centrado en la arquitectura y es un
proceso iterativo e incremental. Estas son las caractersticas esenciales de
este proceso y son los puntos que se desarrollan a continuacin.

2.2.1- Dirigido por caso de uso

Un caso de uso es un fragmento de funcionalidad del sistema que
proporciona al usuario un resultado importante. Los casos de uso
representan los requisitos funcionales del sistema para cada usuario.
Los casos de uso, adems de especificar los requisitos de un sistema, guan
su diseo, implementacin y prueba; es decir, guan el proceso de
desarrollo. Esto es as porque basndose en el modelo de casos de uso, los
desarrolladores crean una serie de modelos de diseo e implementacin
que llevan a cabo los casos de uso. Los ingenieros de prueba prueban la
implementacin para garantizar que se han implementado correctamente
los casos de uso.
De esta manera, los casos de uso adems de iniciar el proceso constituyen
el hilo conductor del mismo. Sin embargo, los casos de uso no se
desarrollan aisladamente, sino a la par de la arquitectura del sistema.

2.2.2- Centrado en la arquitectura

Para comprender mejor el papel que juega la arquitectura en la
construccin de un sistema de software, comparmosla con la arquitectura
en la construccin de una casa. Una casa contempla distintos puntos de
vista: la estructura, los conductos de gas, electricidad, agua, fontanera,
entre otros aspectos. Esto permite al constructor tener una imagen
completa de la casa antes de comenzar la edificacin.
De la misma manera la arquitectura de un sistema de software se describe
mediante distintas vistas, que incluyen los aspectos estticos y dinmicos
ms significativos del sistema. Las distintas vistas y el conjunto de
decisiones significativas que abarca la arquitectura se trataron ya en el
punto Vistas de un Sistema con UML (pg.60). El concepto de
arquitectura software incluye los aspectos estticos y dinmicos ms
significativos del sistema.

46

La arquitectura del sistema surge de las necesidades de la empresa, como

las perciben los usuarios y los inversores, y se refleja en los casos de uso.
Sin embargo, tambin se ve influida por muchos otros factores, como la
plataforma en que tiene que funcionar el software (arquitectura de
hardware, sistema operativo, sistema de gestin de base de datos,
protocolos para comunicacin en red), los bloques de construccin
reutilizables de los que se dispone, consideraciones de implantacin,
sistemas heredados y requisitos no funcionales (por ejemplo, rendimiento,
fiabilidad, seguridad).
Se necesita una arquitectura para:

Comprender el sistema.

Organizar el desarrollo.

Fomentar la reutilizacin.

Hacer evolucionar el sistema.

Si nos preguntamos cmo relacionar los casos de uso con la arquitectura,

debemos recordar que cada producto tiene tanto una funcin como una
forma. Se trata de dos fuerzas que deben estar equilibradas para obtener
un producto con xito. En este contexto la funcin corresponde a los casos
de uso y la forma a la arquitectura. Los casos de uso deben encajar en la
arquitectura cuando se lleven a cabo y, a su vez, la arquitectura debe
permitir el desarrollo de todos los casos de uso requeridos.
Podemos resumir el trabajo de un arquitecto de un sistema (el que
desarrolla la arquitectura), en los siguientes pasos:
1. Crear un esquema en borrador de la arquitectura, comenzando por la
parte que no es especfica de los casos de uso (por ejemplo, la plataforma).
Aunque esta parte de la arquitectura es independiente de los casos de uso,
el arquitecto debe poseer una comprensin general de los casos de uso
antes de comenzar la creacin del esquema arquitectnico.
2. Trabajar con un subconjunto de los casos de uso especificados, aquellos
que representen las funciones clave del sistema. Cada caso de uso se
especifica detalladamente en trminos de subsistemas, clases y
componentes.
3. A medida que se especifican y maduran los casos de uso, se descubre
ms de la arquitectura; esto a su vez lleva a la maduracin de ms casos de
uso.
4. Se debe continuar este proceso hasta que la arquitectura sea estable.

47

2.2.3- Iterativo e Incremental

El desarrollo de un producto de software puede demandar un tiempo
considerable. Es prctico dividir el trabajo en partes ms pequeas o
miniproyectos. Cada miniproyecto es una iteracin que resulta en un
incremento. Las iteraciones se refieren a pasos en el flujo de trabajo y los
incrementos, al crecimiento del producto. Para lograr efectividad, las
iteraciones deben estar controladas, es decir deben seleccionarse y
ejecutarse en forma planificada.
Lo que se implementar en una iteracin se selecciona en base a dos
factores:
1. La iteracin trata un grupo de casos de uso que amplan la
utilidad de lo desarrollado hasta el momento.
2. La iteracin trata los riesgos ms importantes.
En cada iteracin se identifican y especifican los casos de uso relevantes, se
crea un diseo utilizando la arquitectura seleccionada como gua, se
implementa el diseo mediante componentes y se verifica que los
componentes satisfacen los casos de uso (es decir, que en cada iteracin se
hace anlisis, diseo, implementacin y prueba).
Si una iteracin cumple con sus objetivos, se contina con la siguiente; de
lo contrario los desarrolladores deben hacer una revisin y probar nuevos
enfoques.

2.3- Fases dentro de un

ciclo
El Proceso Unificado se repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema. Cada ciclo concluye con una versin del
producto para los clientes.
Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y
transicin. Cada fase a su vez puede tener varias iteraciones:

48

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros

(2000), Pg.8.

Cada ciclo produce una nueva versin del sistema, que es un producto
preparado para su entrega. Consta de cdigo fuente incluido en
componentes que puede compilarse y ejecutarse, manuales y otros
productos asociados. Para llegar a ese producto, debern desarrollarse los
siguientes modelos:

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros

(2000), pg. 9.

49

Fases del Proceso Unificado

Cada ciclo del Proceso Unificado se divide en cuatro fases, cada una de las
cuales puede tener varias iteraciones, como ya vimos. Estas fases son las
siguientes:

Fase de Inicio

Principalmente esta fase responde a las preguntas sobre cules son las
principales funciones del sistema para sus usuarios ms importantes, cmo
podra ser la arquitectura del sistema y cul es el plan del proyecto,
adems de cunto costar desarrollar el sistema.
Se realiza un modelo de casos de uso simplificado, con los ms crticos; la
arquitectura es un esbozo que muestra los principales subsistemas, se
identifican y priorizan los riesgos, se planifica en detalle la fase de
elaboracin y se estima el proyecto.

Fase de elaboracin

Se especifican en detalle la mayora de los casos de uso del producto y se

disea la arquitectura del sistema.
La arquitectura se expresa en forma de vistas de todos los modelos del
sistema (decimos vista de los modelos porque no son los modelos
completos, ya que faltan incorporar casos de uso). Se crea una lnea base
de la arquitectura.

Fase de construccin

Aqu la lnea base de la arquitectura crece hasta convertirse en el sistema

completo, obteniendo as un producto preparado para ser entregado a los
usuarios.

Fase de transicin

En esta fase el producto se convierte en una versin beta. Un nmero

reducido de usuarios, con experiencia, prueba el sistema e informa
defectos y deficiencias.

Los desarrolladores corrigen los problemas e incorporan las mejoras

sugeridas. Esta fase incluye adems las tareas de formacin del
cliente, ayuda en lnea y asistencia.

50

Conceptos bsicos del Proceso

Los trminos que se definen a continuacin se utilizarn a lo largo de todo
el desarrollo del proceso unificado.

Flujo de Trabajo (Workflow)

Es un conjunto de actividades. Un flujo de trabajo determina cmo fluye el

trabajo de un trabajador a otro. Para ello se ha identificado primero qu
tipos de trabajadores participan en el proceso. Luego se identifica qu
artefactos se necesitan crear durante el proceso por cada tipo de
trabajador. Entonces se puede describir cmo fluye el proceso a travs de
los distintos trabajadores y cmo ellos crean, producen y utilizan los
artefactos de los dems.
Un ejemplo de un flujo de trabajo es el flujo de trabajo de los requisitos.
Incluye a los siguientes trabajadores: analista de sistemas, arquitecto,
especificador de casos de uso y diseador de interfaz del usuario. Se
producen los siguientes artefactos: modelos de casos de uso, prototipo de
interfaz, modelo del dominio, entre otros.

Artefacto

Es un trmino general para cualquier tipo de informacin creada,

producida, cambiada o utilizada por los trabajadores en el desarrollo del
sistema. Por ejemplo, los diagramas UML y su texto asociado, los bocetos
de la interfaz del usuario, componentes de cdigo fuente, componentes
ejecutables, entre otros.

Trabajador

Se denomina as a los puestos de trabajo a los cuales se pueden asignar

personas dentro del proyecto.
Un tipo de trabajador es un papel que una persona puede desempear en
el desarrollo de software. Puede ser un especificador de casos de uso, un
arquitecto, un ingeniero de componentes, un ingeniero de pruebas, por
mencionar algunos. Cada trabajador es responsable de un conjunto
completo de actividades y de producir un nmero determinado de
artefactos.
51

Actividades

Son trabajos significativos para una persona que acta como trabajador.

Flujos de trabajo fundamentales

En cada una de las iteraciones del ciclo de vida del Proceso Unificado se
recorre cada uno de los flujos de trabajo fundamentales que son:

Requisitos

Anlisis

Diseo

Implementacin

Prueba

Sobre estos flujos de trabajo, las actividades que se realizan en ellos, los
trabajadores que intervienen y los artefactos que se producen, tratan las
unidades que siguen.
En la figura que se muestra a continuacin se visualiza cmo se combinan
los flujos de trabajos por cada iteracin en cada una de las fases.

52

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros

(2000), pg. 11.

53

Bibliografa

Bell Donald, UML BasicsPart III: TheClassDiagram, artculo publicado en

el sitio IBM Rational en Noviembre/2003.

Booch Grady, Anlisis y diseo orientado a objetos, con aplicaciones,

EE.UU, Editorial Addison-Wesley Iberoamericana S.A., (1996).
Captulos: 1, 2, 3

Booch Grady, Rumbaugh James, Jacobson Ivar, (1999), El lenguaje de

Modelado Unificado, Espaa, Editorial Addison Wesley Iberoamericana.
Captulos: 1, 2, 4, 5, 8

Evans Gary, GettingfromUse.CasetocodePart 1: Use Case Analysis,

artculo publicado en el sitio IBM Rational en Julio/2004.

Jacobson Ivar, Booch Grady, Rumbaugh James, (2000), El Proceso

Unificado de Desarrollo de Software, Espaa, Editorial Addison Wesley.
Captulos: 1, 3, 4, 5

Piattini Mario, Calvo-Manzano, Cervera, Fernndez, (2004), Anlisis y

Diseo de aplicaciones informticas de gestin. Una perspectiva de
Ingeniera de Software, Alfaomega Grupo Editor.
Captulo: 4

Pressman Roger, (2006), Ingeniera de Software. Un enfoque prctico

6ta. edicin, Ed. McGraw Hill

www.uesiglo21.edu.ar

54