ut04 ciclodevida software

CICLO DE GRADO SUPERIOR INFRMATICA DESARROLLO DE APLICACIONES MULTIPLATAFORMA

MDULO ENTORNOS DE DESARROLLO

TEMA 4 CICLO DE VIDA DEL SOFTWARE

ENTORNOS DE DESARROLLO 2

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.


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.


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


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.


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 resultados en algn dispositivo de almacenamiento secundario?

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.


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.


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.


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.


2. MODELOS DE CICLO DE VIDA PARA DESARROLLO 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.


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:


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.


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


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. Objeto 2. Clase 3. Mensaje 4. Herencia

5. 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.


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.


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.


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.

ut04 ciclodevida software

Documents