isw-s20-conceptos y principios orientados a objetos

INGENIERÍA DEL SOFTWARE

C A P Í T U L O 3 : I N G E N I E R Í A

D E L S O F T W A R E O R I E N T A D O

A O B J E T O S

I S T P - K H I P U

W I L B E R T D A L G U E R R E

O R D Ó Ñ E Z

2 0 1 3 - I

SESIÓN NÚMERO 20

CONCEPTOS Y PRINCIPIOS

ORIENTADOS A OBJETOS Conocer y utilizar el paradigma Orientado a Objetos.

Conceptos y Principios Orientados a Objetos

1

Contenido

CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS .......................... 2

EL PARADIGMA ORIENTADO A OBJETOS .............................................................................. 3

CONCEPTOS ORIENTADOS A OBJETOS ................................................................................. 4

Clases y objetos .................................................................................................................... 6

Atributos ............................................................................................................................... 6

Operaciones, métodos y servicios ........................................................................................ 7

Mensajes .............................................................................................................................. 8

IDENTIFICACIÓN DE LOS ELEMENTOS DE UN MODELO DE OBJETOS................................. 12

Identificación de clases y objetos ....................................................................................... 12

Especificación de atributos................................................................................................. 16

Definición de operaciones .................................................................................................. 17

Fin de la definición del objeto ............................................................................................ 18

GESTIÓN DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS................................... 19

El marco de proceso común para OO ................................................................................. 20

Métricas y estimación en proyectos orientados a objetos ................................................ 21

Un enfoque OO para estimaciones y planificación ............................................................ 23

Seguimiento del progreso en un proyecto orientado a objetos ........................................ 24

Hito técnico: análisis OO terminado .................................................................................. 24

Hito técnico: diseño O0 terminado .................................................................................... 25

Hito técnico: programación O0 terminada ........................................................................ 25

Hito técnico: prueba OO ..................................................................................................... 25

BIBLIOGRAFÍA ................................................................................................................ 26


2

CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS

Vivimos en un mundo de objetos.

Estos objetos existen en la naturaleza, en

entidades hechas por el hombre, en los

negocios y en los productos que usamos.

Pueden ser clasificados, descritos, organizados,

combinados, manipulados y creados. Por esto no es sorprendente que se proponga una visión orientada a objetos para la creación de software de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi veinte años para llegar a ser ampliamente usadas. Durante los años 90, la ingeniería del software orientada a objetos se convirtió en el paradigma de elección para muchos productores de software y para un creciente número de sistemas de información y profesionales de la ingeniería. A medida que pasa el tiempo, las tecnologías de objetos están sustituyendo a los enfoques clásicos de desarrollo de software. Una pregunta importante es: ¿Por qué? La respuesta (como muchas otras respuestas a interrogantes sobre ingeniería del software) no es sencilla. Algunas personas argumentarían que los profesionales del software sencillamente añoraban un nuevo enfoque, pero esta visión es muy simplista. Las tecnologías de objeto llevan un número de beneficios inherentes que proporcionan ventajas a los niveles de dirección y técnico.

Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componente de software) lleva a un desarrollo de software más rápido y a programas de mejor calidad. El software orientado a objetos es más fácil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca menos frustración en el ingeniero del software y en el cliente. Además, los sistemas orientados a objetos son más fáciles de adaptar y más fácilmente escalables (por ejemplo: pueden crearse grandes sistemas ensamblando subsistemas reutilizables). En este capítulo presentamos los


3

principios y conceptos básicos que forman el fundamento para la comprensión de tecnologías de objetos.

EL PARADIGMA ORIENTADO A OBJETOS

Durante muchos años el término orientado a objetos (00) se usó para referirse a un enfoque de desarrollo de software que usaba uno de los lenguajes orientados a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). Hoy en día el paradigma OO encierra una completa visión de la ingeniería del software. Edward Berard hace notar esto cuando declara: Los beneficios de la tecnología orientada a objetos se fortalecen si se usa antes y durante el proceso de ingeniería del software. Esta tecnología orientada a objetos considerada debe hacer sentir su impacto en todo el proceso de ingeniería del software. Un simple uso de programación orientada a objetos (POO) no brindará los mejores resultados. Los ingenieros del software y sus directores deben considerar tales elementos el análisis de requisitos orientado a objetos (AROO), el diseño orientado a objetos (DOO), el análisis del dominio orientado a objetos (ADOO), sistemas de gestión de bases de dalos orientadas a objetos (SGBDOO) y la ingeniería del software orientada a objetos asistida por computadora (ISOOAC). «¿Cuál es la gran ventaja? Usamos el análisis, diseño, la programación, las pruebas y otras tecnologías relacionadas cuando realizamos ingeniería del software según métodos clásicos. ¿Por qué debe ser la OO diferente?» Ciertamente, ¿por qué debe ser la O0 diferente? En pocas palabras, ¡no debiera!

Se examinó un número de modelos de procesos diferentes para la ingeniería del software. Aunque ninguno de estos modelos pudo ser adaptado para su uso con OO, la mejor selección reconocería que los sistemas OO tienden a evolucionar con el tiempo. Por esto, un modelo


4

evolutivo de proceso acoplado con un enfoque que fomenta el ensamblaje (reutilización) de componentes es el mejor paradigma para ingeniería del software OO. En la Figura anterior el modelo de proceso de ensamblaje de componentes ha sido adaptado a la ingeniería del software OO. El proceso OO se mueve a través de una espiral evolutiva que comienza con la comunicación con el usuario. Es aquí donde se define el dominio del problema y se identifican las clases básicas del problema. La planificación y el análisis de riesgos establecen una base para el plan del proyecto OO. El trabajo técnico asociado con la ingeniería del software OO sigue el camino iterativo mostrado en la caja sombreada. La ingeniería del software OO hace hincapié en la reutilización. Por lo tanto, las clases se buscan en una biblioteca (de clases OO existentes) antes de construirse. Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de software aplica análisis orientado a objetos (AOO), diseño orientado a objetos (DOO), programación orientada a objetos (POO) y pruebas orientadas a objetos (PROO) para crear la clase y los objetos derivados de la clase. La nueva clase se pone en la biblioteca de tal manera que pueda ser reutilizada en el futuro. La visión orientada a objetos demanda un enfoque evolutivo de la ingeniería del software. Como veremos más adelante, será extremadamente difícil definir las clases necesarias para un gran sistema o producto en una sola iteración. A medida que el análisis OO y los modelos de diseño evolucionan, se hace patente la necesidad de clases adicionales. Es por esta razón por lo que el paradigma arriba descrito funciona mejor para la OO.

CONCEPTOS ORIENTADOS A OBJETOS

Cualquier discusión sobre ingeniería del software

orientada a objetos debe comenzar por el término

orientado a objetos. ¿Qué es un punto de vista

orientado a objetos? ¿Qué hace que un método sea

considerado como orientado a objetos? ¿Qué es un objeto?

Durante años han existido muchas opiniones diferentes sobre las respuestas correctas a estas preguntas. En los párrafos siguientes trataremos de sintetizar las más comunes de éstas. Para entender la visión orientada a objetos, consideremos un ejemplo de un objeto del mundo real -la cosa sobre la que usted está sentado ahora mismo-, una silla.


5

Silla es un miembro (el término instancia también se usa) de una clase mucho más grande de objetos que llamaremos Mobiliario. Un conjunto de atributos genéricos puede asociarse con cada objeto, en la clase Mobiliario. Por ejemplo, todo mueble tiene un costo, dimensiones, peso, localización y color, entre otros muchos posibles atributos. Estos son aplicables a cualquier elemento sobre el que se hable, una mesa o silla, un sofá o un armario. Como Silla es un miembro de la clase Mobiliario, hereda todos los atributos definidos para dicha clase. Este concepto se ilustra utilizando una notación conocida como UML. Una vez definida la clase, los atributos pueden reutilizarse al crear nuevas instancias de la clase. Por ejemplo, supongamos que debemos definir un nuevo objeto llamado Sillesa (un cruce entre una silla y una mesa) que es un miembro de la clase Mobiliario. La Sillesa hereda todos los atributos de Mobiliario. Hemos intentado definir una clase describiendo sus atributos, pero algo falta. Todo objeto en la clase mobiliario puede manipularse de varias maneras. Puede comprarse y venderse, modificarse físicamente (por ejemplo, usted puede eliminar una pata o pintar el objeto de púrpura) o moverse de un lugar a otro. Cada una de estas operaciones (otros términos son servicios o métodos) modificará uno o más atributos del objeto. Por ejemplo, si el atributo localización es un dato compuesto definido como: localización = edificio + piso + habitación entonces una operación denominada mover modificaría uno o más de los elementos dato (edificio, piso o habitación) que conforman el atributo localización. Para hacer esto, mover debe tener «conocimiento» sobre estos elementos. La operación mover puede usarse para una silla o una mesa, debido a que ambas son instancias de la clase Mobiliario. Todas las operaciones válidas (por ejemplo, comprar, vender, pesar) de la clase Mobiliario están «conectadas» a la definición del objeto y son heredadas por todas las instancias de esta clase. El objeto silla (y todos los objetos en general) encapsula datos (los valores de los atributos que definen la silla), operaciones (las acciones que se aplican para cambiar los atributos de la silla), otros objetos (pueden definirse objetos compuestos), constantes (para fijar valores) y otra información relacionada. El encapsulamiento significa que toda esta información se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificación o componente de programa. Ahora que hemos introducido algunos conceptos básicos, resultará más significativa una definición más formal de la «orientación a objetos». Coad y Yourdon definen el término de la siguiente forma: Orientación a objetos = objetos + clasificación + herencia + comunicación


6

Clases y objetos

Los conceptos fundamentales que llevan a un diseño de alta calidad son igualmente aplicables a sistemas desarrollados usando métodos convencionales y orientados a objetos. Por esta razón, un modelo O0 de software de computadora debe exhibir abstracciones de datos y procedimientos que conducen a una modularidad eficaz. Una clase es un concepto O0 que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Las abstracciones de datos (atributos) que describen la clase están encerradas por una «muralla» de abstracciones procedimentales (llamadas operaciones, métodos o servicios) capaces de manipular los datos de alguna manera. La Única forma de alcanzar los atributos (y operar sobre ellos) es ir a través de alguno de los métodos que forman la muralla. Por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los métodos que componen la muralla). Esto posibilita la ocultación de información y reduce el impacto de efectos colaterales asociados a cambios. Como estos métodos tienden a manipular un número limitado de atributos, esto es una alta cohesión, y como la comunicación ocurre sólo a través de los métodos que encierra la «muralla», la clase tiende a un desacoplamiento con otros elementos del sistema. Todas estas características del diseño conducen a software de alta calidad. Puesto de otra manera, una clase es una descripción generalizada (por ejemplo, una plantilla, un patrón o un prototipo) que describe una colección de objetos similares. Por definición, todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulación de los atributos. Una superclase es una colección de clases y una subclase es una instancia de una clase. Estas definiciones implican la existencia de una jerarquía de clases en la cual los atributos y operaciones de la superclase son heredados por subclases que pueden añadir, cada una de ellas, atributos «privados» y métodos.

Atributos

Ya hemos visto que los atributos están asociados a clases y objetos, y que describen la clase o el objeto de alguna manera. Un estudio de los atributos es presentado por de Champeaux y sus colegas: Las entidades de la vida real están a menudo descritas con palabras que indican características estables. La mayoría de los objetos físicos tienen características tales como forma, peso, color y tipo de material. Las personas tienen características como fecha de nacimiento, padres, nombre y color de los ojos. Una característica puede verse como una relación binaria entre una clase y cierto dominio. La «relación» binaria anteriormente señalada implica que un atributo puede tomar un valor definido por un dominio enumerado. En la


7

mayoría de los casos, un dominio es simplemente un conjunto de valores específicos. Por ejemplo, suponga que una clase Coche tiene un atributo color. El dominio de valores de color es (blanco, negro, plata, gris, azul, rojo, amarillo, verde). En situaciones más complejas, el dominio puede ser un conjunto de clases. Continuando el ejemplo, la clase Coche también tiene un atributo motor que abarca los siguientes valores de dominio: (16 válvulas opción económica, 16 válvulas opción deportiva, 24 válvulas opción deportiva, 32 válvulas opción de lujo). Cada una de las opciones indicadas tiene un conjunto de atributos específicos. Las características (valores del dominio) pueden aumentarse asignando un valor por defecto (característica) a un atributo. Por ejemplo, el atributo motor destacado antes, tiene el valor por defecto 16 válvulas opción deportiva. Esto puede ser también útil para asociar una probabilidad con una característica particular a través de pares (valor, probabilidad). Considere el atributo color para Coche. En algunas aplicaciones (por ejemplo, planificación de la producción) puede ser necesario asignar una probabilidad a cada uno de los colores (blanco y negro son más probables como colores de coches).

Operaciones, métodos y servicios

Un objeto encapsula datos (representados como una colección de atributos) y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, métodos o servicios' y pueden ser vistos como módulos en un sentido convencional. Cada una de las operaciones encapsuladas por un objeto proporciona una representación de uno de los comportamientos del objeto. Por ejemplo, la operación DeterminarColor para el objeto Coche extraerá el color almacenado en el atributo color. La consecuencia de la existencia de esta operación es que la clase Coche ha sido diseñada para recibir un estímulo (llamaremos al estímulo mensaje) que requiere el color de una instancia particular de una clase. Cada vez que un objeto recibe un estímulo, éste inicia un cierto comportamiento, que puede ser tan simple como determinar el color del coche o tan complejo como la iniciación de una cadena de estímulos que se pasan entre una variedad de objetos diferentes. En este último caso, considere un ejemplo en el cual el estímulo inicial recibido por el objeto nº 1 da lugar a una generación de otros dos estímulos que se envían al objeto nº 2 y al objeto nº 3. Las operaciones encapsuladas por el segundo y tercer objetos actúan sobre el estímulo devolviendo información necesaria para el primer objeto. El objeto nº 1 usa entonces la información devuelta para satisfacer el comportamiento demandado por el estímulo inicial.


8

Mensajes

Los mensajes son el medio a través del cual interactúan los objetos. Usando la terminología presentada en la sección precedente, un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operación. En la Figura se ilustra esquemáticamente la interacción entre objetos. Una operación dentro de un objeto emisor genera un mensaje de la forma: destino.operación (parámetros) Donde destino define el objeto receptor el cual es estimulado por el mensaje, operación se refiere al método que recibe el mensaje y parámetros proporciona información requerida para el éxito de la operación.

Como un ejemplo de paso de mensajes dentro de un sistema 00, considere los objetos que se muestran en la Figura inferior. Los cuatro objetos. A, B, C y D se comunican unos con otros a través del paso de mensajes. Por ejemplo, si el objeto B requiere el proceso asociado con la operación opl0 del objeto D, el primero enviaría a D un mensaje de la forma: D.op10(datos) Como parte de la ejecución de opl0, el objeto D puede enviar un mensaje al objeto C de la forma: C.op8( datos) C encuentra op8, la ejecuta, y entonces envía un valor de retorno apropiado a D. La operación opl0 completa su ejecución y envía un valor de retorno a B. Cox [COX86] describe el intercambio entre objetos de la siguiente manera: Se solicita de un objeto que ejecute una de sus operaciones enviándole un mensaje que le informa acerca de lo que debe hacer. El [objeto] receptor responde al mensaje eligiendo primero


9

la operación que implementa el nombre del mensaje, ejecutando dicha operación y después devolviendo el control al objeto que origina la llamada. El paso de mensajes mantiene comunicado un sistema orientado a objetos. Los mensajes proporcionan una visión interna del comportamiento de objetos individuales, y del sistema O0 como un todo.

Encapsulamiento, herencia y polimorfismo

Hay tres características de los sistemas orientados a objetos que los hacen únicos. Como ya hemos observado, las clases y los objetos derivados de ella encapsulan los datos y las operaciones que trabajan sobre estos en un único paquete. Esto proporciona un número importante de beneficios:

1. Los detalles de implementación interna de datos y procedimientos están ocultos al mundo exterior (ocultación de la información). Esto reduce la propagación de efectos colaterales cuando ocurren cambios.

2. Las estructuras de datos y las operaciones que las manipulan están mezcladas en una entidad sencilla: la clase. Esto facilita la reutilización de componentes.

3. Las interfaces entre objetos encapsulados están simplificadas. Un objeto que envía un mensaje no tiene que preocuparse de los detalles de las estructuras de datos internas en el objeto receptor, lo que simplifica la interacción y hace que el acoplamiento del sistema tienda a reducirse.


10

La herencia es una de las diferencias clave entre sistemas convencionales y sistemas OO. Una subclase Y hereda todos los atributos y operaciones asociadas con su superclase X. Esto significa que todas las estructuras de datos y algoritmos originalmente diseñados e implementados para X están inmediatamente disponibles para Y (no es necesario más trabajo extra). La reutilización se realiza directamente. Cualquier cambio en los datos u operaciones contenidas dentro de una superclase es heredado inmediatamente por todas las subclases que se derivan de la superclase2. Debido a esto, la jerarquía de clases se convierte en un mecanismo a través del cual los cambios (a altos niveles) pueden propagarse inmediatamente a través de todo el sistema. Es importante destacar que en cada nivel de la jerarquía de clases, pueden añadirse nuevos atributos y operaciones a aquellos que han sido heredados de niveles superiores de la jerarquía. De hecho, cada vez que se debe crear una nueva clase, el ingeniero del software tiene varias opciones:

1. La clase puede diseñarse y construirse de la nada. Esto es, no se usa la herencia.

2. La jerarquía de clases puede ser rastreada para determinar si una clase ascendiente contiene la mayoría de los atributos y operaciones requeridas. La nueva clase hereda de su clase ascendiente, y pueden añadirse otros elementos si hacen falta.

3. La jerarquía de clases puede reestructurarse de tal manera que los atributos y operaciones requeridos puedan ser heredados por la nueva clase.

4. Las características de una clase existente pueden sobrescribirse y se pueden implementar versiones privadas de atributos u operaciones para la nueva clase.

Es importante darse cuenta de que la reestructuración de la jerarquía puede ser difícil y, por esta razón, se usa a veces la anulación. En esencia, la anulación ocurre cuando los atributos y operaciones se heredan de manera normal, pero después son modificados según las necesidades específicas de la nueva clase. Como señala Jacobson, cuando se emplea la anulación, «la herencia no es transitiva». En algunos casos, es tentador heredar algunos atributos y operaciones de una clase y otros de otra clase. Esta acción se llama herencia múltiple y es controvertida. En general, la herencia múltiple complica la jerarquía de clases y crea problemas potenciales en el control de la configuración. Como las secuencias de herencia múltiple son más difíciles de seguir, los cambios en la definición de una clase que reside en la parte superior de la jerarquía pueden tener impactos no deseados originalmente en las clases definidas en zonas inferiores de la arquitectura.


11

El polimorfismo es una característica que reduce en gran medida el esfuerzo necesario para extender un sistema OO. Para entender el polimorfismo, considere una aplicación convencional que debe dibujar cuatro tipos diferentes de gráficos: gráficos de líneas, gráficos de tarta, histogramas y diagramas de Kiviat. Idealmente, una vez que se han recogido los datos necesarios para un tipo particular de gráfico, el gráfico debe dibujarse él mismo. Para realizar esto en una aplicación convencional (y mantener la cohesión entre módulos), sería necesario desarrollar módulos de dibujo para dada tipo de gráfico. Según esto, dentro del diseño para cada tipo de gráfico, se deberá añadir una lógica de control semejante a la siguiente:

case of tipo-grafico:

if tipo-grafico = grafico-linea then

DibujarLinea(datos);

if tipo-grafico = grafico-tarta then

DibujarTarta(dat0s);

if tipo-grafico = grafico-histograma

then DibujarHisto(datos);

if tipo-grafico = grafico-kiviat then

DibujarKiviat(datos);

end case;

Aunque este diseño es razonablemente evidente, añadir nuevos tipos de gráficos puede ser complicado, pues hay que crear un nuevo módulo de dibujo para cada tipo de gráfico y actualizar la lógica de control para cada gráfico. Para resolver este problema, cada uno de los gráficos mencionados anteriormente se convierte en una subclase de una clase general llamada Gráfico. Usando un concepto llamado sobrecarga, cada subclase define una operación llamada dibujar. Un objeto puede enviar un mensaje dibujar a cualquiera de los objetos instanciados de cualquiera de las subclases. El objeto que recibe el mensaje invocará su propia operación dibujar para crear el gráfico apropiado. Por esto, el diseño mostrado anteriormente se reduce a: tipo-grafico dibujar Cuando hay que añadir un nuevo tipo de gráfico al sistema, se crea una subclase con su propia operación


12

IDENTIFICACIÓN DE LOS ELEMENTOS DE UN MODELO DE OBJETOS

Los elementos de un modelo de objetos “clases y

objetos, atributos, operaciones y

mensajes” fueron definidos y examinados

en la sección precedente. Pero, ¿cómo

podemos hacer para identificar estos elementos

en un problema real? Las secciones que siguen

presentan una serie de directrices informales que nos ayudarán en la identificación de los elementos de un modelo de objetos.

Identificación de clases y objetos

Si usted observa a su alrededor en una habitación, existen un conjunto de objetos físicos que pueden ser fácilmente identificados, clasificados y definidos (en términos de atributos y operaciones). Pero cuando usted «observa» el espacio de un problema en una aplicación de software, los objetos pueden ser más difíciles de identificar. Podemos empezar a identificar objetos examinando el planteamiento del problema o realizando un «análisis sintáctico gramatical» en la narrativa del sistema que se va a construir. Los objetos se determinan subrayando cada nombre o cláusula nominal e introduciéndola en una tabla simple. Los sinónimos deben destacarse. Si se requiere del objeto que implemente una solución, entonces éste formará parte del espacio de solución; en caso de que el objeto se necesite solamente para describir una solución, éste forma parte del espacio del problema. Pero, ¿qué debemos buscar una vez que se han aislado todos los nombres? Los objetos se manifiestan de alguna de las formas mostradas en la Figura y pueden ser: entidades externas (por ejemplo: otros sistemas, dispositivos, personas) que producen o consumen información a usar por un sistemas computacional; cosas (por ejemplo: informes, presentaciones, cartas, señales) que son parte del dominio de información del problema; ocurrencias o sucesos (por ejemplo: una transferencia de propiedad o la terminación de una serie de movimientos en un robot) que ocurren dentro del contexto de una operación del sistema; papeles o roles (por ejemplo: director, ingeniero, vendedor) desempeñados por personas que interactúan con el sistema; unidades organizacionales (por ejemplo: división, grupo, equipo) que son relevantes en una aplicación; lugares (por


13

ejemplo: planta de producción o muelle de carga) que establecen el contexto del problema y la función general del sistema; estructuras (por ejemplo: sensores, vehículos de cuatro ruedas o computadoras) que definen una clase de objetos o, en casos extremos, clases relacionadas de objetos.

La clasificación mostrada anteriormente es una de las muchas que se han propuesto en la literatura. También es importante destacar. qué no son los objetos. En general, un objeto nunca debe tener un «nombre procedimental imperativo». Por ejemplo, si los desarrolladores de un software para un sistema gráfico médico definieron un objeto con el nombre inversión de imagen, estarían cometiendo un sutil error. La imagen obtenida por el software pudiera ser, en efecto, un objeto (es un elemento que forma parte del dominio de información), pero la inversión de la imagen es una operación que se aplica a dicho objeto. Inversión debe definirse como una operación del objeto imagen, pero no como objeto separado que signifique versión de imagen. Como establece Cashman, «...el objetivo de la orientación a objetos es encapsular, pero manteniendo separados los datos y las operaciones sobre estos datos». Para ilustrar cómo pueden definirse los objetos durante las primeras etapas del análisis, volvamos al ejemplo del sistema de seguridad Hogar-Seguro. realizamos un «análisis sintáctico gramatical» sobre la narrativa de procesamiento para el sistema Hogar-Seguro. La narrativa de procesamiento se reproduce a continuación: El software Hogar-Seguro le permite al propietario de la casa configurar el sistema de seguridad una vez que este se instala, controla todos los sensores conectados al sistema de seguridad, e interactúa con el propietario a través de un teclado numérico y teclas de función contenidas en el panel de control de Hogar-Seguro.


14

Durante la instalación, el panel de control de Hogar-Seguro se usa para «programar» y configurar el sistema. A cada sensor se le asigna un número y tipo, se programa una contraseña maestra para activar y desactivar el sistema, y se introducen números de teléfono a marcar cuando un sensor detecte un suceso. Cuando se reconoce un suceso de sensor, el software invoca una alarma audible asociada al sistema. Después de un tiempo de espera especificado por el propietario durante las actividades de configuración del sistema, el software marca un número de teléfono de un servicio de control, proporciona información acerca de la localización, e informa de la naturaleza del suceso detectado. El número será remarcado cada 20 segundos hasta obtener una conexión telefónica. Toda la interacción con Hogar-Seguro está gestionada por un subsistema de interacción con el usuario que toma la entrada a partir del teclado numérico y teclas de función, y muestra mensajes y el estado del sistema en la pantalla LCD. La interacción con el teclado toma la siguiente forma... Extrayendo los nombres podemos proponer varios objetos potenciales:

Clase / Objeto potencial Clasificación general

Propietario

sensor

panel de control

instalación

sistema (alias sistema de seguridad)

número, tipo

contraseña maestra

número de teléfono

suceso de sensor

alarma audible

servicio de control

rol o entidad externa

entidad externa

entidad externa

ocurrencia

cosa

no son objetos, sino atributos

de sensor

cosa

cosa

ocurrencia

entidad externa

unidad organizacional o entidad


15

La lista anterior se continuará hasta que se hayan considerado todos los nombres de la descripción del proceso. Observe que hemos llamado a cada entrada en la lista un objeto potencial. Debemos considerar cada uno de ellos antes de tomar una decisión final. Coad y Yourdon sugieren seis características de selección a usar cada vez que un analista considera si incluye o no un objeto potencial en el modelo de análisis:

1. Información retenida: el objeto potencial será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funcione.

2. Servicios necesarios: el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de sus atributos.

3. Atributos múltiples: durante el análisis de requisitos, se debe

centrar la atención en la información principal (un objeto con un solo atributo puede, en efecto, ser útil durante el diseño, pero seguramente será mejor presentado como un atributo de otro objeto durante la actividad de análisis)

4. Atributos comunes: puede definirse un conjunto de atributos

para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto.

5. Operaciones comunes: puede definirse un conjunto de

operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto;

6. Requisitos esenciales: entidades externas que aparecen en el

espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema, serán casi siempre definidas como objetos en el modelo de requisitos.

Para ser considerado un objeto válido a incluir en el modelo de requisitos, un objeto potencial debe satisfacer todas (o casi todas) las características anteriores. La decisión de incluir objetos potenciales en el modelo de análisis es algo subjetivo, y una evaluación posterior puede llegar a descartar un objeto o re-incluirlo. Sin embargo, el primer paso del A00 debe ser la definición de objetos, y la consiguiente toma de decisiones (incluso subjetivas). Teniendo esto en cuenta, aplicamos las características selectivas a la lista de objetos potenciales de Hogar-Seguro (véase tabla a continuación).


16

Clase / Objeto potencial Clasificación general

Propietario

sensor

panel de control

instalación

sistema (alias sistema de

seguridad)

número, tipo

contraseña maestra

número de teléfono

suceso de sensor

alarma audible

servicio de control

Rechazado(1, 2 fallan aunque 6

es aplicable)

Aceptado ( se aplican todas)

Aceptado (se aplican todas)

Rechazado


Rechazado (falla 3)

Rechazado (falla 3)

Rechazado (falla 3)


Aceptado (se aplican 2,3,4,5 y 6)

Rechazado(1, 2 fallan aunque 6

es aplicable)

Debe tenerse en cuenta que: (1) la lista anterior no incluye todo, hay que añadir objetos adicionales para completar el modelo; (2) algunos de los objetos potenciales rechazados serán atributos de los objetos aceptados (por ejemplo, número y tipo son atributos de sensor, y contraseña maestra y número de teléfono pueden convertirse en atributos de sistema); y (3) diferentes descripciones del problema pueden provocar la toma de diferentes decisiones de «aceptación o rechazo» (por ejemplo, si cada propietario tiene su propia contraseña o fue identificado por impresiones de voz, el objeto Propietario cumpliría las características 1 y 2 y habría sido aceptado).

Especificación de atributos

Los atributos describen un objeto que ha sido seleccionado para ser incluido en el modelo de análisis. En esencia, son los atributos los que definen al objeto, los que clarifican lo que se representa el objeto en el contexto del espacio del problema. Por ejemplo, si tratáramos de construir un sistema de estadísticas para jugadores profesionales de béisbol, los atributos del objeto Jugador serían muy diferentes de los atributos del mismo objeto cuando se use dentro del contexto de un sistema de pensiones para jugadores profesionales. En el primero,


17

atributos tales como nombre, posición; promedio de bateo, porcentaje de estancia en el campo de juego, años jugados y partidos jugados pueden ser relevantes. En el segundo caso, algunos de estos atributos serían relevantes pero otros serían reemplazados (o potenciados) por atributos como salario medio, crédito total, opciones elegidas para el plan de pensión, dirección postal, etc. Para desarrollar un conjunto significativo de atributos para un objeto, el analista puede estudiar de nuevo la narrativa del proceso (o descripción del ámbito del alcance) para el problema y seleccionar aquellos elementos que razonablemente «pertenecen» al objeto. Además, para cada objeto debe responderse el siguiente interrogante: ¿Qué elementos (compuestos y/o simples) definen completamente al objeto en el contexto del problema actual? Para ilustrar esto, consideremos el objeto Sistema definido para Hogar-seguro. Anteriormente ya indicamos que el propietario puede configurar el sistema de seguridad para reflejar la información acerca de los sensores, sobre la respuesta de la alarma, sobre la activación/desactivación, sobre identificación, etc. Usando la notación de la descripción del contenido definida para el diccionario de datos, podríamos representar estos elementos de datos compuestos de la siguiente manera: Información del censor = tipo de sensor + número de sensor + umbral de alarma Información de respuesta de la alarma = tiempo de retardo + número de teléfono + tipo de alarma Información de activación/desactivación = contraseña maestra + cantidad de intentos permitidos + contraseña temporal Información de identificación = ID del sistema + verificación de número de teléfono + estado del sistema Cada uno de los elementos de datos a la derecha del signo de igualdad puede volver a definirse en un nivel elemental, pero para nuestros propósitos, comprenden una lista razonable de atributos para el objeto sistema.

Definición de operaciones

Las operaciones definen el comportamiento de un objeto y cambian, de alguna manera, los atributos de dicho objeto. Más concretamente, una operación cambia valores de uno o más atributos contenidos en el objeto. Por lo tanto, una operación debe tener «conocimiento» de la naturaleza de los atributos de los objetos y deben ser implementadas


18

de manera tal que le permita manipular las estructuras de datos derivadas de dichos atributos. Aunque existen muchos tipos diferentes de operaciones, éstas pueden clasificarse en tres grandes categorías: (1) operaciones que manipulan, de alguna manera, datos (ejemplo: añadiendo, eliminando, reformateando, seleccionando); (2) operaciones que realizan algún cálculo; y (3) operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de control . En una primera iteración para obtener un conjunto de operaciones para los objetos del modelo de análisis, el analista puede estudiar de nuevo la narrativa del proceso (o descripción del ámbito) del problema y seleccionar aquellas operaciones que razonablemente pertenecen al objeto. Para realizar esto, se estudia de nuevo el análisis gramatical y se aíslan los verbos. Algunos de estos verbos serán operaciones legítimas y pueden conectarse fácilmente a un objeto específico. Por ejemplo, de la narrativa de proceso de Hogar-seguro, vemos que «al sensor se le asigna un número y un tipo» o que «se programa una contraseña maestra para activar y desactivar el sistema». Estas dos frases indican varias cosas: que una operación de asignación es relevante para el objeto Sensor; que una operación de programar se le aplicará al objeto Sistema; que activar y desactivar son operaciones aplicables al Sistema (o sea que el estado del sistema puede en última instancia definirse usando notación del diccionario de datos) como estado del sistema = [activado I desactivado] Tras una investigación más detallada, es probable que haya que dividir la operación programar en varias sub-operaciones más específicas requeridas para configurar el sistema. Por ejemplo, programar implica especificar números de teléfonos, configurar características del sistema (por ejemplo, crear la tabla de sensores, introducir las características de las alarmas), e introducir la(s) contraseña(s), pero por ahora, especificaremos programar como una operación simple.

Fin de la definición del objeto

La definición de operaciones es el último paso para completar la especificación del objeto; las operaciones se eligieron a partir de un examen gramatical de la narrativa de proceso del sistema. Las operaciones adicionales pueden determinarse considerando la «historia de la vida» de un objeto y los mensajes que se pasan entre objetos definidos por el sistema. La historia de la vida genérica de un objeto puede definirse reconociendo que dicho objeto debe ser creado, modificado, manipulado o leído de manera diferente, y posiblemente borrado. Para el objeto Sistema, esto puede expandirse para reflejar actividades conocidas que ocurren durante su vida (en este caso, durante el tiempo que Hogar-Seguro se mantiene


19

operativo). Algunas de las operaciones pueden determinarse a partir de comunicaciones semejantes entre objetos. Por ejemplo, el Suceso sensor enviará un mensaje a Sistema para mostrar en pantalla la localización y número del suceso; el Panel de control enviará un mensaje de reinicialización para actualizar el estado del Sistema (un atributo); la Alarma audible enviará un mensaje de consulta, el Panel de control enviará un mensaje de modificación para cambiar uno o más atributos sin reconfigurar el objeto sistema por completo; el Suceso sensor enviará un mensaje para llamar al número(s) de teléfono(s) contenido(s) en el objeto. Podrán considerarse otros mensajes para derivar operaciones correspondientes. Se usaría un enfoque similar para cada uno de los objetos definidos para Hogar-Seguro. Después de haber definido los atributos y operaciones para todos los objetos especificados hasta este punto, se crearían los inicios del modelo AOO.

GESTIÓN DE PROYECTOS DE SOFTWARE ORIENTADOS A OBJETOS

La moderna gestión de proyectos de software puede subdividirse en las siguientes actividades:

1. Establecimiento de un marco de proceso común para el proyecto.

2. Uso del marco y de métricas históricas para desarrollar estimaciones de esfuerzo y tiempo.

3. Especificación de productos de trabajo e hitos que permitirán medir el progreso.

4. Definición de puntos de comprobación para la gestión de riesgos, aseguramiento de la calidad y control.

5. Gestión de los cambios que ocurren invariablemente al progresar el proyecto.

6. Seguimiento, monitorización y control del progreso.

El director técnico que se enfrenta con un proyecto de software orientado a objetos aplica estas seis actividades. Pero debido a la naturaleza única del software orientado a objetos, cada una de estas actividades de gestión tiene un matiz levemente diferente y debe ser enfocado usando un modelo propio. En las secciones que siguen, exploramos el área de gestión de proyectos orientados a objetos. Los principios de gestión fundamentales serán los mismos, pero para que un proyecto O0 sea dirigido correctamente hay que adaptar la técnica.


20

El marco de proceso común para OO

Un marco de proceso común (MPC) define un enfoque organizativo para el desarrollo y mantenimiento de software. El MPC identifica el paradigma de ingeniería del software aplicado para construir y mantener el software, así como las tareas, hitos y entregas requeridos. Establece el grado de rigor con el cual se enfocarán los diferentes tipos de proyectos. El MPC siempre es adaptable, de tal manera que siempre cumpla con las necesidades individuales del equipo del proyecto. Ésta es su característica más importante. Ed Berard y Grady Booch, entre otros, sugieren el uso de un modelo recursivo/paralelo para el desarrollo de software orientado a objetos. En esencia, el modelo recursivo/paralelo funciona de la siguiente manera:

1. Realizar los análisis suficientes para aislar las clases del problema y las conexiones más importantes.

2. Realizar un pequeño diseño para determinar si las clases y conexiones pueden ser implementadas de manera práctica.

3. Extraer objetos reutilizables de una biblioteca para construir un prototipo previo.

4. Conducir algunas pruebas para descubrir errores en el prototipo.

5. Obtener realimentación del cliente sobre el prototipo. 6. Modificar el modelo de análisis basándose en lo que se ha

aprendido del prototipo, de la realización del diseño y de la realimentación obtenida del cliente.

7. Refinar el diseño para acomodar sus cambios. 8. Construir objetos especiales (no disponibles en la biblioteca). 9. Ensamblar un nuevo prototipo usando objetos de la biblioteca y

los objetos que se crearon nuevos. 10. Realizar pruebas para descubrir errores en el prototipo. 11. Obtener realimentación del cliente sobre el prototipo.

Este enfoque continúa hasta que el prototipo evoluciona hacia una aplicación en producción. El modelo recursivo/paralelo es muy similar al modelo de proceso OO. El progreso se produce iterativamente. Lo que hace diferente al modelo recursivo/paralelo es el reconocimiento de que (1) el modelo de análisis y diseño para sistemas O0 no puede realizarse a un nivel uniforme de abstracción, y (2) el análisis y diseño pueden aplicarse a componentes independientes del sistema de manera concurrente. Berard describe el modelo de la siguiente manera:

1. Descomponer sistemáticamente el problema en componentes altamente independientes.


21

2. Aplicar de nuevo el proceso de descomposición a cada una de las componentes independientes para, a su vez, descomponerlas (la parte recursiva).

3. Conducir este proceso de reaplicar la descomposición de forma concurrente sobre todos los componentes (la parte paralela).

4. Continuar este proceso hasta cumplir los criterios de finalización.

Es importante observar que el proceso de descomposición mostrado anteriormente es discontinuo si el analista/diseñador reconoce que el componente o subcomponente requerido está disponible en una biblioteca de reutilización. Para controlar el marco de proceso recursivo/paralelo, el director del proyecto tiene que reconocer que el progreso está planificado y medido de manera incremental. Esto es, las tareas y la planificación del proyecto están unidas a cada una de las «componentes altamente independientes», y el progreso se mide para cada una de estas componentes individualmente. Cada iteración del proceso recursivo/paralelo requiere planificación, ingeniería (análisis, diseño, extracción de clases, prototipado y pruebas) y actividades de evaluación. Durante la planificación, las actividades asociadas con cada una de las componentes independientes del programa son incluidas en la planificación. [Nota: Con cada iteración se ajusta la agenda para acomodar los cambios asociados con la iteración precedente]. Durante las primeras etapas del proceso de ingeniería, el análisis y el diseño se realizan iterativamente. La intención es identificar todos los elementos importantes del análisis OO y de los modelos de diseño. Al continuar el trabajo de ingeniería, se producen versiones incrementales del software. Durante la evaluación se realizan, para cada incremento, revisiones, evaluaciones del cliente y pruebas, las cuales producen una realimentación que afecta a la siguiente actividad de planificación y al subsiguiente incremento.

Métricas y estimación en proyectos orientados a objetos

Las técnicas de estimación en proyectos de software convencionales requieren estimaciones de líneas de código (LDC) o puntos de función (PF) como controlador principal de estimación. Las estimaciones realizadas a partir de LDC tienen poco sentido en proyectos OO debido a que el objetivo principal es la reutilización. Las estimaciones a partir de PF pueden usarse de manera efectiva, pues los elementos del dominio de información requeridos se pueden determinar a partir del planteamiento del problema. El análisis de PF puede aportar valores para estimaciones en proyectos 00, pero la medida de PF no provee una granularidad suficiente para ajustes de planificación y esfuerzo a realizar, los cuales se requieren cuando iteramos a través


22

del paradigma recursivo/paralelo. Lorenz y Kidd sugieren el siguiente conjunto de métricas para proyectos:

Número de guiones de escenario. Un guión de escenario (como los casos de uso) es una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación. Cada guión se organiza en tripletes de la forma: [iniciador, acción, participante] donde iniciador es el objeto que solicita algún servicio (que inicia un mensaje); acción es el resultado de la solicitud; y participante es el objeto servidor que cumple la petición (solicitud). El número de guiones de actuación está directamente relacionada al tamaño de la aplicación y al número de casos de prueba que se deben desarrollar para ejercitar el sistema una vez construido.

Número de clases clave. Las clases clave son las «componentes altamente independientes» definidas inicialmente en el AOO. Debido a que estas clases son centrales al dominio del problema, el número de dichas clases es una indicación del esfuerzo necesario para desarrollar el software y de la cantidad potencial de reutilización a aplicar durante el desarrollo del sistema.

Número de clases de soporte. Las clases de soporte son necesarias para implementar el sistema, pero no están directamente relacionadas con el dominio del problema. Como ejemplos podemos tomar las clases de Interfaz Gráfica de Usuario, el acceso a bases de datos y su manipulación y las clases de comunicación. Además las clases de soporte se definen iterativamente a lo largo del proceso recursivo/paralelo. El número de clases de soporte es un indicador del esfuerzo necesario requerido para desarrollar el software y de la cantidad potencial de reutilización a aplicar durante el desarrollo del sistema.

Número promedio de clases de soporte por clase clave. En general las clases clave son conocidas en las primeras etapas del proyecto. Las clases de soporte se definen a lo largo de éste. Si, dado un dominio de problema, se conociera la cantidad promedio de clases de soporte por clase clave, la estimación (basada en la cantidad total de clases) se simplificaría mucho. Lorenz y Kidd sugieren que las aplicaciones con IGU poseen entre dos y tres veces más clases de soporte que clases clave. Las aplicaciones sin IGU poseen a lo sumo dos veces más de soporte que clave.


23

Número de subsistemas. Un subsistema es una agregación de clases que dan soporte a una función visible al usuario final del sistema. Una vez que se identifican los subsistemas, resulta más fácil realizar una planificación razonable en la cual el trabajo en los subsistemas está repartido entre los miembros del proyecto.

Un enfoque OO para estimaciones y planificación

La estimación en proyectos de software es más un arte que una ciencia. Sin embargo, esto en modo alguno excluye el uso de un enfoque sistemático. Para desarrollar estimaciones razonables es esencial el desarrollo de múltiples puntos de datos. Esto significa que las estimaciones deben derivarse usando diferentes técnicas. Las estimaciones respecto al esfuerzo y la duración usadas en el desarrollo de software convencional son aplicables al mundo de la OO, pero la base de datos histórica para proyectos OO es relativamente pequeña en muchas organizaciones. Debido a esto, vale la pena sustituir la estimación de costes para software convencional por un enfoque diseñado explícitamente para software OO. Lorenz y Kidd sugieren el siguiente enfoque:

1. Desarrollo de estimaciones usando la descomposición de esfuerzos, análisis de PF y cualquier otro método aplicable a aplicaciones convencionales.

2. Desarrollar guiones de escenario y determinar una cuenta, usando AOO. Reconocer que el número de guiones de escenarios puede cambiar con el progreso del proyecto.

3. Determinar la cantidad de clases clave usando AOO. 4. Clasificar el tipo de interfaz para la aplicación y desarrollar un

multiplicador para las clases de soporte:

TIPO DE INTERFAZ MULTIPLICADOR

Interfaz no gráfica (No IGU)

Interfaz de usuario basada en texto

Interfaz Gráfica de Usuario ( IGU)

Interfaz Gráfica de Usuario (IGU) compleja

2.0

2.25

2.5

3.0

Multiplicar el número de clases clave (paso 3) por el multiplicador anterior para obtener una estimación del número de clases de soporte.


24

5. Multiplicar la cantidad total de clases (clave + soporte) por el número medio de unidades de trabajo por clase. Lorenz y Kidd sugieren entre 15 y 20 días persona por clase.

6. Comprobar la estimación respecto a clases multiplicando el número promedio de unidades de trabajo por guión de acción.

La planificación de proyectos orientados a objetos es complicada por la naturaleza iterativa del marco de trabajo del proceso. Lorenz y Kidd sugieren un conjunto de métricas que pueden ayudar durante esta planificación del proyecto: Número de iteraciones principales. Recordando el modelo en espiral, una iteración principal corresponderá a un recorrido de 360 grados de la espiral. El modelo de proceso recursivo/paralelo engendrará un número de mini espirales (iteraciones localizadas) que suceden durante el progreso de la iteración principal. Lorenz y Kidd sugieren que las iteraciones de entre 2.5 y 4 meses de duración son más fáciles de seguir y gestionar. Número de contratos completos. Un contrato es «un grupo de responsabilidades públicas relacionadas que los subsistemas y las clases proporcionan a sus clientes». Un contrato es un hito excelente, y debería asociarse al menos un contrato a cada iteración del proyecto. Un jefe de proyecto puede usar contratos completos como un buen indicador del progreso en un proyecto OO.

Seguimiento del progreso en un proyecto orientado a objetos

Aunque el modelo de proceso recursivo/paralelo es el mejor marco de trabajo para un proyecto 00, el paralelismo de tareas dificulta el seguimiento del proyecto. El jefe del proyecto puede tener dificultades estableciendo hitos significativos en un proyecto OO debido a que siempre hay un cierto número de cosas ocurriendo a la vez. En general, los siguientes hitos principales pueden considerarse «completados» al cumplirse los criterios mostrados:

Hito técnico: análisis OO terminado

1. Todas las clases, y la jerarquía de clases, están definidas y revisadas.

2. Se han definido y revisado los atributos de clase y las operaciones asociadas a una clase.

3. Se han establecido y revisado las relaciones entre clases. 4. Se ha creado y revisado un modelo de comportamiento. 5. Se han marcado clases reutilizables.


25

Hito técnico: diseño O0 terminado

1. Se ha definido y revisado el conjunto de subsistemas. 2. Las clases se han asignado a subsistemas y han sido

revisadas. 3. Se ha establecido y revisado la asignación de tareas. 4. Se han identificado responsabilidades y colaboraciones 5. Se han diseñado y revisado los atributos y operaciones. 6. Se ha creado y revisado el modelo de paso de mensajes.

Hito técnico: programación O0 terminada

1. Cada nueva clase ha sido implementada en código a partir del modelo de diseño.

2. Las clases extraídas (de una biblioteca de reutilización) se han integrado.

3. Se ha construido un prototipo o incremento.

Hito técnico: prueba OO

Han sido revisadas la corrección y compleción del análisis O0 y del modelo de diseño. Se ha desarrollado y revisado una red de clases responsabilidades y colaboraciones. Se han diseñado casos de prueba y ejecutado pruebas al nivel de clases para cada clase. Se han diseñado casos de prueba y completado pruebas de agrupamientos y las clases se han integrado. Se han terminado las pruebas del sistema. Recordando el modelo de proceso recursivo/paralelo examinado anteriormente en este capítulo, es importante destacar que cada uno de estos hitos puede ser revisado nuevamente al entregar diferentes incrementos al usuario.


26

BIBLIOGRAFÍA

Ingeniería del software – un enfoque práctico. Roger S. Pressman

http://www.google.com.pe/search?num=10&hl=es&site=imghp&tb

m=isch&source=hp&biw=1366&bih=677&q=EL+PRODUCTO&oq=

EL+PRODUCTO&gs_l=img.3..0l10.1430.3454.0.4143.11.9.0.2.2.0

.186.986.4j5.9.0...0.0...1ac.1.Fl7oAV4lIQw#hl=es&tbo=d&site=img

hp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=soft

ware+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.1409

50.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2

AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb

8&bpcl=38897761&biw=1366&bih=634

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

http://www.ctic.uni.edu.pe/files/insoft01.pdf

Todos son links o enlaces a diferentes páginas web que se

consultaron para el desarrollo de esta sesión de clases.

isw-s20-conceptos y principios orientados a objetos

Documents