CICLO DE GRADO SUPERIOR INFRMATICA

DESARROLLO DE APLICACIONES MULTIPLATAFORMA

MDULO ENTORNOS DE
DESARROLLO

TEMA 4
CICLO DE VIDA DEL SOFTWARE

ENTORNOS DE DESARROLLO

Autor :Javier Tamargo Rodrguez

Este documento se publica bajo licencia Creative Commons No se permite
un uso comercial de la obra original ni de las posibles obras derivadas, la
distribucin de las cuales se debe hacer con una licencia igual a la que
regula la obra original.

ENTORNOS DE DESARROLLO

1. CICLO DE VIDADEL SOFTWARE

1.1. Concepto
Se define por ciclo de vida del software a las distintas fases por las que pasa una
aplicacin software a lo largo del tiempo, desde la fase de estudio y concepcin
hasta la de realizacin, explotacin y mantenimiento. El Ciclo de vida define tambin el
modo en que esas fases se organizan entre s.
Diversas organizaciones profesionales (IEEE o ISO/IEC) han publicado estudios
relativos al ciclo de vida del software y el desarrollo de procesos. La norma IEEE 1074
y la norma ISO 12207-1.
Ambas normas dividen el proceso software en actividades, consideran una actividad
como un conjunto de tareas y una tarea como una accin que transforma entradas en
salidas.
El ciclo de vida abarca, toda la vida del sistema desde su concepcin hasta que
deja de utilizarse, por eso, a veces, se habla de ciclo de desarrollo como el
subconjunto del anterior que empieza en el anlisis y finaliza con la entrega del
sistema al usuario.

1.2. Procesos del ciclo de vida software en iso/iec tr 15504-2

A modo de ejemplo, vamos a ver una de las dos normas anteriores, en concreto una
extensin de la ISO 12207 1 que es la ISO/IEC TR 15594-2.
La norma establece las actividades a realizar durante el ciclo de vida software,
agrupadas en procesos segn la figura, indicando que la norma no fomenta ni
especfica ningn modelo concreto de ciclo de vida, gestin de software o
mtodo de ingeniera ni establece cmo realizar ninguna de las actividades.
Dichas actividades se agrupan en grupos de procesos principales, procesos de
soporte y cuatro procesos de la organizacin.
A continuacin se analizan cada uno de estos procesos para posteriormente resumir
los principales modelos de ciclo de vida.

ENTORNOS DE DESARROLLO

Ilustracin 10: Fases ISO TR 15504-2

1.2.1. PROCESOS PRINCIPALES

Son aquellos que resultan tiles a las personas que inician o realizan el desarrollo,
la explotacin o el mantenimiento del software durante su ciclo de vida.
A) PROCESOS CLIENTE-SUMINISTRADOR
1) Proceso de Adquisicin Son las actividades y tareas que el comprador,
cliente o usuario realiza para adquirir un sistema, un producto o un servicio
software:
Establecer necesidades y objetivos de la adquisicin
Seleccin del suministrador: Quin o qu empresa de informtica
va a suministrarme el producto que necesito?
Control de las actividades del suministrador.
Aceptacin del producto entregado por el suministrador.
2)Proceso de Suministro Son las actividades y tareas que el
suministrador realiza. El propsito es proporcionar al cliente un producto

ENTORNOS DE DESARROLLO

que cumpla con los requisitos acordados.

3) Obtencin o educcin de requisitos Reunir, procesar y seguir la evolucin de

las necesidades y requisitos del cliente a lo largo de la vida del producto.
4) Proceso de Explotacin Desarrollo de los planes del proyecto. Puesta en
marcha de la aplicacin en el entorno del cliente y entrega del producto al
comprador

B) PROCESOS DE INGENIERA

Tradicionalmente, el proceso de desarrollo se ha distribuido por fases como indica la

Figura
En el estndar actualmente. El proceso de desarrollo tradicional desglosa sus fases
en actividades, siendo las ms principales las siguientes:
DESARROLLO:
1) Anlisis: una aplicacin siempre se crea para dar solucin a un problema, pero no
todos los problemas que se plantean al ser humano se pueden informatizar; para
determinar si es posible o no, lo primero que hay que hacer es analizar el problema.
Esto implica determinar cules son las exigencias del problema y estudiar si dicho
problema se puede resolver poniendo en prctica las tcnicas y conocimientos usados
por la ingeniera del software.
En caso de que se considere viable se realizar un anlisis exhaustivo del problema,
fruto del cual se obtendr documentacin, donde se especificarn los requisitos que el
proyecto debe tener. Al documento generado se le denomina especificacin de
requisitos software -> ERS, y en l quedar escrito qu tiene que hacer el programa
que se va a desarrollar, tanto en lo referido al comportamiento interno como al externo.

ENTORNOS DE DESARROLLO

ERS: es un contrato entre la empresa desarrolladora y la empresa cliente. Ambas

partes deben comunicarse estrechamente para establecer los requisitos de la
aplicacin. Una buena ERS ayudar a la empresa cliente a describir qu es lo que
quiere, y a la empresa desarrolladora le servir para comprender exactamente lo que le
estn pidiendo; por lo tanto, de una buena ERS que describa todo detalladamente
depende el resultado final del producto.

Para obtener toda esta informacin el desarrollador deber realizar al cliente

preguntas como:
o Qu debe hacer el programa? A lo que el cliente debe responder para
qu necesita la aplicacin, qu tareas quiere que desempee la
aplicacin, etc.
o Qu datos de entrada y de salida intervendrn en el proceso?
o Es necesario archivar los
almacenamiento secundario?

resultados

en

algn

dispositivo

de

o En qu mquina o sistema operativo se va a ejecutar la operacin?

o La aplicacin estar conectada en red?
o Quin ser el usuario de la aplicacin?
o Quin va a garantizar la seguridad de los datos?
o Cul ser la vida til de la aplicacin? Podr sufrir modificaciones en el
futuro?
2) Diseo: una vez que los requisitos del programa han sido establecidos ya se puede
iniciar la fase de diseo. En esta fase ya se tiene que encontrar una solucin
informtica al problema planteado, y dicha solucin determinar cmo se va a resolver
el problema.

ENTORNOS DE DESARROLLO

Por lo general, no es fcil encontrar una solucin ptima, y menos an si se trata de

una aplicacin de gran envergadura. Cuando est claro lo que se quiere hacer, se debe
hacer un diseo modular, que consiste en que, una vez dado el problema a resolver lo
primero es estudiar la posibilidad de dividirlo en otros ms pequeos, llamados
subproblemas, de manera que cada uno de stos puedan tratarse de forma aislada.
A cada uno de los subproblemas se le considera parte o mdulo del problema global, y
cada uno de ellos se resolver por medio de un programa o subprograma. Todos estos
mdulos implementados ser necesario relacionarlos entre si, ya que generalmente el
comportamiento de uno afectar a una parte del resto.
3) Codificacin: una vez que los algoritmos de una aplicacin se han diseado, se
inicia la fase de codificacin. En esta etapa ser necesario traducir los algoritmos a un
lenguaje de programacin especfico: pasaremos cada accin del algoritmo a
instrucciones de un programa.
Para codificar un algoritmo hay que conocer la sintaxis del lenguaje de
programacin al que tengamos que traducir, sin embargo, independientemente del
lenguaje de programacin, ser el algoritmo el que determine su lgica, por ello es muy
importante que el diseo del algoritmo est claro.
4) Pruebas: cuando se ha obtenido el cdigo ejecutable de un programa hay que
comprobar exhaustivamente su funcionalidad, y para ello se tiene que ejecutar tantas
veces como se considere necesario, proporcionndole cada vez datos de entrada
diferentes y comprobando que los datos de salida son slo los esperados.
El cdigo ejecutable de un programa es imposible que tenga errores de
sintaxis, ya que stos habrn sido detectados por el compilador y corregidos por el
programador. Por ello, las pruebas se deben centrar en la bsqueda de errores de
ejecucin.
Para estar seguros del buen funcionamiento de un programa se debera probar con
todas las combinaciones posibles de entrada, lo que sera imposible porque estas
pruebas seran infinitas. Por ello, las pruebas deben ser bien elegidas, intentando
abarcar el mayor nmero de casos y poniendo a prueba el programa en aspectos
crticos. Adems, en todos los programas pueden darse situaciones inesperadas o no
previstas por el programador; en estos casos el programa reaccionar de manera
imprevisible.
El tiempo en el que se realizan las pruebas depende del tamao de la aplicacin.
Una vez probado el programa, para corregir los errores de ejecucin o de lgica
encontrados, casi siempre hay que modificar el algoritmo y en algunos casos incluso
hay que volver a analizar el problema volviendo a pasar por todas las fases de
desarrollo. De aqu se deduce que el anlisis y el diseo de una aplicacin deben
realizarse con el mximo detalle para no encontrar errores en la fase de prueba.
MANTENIMIENTO:
Se puede realizar bsicamente en 2 sentidos: reparacin o modificacin.
Una vez implementada la aplicacin, todava pueden producirse errores no detectados
en las fases anteriores, los cuales implicarn efectuar reparaciones. Por otra parte,
puede ser que la aplicacin se quiera ampliar o cambiar alguna funcionalidad, lo que
conllevar a realizar modificaciones.

ENTORNOS DE DESARROLLO

En un programa pequeo, las modificaciones o reparaciones pueden ser fciles de

realizar, sin embargo, en aplicaciones grandes, una pequea modificacin o reparacin
puede resultar muy costosa, adems hay que tener en cuenta que aunque el software
nunca se estropea, s se puede deteriorar debido a los cambios, tanto es as que en
algunos casos es preferible comenzar de cero toda la aplicacin, con lo que el software
obsoleto finalizara su ciclo de vida.

1.2.2. PROCESOS DE SOPORTE

Son procesos de apoyo al resto de los procesos (incluidos los mismos de soporte) y se
aplican en cualquier punto del ciclo de vida del software. Son los siguientes:
1) Proceso de Documentacin
Registra la informacin producida por un proceso o actividad del ciclo de vida. El
proceso permite planificar, disear, desarrollar, producir, editar, distribuir, y mantener los
documentos necesarios para todas las personas involucradas en el software.
2) Proceso de Gestin de la Configuracin
Aplica procedimientos administrativos y tcnicos durante todo el ciclo de vida del
sistema para:

identificar, definir y establecer la lnea base de los elementos de configuracin

del software del sistema.

Controlar las modificaciones y las versiones de los elementos.

Registrar el estado de los elementos y las peticiones de modificacin.

Asegurar la complexin, la consistencia y la correccin de los elementos.

Controlar el almacenamiento, la manipulacin y la entrega de lo

elementos.
3) Proceso de Aseguramiento de la Calidad
Garantiza que los procesos y los productos software del ciclo de vida cumplen los
requisitos especificados y cumplen con los planes establecidos.
4) Proceso de Verificacin
Se realiza por fases. Inicialmente por ejemplo, comprueba si los requisitos de un sistema
o del software estn completos y son correctos. Posteriormente comprueba si los
productos software de cada fase del ciclo de vida cumplen los requisitos impuestos
sobre ellos, si el diseo es consistente con el anlisis, si el cdigo lo es respecto al
diseo, etc.
5) Proceso de Validacin
Comprueba que el producto es funcional, que se construye el producto correcto.
Comprueba que los requisitos sirven para cubrir las necesidades del usuario. Es un
comprobacin global.

ENTORNOS DE DESARROLLO

6) Proceso de Revisin Conjunta

Revisin con el Cliente para contrastar el progreso frente a los objetivos del
contrato
7) Proceso de Auditora
Permite establecer, de modo independiente, en momentos predeterminados si se han
cumplido los requisitos, los planes y el contrato.
8) Proceso de Resolucin de Problemas
Permite analizar y eliminar los problemas (disconformidades con los requisitos o el
contrato) descubiertos durante el desarrollo, la explotacin, el mantenimiento u otro
proceso.
2.2.3. PROCESOS DE LA ORGANIZACIN
Son los procesos que emplea una organizacin para llevar a cabo funciones tales
como la gestin, la formacin del personal o la mejora del proceso. Suelen llevarse a
cabo en el mbito organizativo, fuera del mbito de proyectos y contratos especficos.
1) Procesos de Gestin
Comprende las actividades y tareas genricas que puede emplear una organizacin
que tenga que gestionar sus procesos:

Control de cualquier otro Proceso

Coordinar
Garantizar la calidad
Gestionar los riesgos, para reducirlos.
2) Procesos de Organizacin

Proceso de Alineamiento de la Organizacin: todos los individuos comparten

una visin comn de los objetivos

Proceso de Mejora: evala, mide, controla y mejora cada proceso del ciclo de
vida.

Proceso de Recursos Humanos: seleccin y contratacin del personal

adecuado para cada tarea.

Proceso de Infraestructura: establece la infraestructura necesaria para cualquier

otro proceso (hardware, software, herramientas, normas, tcnicas e instalaciones
para el desarrollo, la explotacin o el mantenimiento).

Proceso de Reutilizacin: promueve y facilita la reutilizacin de productos

existentes, para no disear uno nuevo ante necesidades ya planteadas y
resueltas con anterioridad.

ENTORNOS DE DESARROLLO

10

2. MODELOS DE CICLO DE VIDA P ARA DESARROL LO

ESTRUCTURADO
Para desarrollar el ciclo de vida se han propuesto distintos modelos de desarrollo, tanto
para sistemas convencionales como para sistemas orientados al objeto. En el primer
caso se considera el modelo en cascada o Waterfall propuesto por Royce (1970) y
refinado por distintos autores (Boehm (1981), Sommerville (1985), Sigwart (1990),
etc.). El modelo incremental (Lehman (1984) y Amescua (1995) y el modelo en espiral
(Boehm (1988)). Por su parte, para sistemas orientados al objeto se considera el
modelo de agrupamiento o cluster (Meyer (1990)), el modelo fuente (Henderson,
Sellers y Edwards (1990), el modelo remolino (Rumbaugh (1992)) y el modelo pinball
(Ambler (1994).
A continuacin se hace una somera descripcin de algunos modelos.
2.1. Modelo en Cascada o Tradicional
El modelo consta de un nmero variable de fases o etapas que se proponen para el
ciclo de vida del sistema pero que generalmente suelen ser las indicadas en la figura. El
inicio de cada etapa debe esperar a la finalizacin de la anterior.

Las caractersticas del ciclo segn este modelo son:

Cada fase empieza cuando ha terminado la fase anterior.

Para pasar de una fase a otra es preciso conseguir todos los objetivos de
la etapa previa

Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes

esperados.

ENTORNOS DE DESARROLLO

11

Al final de cada fase, el personal tcnico y el usuario tienen la oportunidad de

revisar el progreso del proyecto.

Aunque es el ciclo de vida ms antiguo y el ms utilizado, tiene los siguientes

inconvenientes:

No refleja el proceso real de desarrollo del software. (Los proyectos reales

raramente tienen un flujo secuencial dado que siempre hay iteraciones que
pueden cubrir ms de una etapa.

Se tarda mucho tiempo en recorrer todo el ciclo, dado que hasta que no se
finaliza una fase no se pasa a la siguiente, por lo que el usuario debe esperar
hasta el final del proyecto para ver si el producto se ajusta o no a lo solicitado.

2.2. Modelo Incremental

Corrige la necesidad de una secuencia no lineal de pasos de desarrollo. Segn dicho
modelo, se va creando el sistema software aadiendo componentes funcionales al
sistema (llamados incrementos). En cada paso sucesivo se actualiza el sistema con
nuevas funcionalidades o requisitos (esto es, cada versin o refinamiento parte de
una versin previa a la que le aade nuevas funciones).
Es un modelo que se ajusta a entornos de alta incertidumbre, por no poseer un
conjunto exhaustivo de requisitos, especificaciones, diseos, etc., al comenzar el
sistema, amplindose stos en cada refinamiento.
Representa una mejora sobre el modelo en cascada y, aunque permite el cambio
continuo de requisitos, no se puede determinar si los requisitos propuestos son vlidos,
por lo que los errores de detectan tarde y su correccin resulta muy costosa.

Un ejemplo de modelo en cascada utilizando el desarrollo incremental es el de la figura:

ENTORNOS DE DESARROLLO

12

2.3. Modelo en Espiral

El modelo en espiral consta de una serie de ciclos. Cada uno empieza identificando
los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las
alternativas respecto de los objetivos del ciclo y considerando las restricciones, se
realiza el ciclo correspondiente para, una vez finalizado, iniciar el siguiente ciclo.
Cada ciclo en espiral comienza con los siguientes pasos:

Los Objetivos de la parte del producto que est siendo elaborado.

Las Alternativas principales de la implementacin de esa porcin del

producto.

Las Restricciones para cada alternativa.

El siguiente paso es

Evaluacin de las diferentes Alternativas teniendo en cuenta los objetivos

a conseguir y las restricciones impuestas.

Si existen riesgos, formulacin, de una estrategia efectiva para resolver

o minimizar dichos riesgos (hacer prototipos, simulacin, hacer informes
de anlisis de riesgos, ...)
Revisin de los resultados del anlisis de riesgos

Implementacin de la fase en s del ciclo (anloga a las vistas en el

modelo tradicional e incremental en cada vuelta de la espiral). En la primera
vuelta, Concepto de operacin, en la segunda, Requisitos y Validacin de
los mismos, etc,...
Planificacin de la fase posterior

Ilustracin 11: Ciclo en Espiral

Realizado el primer ciclo se volvera a empezar.

ENTORNOS DE DESARROLLO

13

En el modelo en espiral, cada ciclo se completa con una revisin en la que participan
las principales personas u organizaciones que tienen relacin con el ciclo, que cubre
todos los productos desarrollados en el ciclo anterior e incluye los planes para el
siguiente ciclo y los recursos necesarios para llevarlo a cabo.
Estos planes para las sucesivas fases pueden incluir una particin del producto en
incrementos (para desarrollos sucesivos) o en componentes (para ser desarrollados
por organizaciones individuales o por personas). En este ltimo caso pueden
preverse una serie de ciclos en paralelo, uno por cada componente, aadiendo una
tercera dimensin al modelo en espiral
Las principales diferencias entre el modelo en espiral y los modelos
anteriores son:

Existencia reconocida de diferentes alternativas

Identificacin de riesgos para cada alternativa . La resolucin de los riesgos es

realmente el centro del modelo.

Divisin del proyecto en ciclos, cada uno con un acuerdo al final de

cada ciclo. v' El modelo se adapta a cualquier tipo de actividad.

3. MODELOS DE CICLO DE VIDA ORIENTADO A OBJETOS

El objetivo de la Orientacin a Objetos es elaborar un programa o producto software
mediante una serie de operaciones iterativas que se encaminan a:
1. Comprender la realidad del problema que se quiere resolver, qu parte de ese
problema ser resuelta por el producto. Ser preciso descomponer el
problema en subproblemas ms sencillos, con objeto de facilitar su
comprensin.
2. Buscar soluciones a los subproblemas parciales.
3. Composicin de las diferentes soluciones parciales que se han encontrado a
los distintos subproblemas en una solucin general.
El mtodo clsico consista en identificar las funciones (procesos) principales del
sistema y descomponerlas en subfunciones, hasta llegar a un nivel en el que los
subproblemas son suficientemente pequeos como para ser resueltos por un
lenguaje de programacin, usando variables, secuencias, decisiones, iteraciones y
funciones+procedimientos1. El mtodo clsico asla funciones. De modo que si en el
mundo real cambia alguna de esas funciones, basta retocar esa funcin en el cdigo.
Calcular_nmina es una funcin del programa de gestin del departamento de
recursos humanos de una empresa. Si la legislacin relativa a las retenciones cambia
tras la victoria del PP, basta retocar esa funcin Calcular_nmina para adaptarse a
las nuevas leyes, sin afectar al resto del programa.
El problema del mtodo clsico es que a menudo una variacin en la realidad
representada, supone un cambio ms profundo, que afecta a la estructura funcional
del programa
La orientacin a objetos supone un avance en ste sentido. Acerca la representacin

ENTORNOS DE DESARROLLO

14

informatizada de la realidad a la realidad misma hacindola ms fiel. No se basa

nicamente en lo que hace el sistema, sino tambin en cmo es, cules son sus
caractersticas definitorias.
Todo el modelo orientado a objetos se ajusta a los 3 objetivos que se fijaron en sus
inicios y se basa en 5 elementos:
1.
2.
3.
4.
5.

Objeto
Clase
Mensaje
Herencia
Polimorfismo

El desarrollo orientado a objetos considera a un programa como una coleccin de

agentes autnomos llamados Objetos. Mediante la interaccin de los objetos avanza
la ejecucin del programa.

3.1 Definicin de Objeto

Un objeto es una representacin de un ente del mundo real. Mediante un objeto el
ente queda representado por:
1. El estado del objeto. El estado del objeto queda definido por el valor de una
serie de atributos o propiedades.
2. El comportamiento del objeto. Representa las capacidades del objeto para
actuar, para responder a la interaccin con otros objetos, para operar. Estas
capacidades se incluyen en el objeto con el nombre de mtodos u
operaciones.
Por ejemplo. Para representar un objeto tringulo T, podran incluirse
1. Como valores de estado: longitud del lado1, longitud del lado 2, longitud del
lado3 y valor del ngulo1, 2 y 3. Por ejemplo: 3mm, 3mm y 3mm para los lados
y 60, 60, 60 para un tringulo equiltero particular. Otro atributo puede ser la
posicin sobre la horizontal en grados (ste tringulo puede presentarse
girado). Por ejemplo T podra estar girado en un instante dado 12 sobre la
horizontal.
2. Como comportamiento, podra incluirse el mtodo: girarTringulo(grados). El
mtodo anterior indica que un tringulo puede girarse, mediante la invocacin
del mtodo con un valor del argumento en grados. A esto se le llama tambin
enviar un mensaje al tringulo.
El hecho de representar la realidad mediante objetos, permite aislar unos de otros,
mientras su interfaz externa (mtodos) se mantenga. Cualquier cambio en un objeto
no repercutir en otros objetos. De este modo se facilita la introduccin de cambios y
mejoras en el software. Slo habr que retocar determinados objetos, permaneciendo el
resto inalterados.
En el mundo real, en el caso de un ordenador, por ejemplo, cuando se avera la pantalla,
basta con reemplazarla por otra, no es necesario retocar o modificar el ordenador mismo.

ENTORNOS DE DESARROLLO

15

Se llama encapsulamiento a la combinacin de datos y comportamiento de los

objetos, mientras que, por el contrario, se oculta su implementacin.
As, la forma en que un objeto desempea una tarea concierne slo a dicho objeto y
no a otros objetos aunque interaccionen con ste. El objeto ofrece la misma imagen al
exterior aunque se vare su contenido.
La mayora de la gente ve una televisin sin importarle demasiado como se hace para que
la imagen llegue a l y se muestre en la pantalla. Simplemente hace lo que tiene que
hacer y el cmo lo hace permanece oculto. Nosotros slo vemos y conocemos el interfaz
esto es, los botones del mando a distancia.
3.2 Comunicacin entre objetos: mensajes
El avance de un programa depende de la colaboracin entre los objetos que lo
componen. Es necesario que los objetos se comuniquen.
Denominaremos mensaje hacia un objeto a la llamada o invocacin de un
mtodo de ese objeto desde otro objeto o desde dentro de s mismo.
Un objeto se activa mediante la invocacin de un mtodo propio al recibir un mensaje.
Los mtodos se suelen invocar usando su nombre y, opcionalmente, recibiendo unos
valores concretos llamados argumentos; Ej: girarTringulo(10 grados). Se debe indicar
a quin se enva el mensaje, esto es, a qu objeto concreto.
3.3 Clasificacin
Cada objeto es un ejemplo que pertenece a una clase determinada. Se dice que un
objeto concreto es una instancia de una clase. La clase es una generalizacin del
concepto objeto.
En el ejemplo del tringulo anterior, el objeto tringulo con las medidas concretas
propuestas, sera una instancia de la clase genrica tringulos, a la que pueden
pertenecer mltiples elementos o instancias.
Dos instancias de una misma clase se diferencian entre s por el valor de sus
atributos, esto es, por su estado.
En el lenguaje natural escrito o hablado puede deducirse cul es la clase porque
suele estar precedida por un artculo que determina que se trata de un concepto
genrico aplicable a muchos casos particulares: Ej: los tringulos.
A veces se hace referencia en el lenguaje natural a las clases usando el artculo
indeterminado un(a). En lenguaje matemtico tambin: Sea 't' un tringulo... t es la
instancia y un tringulo es la clase.
En la definicin de una clase se indica qu partes pueden ser vistas por otros objetos
(interfaz del objeto) y cules quedan ocultas y forman parte de la implementacin del
mismo.

La ocultacin de la implementacin contribuye al encapsulamiento.

ENTORNOS DE DESARROLLO

16

3.4 Herencia
Las clase pueden organizarse en un rbol de herencia jerrquico. Las clases que se
encuentran en los niveles bajos del rbol (clases descendientes) pueden tener
asociados atributos (propiedades) y mtodos que ya existen en las clases superiores o
ancestros.
Para dos clases organizadas mediante una relacin de herencia, una de ellas es la
clase padre y la otra, la que hereda propiedades y comportamientos sera la clase
hija.
En el ejemplo del tringulo T, ste pertenece (es un ejemplo o una instancia) de la clase
tringulos, que es una clase hija de la clase padre polgonos.

Ilustracin 3: Ejemplo de relacin de herencia

Ejercicio
Busca un ejemplo en el mundo real de clases y subclases relacionadas por
herencia y represntalos con rectngulos a modo del ejemplo de la Ilustracin
3
Como se ha comentado, la clase hija hereda propiedades y comportamientos de la
clase padre, lo que facilita la reutilizacin de desarrollo anteriores para aplicaciones
completamente nuevas. La clase padre recibe a veces el nombre de superclase y
clase base y la hija el de subclase o clase derivada.
Las subclases aprovechan las caractersticas de sus superclases para construir las
suyas propias. Adems puede definir caractersticas (atributos o mtodos) propias.
Una clase Electrodomstico poseer atributos y mtodos comunes a cada una de
sus clases derivadas. Contar por ejemplo con los atributos interruptor y
cableElectrico. Con los mtodos encender() y apagar(). Todas las clases de
electrodomsticos, por ejemplo, Lavadora, poseern (heredarn) esos atributos y
mtodos. A partir de ah, en Lavadora pueden definirse atributos y mtodos propios
de las lavadoras, aparte de esos comunes. Si los mtodos comunes se redefinen en
la clase derivada, dar lugar al polimorfismo, que se ve en el siguiente punto.
La herencia es mltiple cuando la clase derivada hereda de varias
clases base.

ENTORNOS DE DESARROLLO

17

3.5 Polimorfismo
El polimorfismo consiste en elaborar diferentes operaciones en respuesta
a un mismo mensaje.
Como hemos visto en la herencia, las clases hijas heredan mtodos de sus clase
padre. Un mismo mtodo (con el mismo nombre) existir en las clases padre e hija,
pero su implementacin puede ser diferente.
Supongamos la clase polgonos y su subclase Tringulos. El mtodo girar() se
llamar igual, pero el mecanismo finalmente empleado para girar un tringulo puede
ser distinto al usado para otros polgonos.
Resumiendo:
1. La subclase puede modificar la implementacin de las operaciones
heredadas.
2. En ese caso, el mismo nombre de operacin puede designar
implementaciones distintas.
3. As, objetos de distintas clases pueden tener operaciones con el mismo
nombre, pero con una implementacin diferente, por lo tanto: ante un mismo
mensaje, respondern realizando operaciones diferentes. (El cdigo fuente o
definicin es distinto, pero el nombre de funcin o mtodo es el mismo).
Por poner otros ejemplos: puede abrirse() una puerta, una ventana, un peridico,
un regalo o una cuenta de banco. En cada caso se realiza una operacin diferente.
En la orientacin a objetos cada clase sabr cmo realizar cada operacin segn el
caso. Esto es el polimorfismo.
Las metodologas orientadas a objetos se basan en los lenguajes de modelado de
objetos. El estndar actualmente se denomina UML y ser uno de las cuestiones
que trataremos con detenimiento a lo largo del curso en los prximos temas.
Cuestin: Determina el ciclo de vida a aplicar en los siguientes casos y
razona la respuesta en cada caso:
1. En una empresa para un proyecto donde est muy claro lo que se
quiere implementar
2. Si el cliente es una persona inestable y de carcter voluble, y el
negocio de ese cliente ha sufrido varios ajustes en el ltimo ao
3. Si el Cliente quiere supervisar los avances del proyecto y decidir
sobre la marcha cada nueva implementacin
4. Si el Cliente no tiene conocimientos informticos, lo que hace
complicado que se haga una idea exacta del aspecto, de los
interfaces y de la funcionalidad que tendr el producto.