INGENIERIA DEL SOFTWARE MODOS DE PROGRAMACION ORIENTADA A OBJETOS (POO)

C. Arciniega*1 , J. Garca*2 , G. Guano*3 , G. Llumiquinga*4 IEE, Escuela Politcnica del Ejercito Sangolqui, Ecuador

Abstract En este trabajo se presenta un o breve resumen de la ingeniera del software y sus diferentes modos de operar la programacin orientada a objeto (POO). La programacin orientada a objetos o POO (OOP segn sus siglas en ingls) es un paradigma de programacin que usa objetos y sus interacciones, para disear aplicaciones y programas informticos. Est basado en varias tcnicas, incluyendo herencia, abstraccin, polimorfismo y encapsulamiento. Su uso se populariz a principios de la dcada de los aos 1990. En la actualidad, existe variedad de lenguajes de programacin que soportan la orientacin a objetos.

responder dicho objeto, es decir, qu operaciones se pueden realizar con l.

I.

INTRODUCCION

La identida es una propiedad de un objeto qued lo diferencia del resto, dicho con otras palabras, es su identificador (concepto anlogo al de identificador de una variable o unaconstante). Un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interaccin llamados mtodos, que favorecen la comunicacin entre ellos. Esta comunicacin favorece a su vez el cambio de estado en los propios objetos. Esta caracterstica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los objetos son entidades que tienen un determinado estad , comportamient o (mtodo e identida :o ) d El estad est compuesto de datos, ser uno o o varios atributos a los que se habrn asignado unos valores concretos (datos). El comportamient est definido por loso mtodos o mensajes a los que sabe

Fig 1. Tecnicas de la POO

II.

ANALISIS ORIENTADO A OBJETOS III. Diseo Orientado a Objetos (DOO).

Sirve para desarrollar una serie de modelos que describan el software para satisfacer un conjunto de requisitos. A. OO. B. Enfoques convencionales y enfoques El panorama del AOO.

Todos estos mtodos tienen una diferente forma de llegar a un anlisis de OO El Mtodo de Booch. El Mtodo de Rumbaugh. El Mtodo de Jacobson o OOSE (Ingeniera del software OO) Describe como el usuario interacta con el producto o sistema. El Mtodo de Coad y Yourdon. Es un mtodo sencillo de aprender, Identifica objetos, usando el criterio de que buscar. Identificar temas (representaciones de componentes de subsistemas), Definir atributos, Definir servicios. El mtodo de Wirfs-Brock Este mtodo es diferente ya que el proceso contino que comienza con la valoracin de una especificacin del cliente y termina con el diseo. C. Un enfoque unificado para el AOO. Vista de Usuario(Llamados actores en UML) representa al sistema visto desde el punto de vista del usuario final. Vista Estructural. Modela la estructura esttica(clases objetos y relaciones) Vista de Comportamiento. Representa los aspectos dinmicos o de de comportamiento del sistema. Vista de Implementacin. Se representa los aspectos estructurales y de comportamiento que se emplearan. Vista de entorno. Aspectos estructurales y de comportamiento en el que el sistema a implementar se representa.

El diseo orientado a objetos traduce el modelo de A00 del mundo real, a un modelo de implementacin especfica, que puede realizarse en software. El proceso de DO0 puede describirse como una pirmide compuesta por cuatro capas. La capa fundamental se centra en el diseo de subsistemas, que implementan funciones principales de sistema. La capa de clases especifica la arquitectura de objetos global, y la jerarqua de clases requerida para implementar un sistema. La capa de mensajes indica cmo debe ser realizada la colaboracin entre objetos, y la capa de responsabilidades identifica las operaciones y atributos que caracterizan cada clase. Al igual que el AOO, existen diferentes mtodos de DOO El DOO debe ser implementado un Ingeniero de software, es importante su utilizacin ya que un sistema Orientado a Objetos utiliza las definiciones que este tema abarca desde el inicio del planteamiento del problema a resolver mediante la Programacin para lo cual se reconocen los patrones de diseo apropiados. El DOO establece un anteproyecto, que permite al ingeniero definir la arquitectura Orienta a Objetos, en forma que maximice la reutilizacin del cdigo generado; para mejorar la velocidad del desarrollo y la calidad del producto. Existen dos pasos para el DOO el primero es con relacin a los sistemas y el otro al los objetos Diseo de sistemas se centra en arquitectura de software y la definicin de subsistemas o mdulos. Diseo de objetos describe objetos, hasta un nivel en el cual puedan ser implementados en el lenguaje de programacin. Subsistemas: El subsistema debe tener una interfaz bien definida, que reduzca todas las comunicaciones con el resto del sistema. Las clases incluidas dentro del subsistema deben colaborar slo con otras clases dentro del subsistema. El nmero de subsistemas debe ser bajo.

Un subsistema puede ser particionado internamente, para ayudar a reducir la complejidad. Cuando dos subsistemas se comunican entre s, pueden establecer un enlace cliente- o un servidor enlace punto-aEn un punto. cliente/servidor, cada subsistema enlace asume uno de los papeles implicados, (cliente o servidor). Estas componentes de subsistemas proporcionan la infraestructura de diseo, que permite a la aplicacin operar efectivamente. En la mayora de los casos una implementacin multiproceso incrementa dificultad y riesgo tcnico, siempre que sea posible se debe escoger la arquitectura de procesador ms simple que pueda realizar el trabajo. Para el proceso de diseo orientado a objetos se comienza por asegurarse que la arquitectura del sistema se ha definido antes de comenzar. El proceso de diseo de objetos se centra en la descripcin de estructuras de datos, que usan los atributos de clase, los algoritmos que usan las operaciones y los mensajes que permiten colaboraciones entre objetos relacionados. El primer paso es realizar una descripcin de los objetos que puede ser por protocolo o por implementacin; por protocolo quiere decir por las funciones que el objeto realiza en cambio por implementacin tiene su en la estructura interna que caracteriza a dicho objeto (atributos y mtodos u operaciones). Para la programacin Orientada a objetos se comienza por el modelado de clases que consiste en detallar el modelo de cada clase que pertenece al sistema, adems de la relacin que existe entre ellas. Los patrones de diseo permiten al diseador crear la arquitectura de diseo integrando componentes reusables. La programacin OO extiende el modelo de diseo a un dominio de ejecucin. Un lenguaje de programacin OO se usa para traducir las clases, atributos, operaciones y mensajes, de manera que puedan ejecutarse por la mquina.

En cuanto a la relacin que existe entre clases se utiliza los diagramas ULM que anteriormente ya los hemos conocido y revisado ya que estos nos facilitan en gran parte este trabajo de determinar la relacin entre clases y nos ayudan mucho en determinar la estructura del programa, existen relaciones entre clases por agregacin y composicin, asociacin, generalizacin, asociaciones, casos de uso y diagramas de estado, este ultimo describe el ciclo de funcionamiento de los objetos de las clases un ejemplo lo tenemos a continuacin:

Ilustracin 1 Ejemplo de un diagrama de estados. Explicacin: Cuando la cuenta se crea, se visualiza como una cuenta vaca. Hasta que una transaccin se lleve a cabo (los fondos depositados o retirados de la cuenta se visualizan como una cuenta activa). El diagrama de estado tambin muestra que, cuando una cuenta se cierra, se destruye.

IV.

MODELO OBJETO RELACION Podemos obtener con 3 etapas:

I . II .

Usando las tarjetas ndice CRC Revisando el modelo CRC de tarjetas ndices, se evalan responsabilidades, colaboradores y cada lnea de conexin sin etiquetar recibe un nombre. Para evitar ambigedades. Una vez que se han establecido y nombrado las relaciones.

Modelo Objeto Comportamiento Para el analista debe ejecutar los siguientes pasos: Evaluar todos los casos de uso para comprender totalmente la secuencia de interaccin dentro del sistema. Identificar sucesos que dirigen la secuencia de interaccin y comprender cmo estos sucesos se relacionan con objetos especficos. Crear una traza de sucesos para cada caso de uso. Construir un diagrama de transicin de estados para el sistema. Revisar el modelo objetocomportamiento para verificar exactitud y consistencia. V. PRUEBAS ORIENTADAS A OBJETOS (POO)
Estrategia clasic a Probar lo pequeo probar lo Grande Prueba de la unidad Contexto OO Encasuplacio n Clases Objetos Atributos Pruebas contexto OO POO no tiene una estructura de control jerarquico Pruebas ed Agrupamiento

Fig 3.1 Representacin del contexto de las (POO)

Diseos de casos de prueba para software Los mtodos de diseo de casos de prueba para software orientado a objetos continan evolucionando. Sin embargo, una aproximacin global al diseo de casos de prueba OO ha sido definida por Bernard

Ya que el software orientado a objetos no tiene una estructura de control jerrquico, las estrategias convencionales integracin descendente (top-down) y ascendente (bottomup) tienen muy poco significado. En suma, la integracin de operaciones una por una en una clase (la aproximacin de la integracin incremental convencional), a menudo es imposible por la interaccin directa e indirecta de los componentes que conforman la clase. Existen dos estrategias diferentes para las pruebas de integracin de los sistemas OO Existen clases (llamadas clases independientes), que utilizan muy pocas (o ninguna) clases servidoras. Despus de que las clases independientes se prueban, esta secuencia de pruebas por capas de clases dependientes contina hasta que se construye el sistema completo. A diferencia de la integracin convencional, el uso de drivers y stubs como operaciones de reemplazo, debe evitarse siempre que sea posible.

1.- Cada caso de pueba debe ser identificado separadamente 2.- Debe declararse el proposito de la prueba
. Debe desarrollarse una lista de pasos a seguir, como consecuencia de la prueba

Diagrama 3.1 Consejos para realizar una buena correccin de errores Pruebas basadas en errores El objetivo de las pruebas basadas en errores dentro de un sistema 00, es disear pruebas que tengan una alta probabilidad de revelar fallos. Ya que el producto o sistema debe adaptarse a los requerimientos del cliente, la

la estrategia consiste en hacer hiptesis de una serie de posibles fallos, y luego conducir las prueba s para comprobar las hiptesis .

El impacto de la programacin OO en las pruebas Hay distintas maneras en que la programacin orientada a objetos puede tener un impacto en las pruebas. Dependiendo del enfoque de la POO. Algunos tipos de fallos se vuelven menos probables (no vale la pena probar). Algunos tipos de fallos se vuelven ms probables (vale la pena probar) pruebas Aparecen algunos tipos nuevos de fallos. DISEOS DE CASO DE PRUEBA INTERCLASES Ejemplo

VI.

BIBLIOGRAFI A

2* Juan Jos Garca Chvez

Naci en Quito el 29 de Diciembre de 19 86, Estudio la primaria en el Instituto Pedaggico Manuela y la Secundaria en el Caizares Colegio Tcnico Salesiano Don Bosco, se Gradu en el ao 2004 de Bachiller Tcnico en Electricidad, luego Ingreso a la Escuela Politcnica la cual tubo que retirarse en el 20 07 por Nacional de problemas de salud , Luego de Trabajar por un periodo corto de tiempo en Cableado estructurado e instalaciones Elctricas, decidio en el 2009 ingresar a la Escuela Politcnica del Ejercito donde Actualmente cursa la carrera de Ingeniera Electrnica en Redes y Comunicacin de Datos. 3*

Fowler, M., Analysis Patterns: Reusable Object Models, Grand, M., Patterns in Java, vol. 1, John Wiley, Langr, J., Essential Java 1998. Style: Patterns for Implementation, Prentice-Hall, 1999. Larman, C., Applying Un1 and Patterns: An Introduction to Object-Oriented Analysis and Design, PrenticeHall, 1997. Martin, R.C., et al., Pattern Languages of Program Design 3, Addiso n-Wesley, 1997. Rising, L., y J. Coplien (eds.), The Patterns Handbook: Techniques, Strategies, andApplicatio ns, SIGS Books, 1998. Pree, W., Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995. Preiss, B., Data Structures and Algorithms with ObjectOriented Design Patterns in Java, John Wiley, 1999. Vlissides, J., Pattem Design Patterns Hatching: Applied, Addison -Wesley, 1998. Vlissides, J.M., J.O. Coplien y N. Pattern Kerth, ges Laggua of Program Design 2, Addison-Wesley, 1996. Cientos de libros de programacin orientada a objetos (POO) han sido pub licados. Una muestra de libros especficos en lenguajes de POO:

Geovanny Patricio Guano Chipuxi

Naci el 20 de Feb rero de 1991 en la ciud ad de Machachi, Pichincha - Ecuador, Sus estudios primarios los realizo en la Escuela "Jos Meja Lequerica", sus estudios

secundarios en el Colegio "Nacional Machachi" donde u como bachiller en fsico matemtico, se grad promocin del 2008, en este mismo ao ingresa a la Escuela Politcnica del Ejercito(ESPE), donde actualmente cursa el sexto nivel de Pregrado en la carrera de Ingeniera Electr nica en Telecomunicaciones, pertenece al club cultural de Software Libre MELI(Mentes Libres) donde colabora con la realizacin de nuevos e innovadores proyectos de la colectividad. en beneficio 4*

VII.

BIOGRAFI A

1*Cristian Andrs Arciniega Arciniega

Naci el 21 de Enero 1990, en la ciudad de Ibarra, Imbabura. Sus estudio s primarios los realiz en la Escuela Hermano Miguel La Salle de Ibarra hasta 3 ao de Bsica. Luego se traslado a vivir a la Ciudad de Quito, donde culmino sus estudios en la Escuela Hermano Miguel d e Quito. Su estudios Secundarios los realizo en el Colegio San Gabriel donde se gradu de bachiller en fsico matemtico promocin 2007, Ingreso a la Escuela Politcnica del Ejercito el mismo ao donde actualmente esta cruzado tercerde Ingeniera Electr nica en Automatizaci n a os y Control.

Gabriela Nathaly Llumiquinga Panchi

naci en Quito, Ecuador el 2 6

de Julio del 1989.Realjzo sus estudios primarios en la Escuela Pompillo Llona Numa de Quito, sus estudios secundarios en el Colegio Experimental de Seoritas Simn Bolvar se gradu en el 2007 de Bachiller en la Especialidad Informtica .Actualmente cursa el nivel de Ingeniera Electrnica 5 y Telecomunicaciones En la Universidad Fuerzas Armadas ESPE. de las