Presentacin de PowerPoint

INGENIERIA DEL SOFTWARE

ORIENTADO A OBJETOS

1

INGENIERA DEL SOFTWARE

El IEEE define:

Ingeniera es la aplicacin de un mtodo sistemtico, estructurado y cuantificable a estructuras, mquinas, productos, sistemas o procesos.

Ingeniera del software es la aplicacin de un mtodo sistemtico, estructurado y cuantificable al desarrollo, operacin y mantenimiento de software.

Bauer, 1972

La IS es el establecimiento y uso de slidos principios de ingeniera y buenas prcticas de gestin, as como la evolucin de herramientas y mtodos aplicables y su uso cuando sea apropiado para obtener, dentro de las limitaciones de recursos existentes, software que sea de alta calidad en un sentido explcitamente definido.

Es una forma de pensar, una filosofa, de la cual surge una cultura nueva que incorpora tcnicas y metodologas diferentes. desde el punto de vista computacional "es un mtodo de implementacin en el cul los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarqua de clases unidas va relaciones de herencia".

PROGRAMACION ORIENTADO A OBJETOS " POO "

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 visin orientada a objetos para la creacin de software de computadora, una abstraccin 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 aos sesenta. Sin embargo, las tecnologas de objetos han necesitado casi veinte aos para llegar a ser ampliamente usadas. Durante los aos 90. la ingeniera del software orientada a objetos se convirti en el paradigma de eleccin para muchos productores de software y para un creciente nmero de sistemas de informacin y profesionales de la ingeniera. A medida que pasa el tiempo, las tecnologas de objetos estn sustituyendo a los enfoques clsicos de desarrollo de software.

CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS

El proceso se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es aqu donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base para el plan del proyecto OO. El trabajo tcnico asociado con la ingeniera del software sigue el camino iterativo mostrado en la caja sombreada. La ingeniera del software hace hincapi en la reutilizacin. Por lo tanto, las clases se buscan en una biblioteca (de clases existentes) antes de construirse. Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de software aplica Anlisis orientado a objetos (AOO), diseo orientado a objetos (DOO), programacin 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.

MODELO DE PROCESO DE OO

ORIENTADO A OBJETOS

Para entender la visin orientada a objetos, consideremos un ejemplo de un objeto del mundo real cosa sobre la que usted est sentado ahora una silla. Silla es un miembro (el trmino instancia tambin se usa) de una clase mucho ms grande de objetos que llamaremos Mobiliario. Un conjunto de atributos genricos puede asociarse con cada objeto, en la clase Mobiliario. Por ejemplo, todo mueble tiene un costo, dimensiones, peso, localizacin 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.

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 MESA que es un miembro de la clase Mobiliario. La hereda todos los atributos de Mobiliario.

Secuencia tpica de un proceso para un proyecto OO.

ANALISIS ORIENTADO

A OBJETOS

El propsito del AOO es definir todas las clases que son relevantes al problema que se va a resolver, las operaciones y atributos las relaciones y comportamientos asociadas con ellas. Para cumplirlo se deben ejecutar las siguientes tareas:

1.Los requisitos bsicos del usuario deben comunicarse entre el cliente y el ingeniero del software.

2. Identificar las clases (es decir, definir atributos y mtodos).

3. Se debe especificar una jerarqua de clases.

4. Representan las relaciones objeto a objeto (conexiones de objetos).

5. Modelar el comportamiento del objeto.

6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo.

El objetivo del anlisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente. El AOO, como los mtodos de anlisis convencional , forman un modelo de anlisis multiparte para satisfacer este objetivo.

El panorama del AOO

La popularidad de las tecnologas de objetos ha generado docenas de mtodos de desde finales de los 80 y durante los 90'. Cada uno de ellos introduce un proceso para el anlisis de un producto o sistema, un conjunto de modelos que evoluciona fuera del proceso, y una notacin que posibilita al ingeniero del software crear cada modelo de una manera consistente. Entre los ms ampliamente utilizados se encuentran:

El mtodo de Wirfs-Brock. El mtodo de Brock no hace una distincin clara entre las tareas de anlisis y diseo. En su lugar, propone un proceso continuo que comienza con la valoracin de una especificacin del cliente y termina con el diseo. A continuacin se esbozan brevemente las tareas relacionadas con el anlisis de Wirfs-Brock:

1. Evaluar la especificacin del cliente.

2.Usar un anlisis gramatical para extraer clases candidatas de la especificacin.

3.Agrupar las clases en un intento de determinar clases.

4.Definir responsabilidades para cada clase. Asignar responsabilidades a cada clase. 5.Identificar relaciones entre clases.

6.Definir colaboraciones entre clases basndose en sus responsabilidades.

7.Construir representaciones jerrquicas de clases para mostrar relaciones de herencia.

8. Construir un grafo de colaboraciones para el sistema.

El mtodo de Booch. El mtodo de Booch abarca un microproceso de desarrollo y un macroproceso de desarrollo. El nivel micro define un conjunto de tareas de anlisis que se reaplican en cada etapa en el macro proceso. Por esto se mantienen un enfoque evolutivo. El micro proceso de desarrollo identifica clases y objetos y la semntica de dichas clases y objetos, define las relaciones entre clases y objetos y realiza una serie de refinamientos para elaborar el modelo del anlisis.

El mtodo de Rumbaugh. Rumbaugh y sus colegas desarrollaron la Tcnica de Modelado Objetos (OMT) para el anlisis, diseo del sistema y diseo a nivel de objetos. La actividad de anlisis crea tres modelos: el modelo de objetos (una representacin de objetos, clases, jerarquas y relaciones), el modelo dinmico (una representacin del comportamiento del sistema y los objetos) y el modelo funcional (una representacin a alto nivel del flujo de informacin a travs del sistema similar al DFD).

El mtodo de Jacobson. Tambin llamado OOSE (en espaol Ingeniera del Software Orientada a Objetos), el mtodo de Jacobson es una versin simplificada de Objectory, un mtodo patentado, tambin desarrollado por Jacobson. Este mtodo se diferencia de los otros por la importancia que da al caso de uso - una descripcin o escenario que describe cmo el usuario interacta con el producto o sistema.

El mtodo de Coad y Yourdon. El mtodo de Coad y Yourdon se considera, con frecuencia, como uno de los mtodos del ms sencillos de aprender. La notacin del modelado es relativamente simple y las reglas para desarrollar el modelo de anlisis son evidentes. A continuacin sigue una descripcin resumida del proceso de AOO de Coad y Yourdon:

Identificar objetos, usando el criterio de que buscar.

Definir una estructura de generalizacin - especificacin.

ANALISIS DEL DOMINIO

El anlisis en sistemas orientados a objetos puede ocurrir a muchos niveles diferentes de abstraccin. A nivel de negocios o empresas, las tcnicas asociadas con el pueden acoplarse con un enfoque de ingeniera de la informacin en un esfuerzo por definir clases, objetos, relaciones y comportamientos que modelen el negocio por completo. A nivel de reas de negocios, puede definirse un modelo de objetos que describa el trabajo de un rea especfica de negocios (o una categora de productos o sistemas). A nivel de las aplicaciones, el modelo de objetos se centra en los requisitos especficos del cliente, pues stos afectan a la aplicacin que se va a construir.

Anlisis de reutilizacin y del dominio

Las tecnologas de objetos estn influenciadas por la reutilizacin. Considere un ejemplo simple. El anlisis de los requisitos para nuevas aplicaciones indican la necesidad de 100 clases. Se le asigna a dos equipos la tarea de construir la aplicacin. Cada uno debe disear y construir un producto final y, a su vez, est compuesto de personas con el mismo nivel de habilidad y experiencia.

EL PROCESO DE ANLISIS DEL DOMINIO

Firesmith describe el anlisis del dominio del software de la siguiente manera:

El anlisis del dominio del software es la identificacin, anlisis y especificacin de requisitos comunes de un dominio de aplicacin especfico, normalmente para su reutilizacin en mltiples proyectos dentro del mismo dominio de aplicacin ... (el anlisis orientado a objetos del dominio es la identificacin, anlisis y especificacin de capacidades comunes y reutilizables dentro de un dominio de aplicacin especfico, en trminos de objetos, clases, submontajes y marcos de trabajo comunes.

DISEO ORIENTADO

A OBJETOS

1) A diferencia de los mtodos de diseo de software convencionales, el DOO proporciona un diseo que alcanza diferentes niveles de modularidad. La mayora de los componentes de un sistema, estn organizados en subsistemas, un mdulo a nivel del sistema. Los datos y las operaciones que manipulan los datos se encapsulan en objetos , una forma modular que es el bloque de construccin de un sistema 00. Adems, el DOO debe describir la organizacin especfica de los datos de los atributos y el detalle procedural de cada operacin. Estos representan datos y piezas algortmicas de un sistema OOy son los que contribuyen a la modularidad global.

2) El diseo de software orientado a objetos es difcil, y el diseo de software reusable orientado a objetos es aun ms difcil. Se deben identificar los objetos pertinentes, clasificarlos dentro de las clases en la granularidad correcta, definir interfaces de clases y jerarquas de herencia y establecer relaciones clave entre ellos. El diseo debe ser especfico al problema que se tiene entre manos, pero suficientemente general para adaptarse a problemas y requerimientos futuros. Adems se deber evitar el rediseo, o por lo menos Los diseadores experimentados en OO dicen que un diseo reusable y flexible es difcil, si no imposible de obtener bien, la primera vez. Antes de que un diseo sea terminado, usualmente tratan de varias veces, modificndolo cada vez.

LAS CUATRO CAPAS DE LA PIRMIDE DE DISEO SON:

1) La capa subsistema. Contiene una representacin de cada uno de los subsistemas, para permitir al software conseguir sus requisitos definidos por el cliente e implementar la infraestructura que soporte los requerimientos del cliente.

2) La capa de clases y objetos. Contiene la jerarqua de clases, que permiten al sistema ser creado usando generalizaciones y cada vez especializaciones ms acertadas. Esta capa tambin contiene representaciones.

3) La capa de mensajes. Contiene detalles de diseo, que permite a cada objeto comunicarse con sus colaboradores. Esta capa establece interfaces externas e internas para el sistema.

4) La capa de responsabilidades. Contiene estructuras de datos y diseos algortmicos, para todos los atributos y operaciones de cada objeto.

LA PIRMIDE DEL DISEO OO

ENFOQUE CONVENCIONAL VS OO

Los enfoques convencionales para el diseo de software aplican distintas notaciones y conjunto de heursticas, para trazar el modelo de anlisis en un modelo de diseo cada elemento del modelo convencional de anlisis se corresponde con uno o ms capas del modelo de diseo. Al igual que el diseo convencional de software, el aplica el diseo de datos cuando los atributos son representados, el diseo de interfaz cuando se desarrolla un modelo de mensajera, y diseo a nivel de componentes mental), para operaciones de diseo. Es importante notar que la arquitectura de un diseo tiene ms que ver con la colaboracin entre objetos que con el control de flujo entre componentes del sistema.

ASPECTOS DEL DISEO

Descomponibilidad: la facilidad con que un mtodo de diseo ayuda al diseador a descomponer un problema grande en problemas ms pequeos, hacindolos ms fcil de resolver.

Componibilidad: el grado con el que un mtodo de diseo asegura que los componentes del programa (mdulos), una vez diseados y construidos, pueden ser reutilizados para crear otros sistemas.

Comprensibilidad: la facilidad con la que el componente de un programa puede ser entendido, sin hacer referencia a otra informacin o mdulos.

Continuidad: la habilidad para hacer pequeos cambios en un programa y que se revelen haciendo los cambios pertinentes en uno o muy pocos mdulos.

Proteccin: una caracterstica arquitectnica, que reduce la propagacin de efectos colaterales, si ocurre un error en un mdulo dado.

EL PANORAMA DE DOO

El mtodo de Booch: abarca un proceso demicro desarrollo y un proceso de macro desarrollo. En el contexto del diseo, el macro desarrollo engloba una actividad de planificacin arquitectnica, que agrupa objetos similares en particiones arquitectnicas separadas, capas de objetos por nivel de abstraccin, identifica situaciones relevantes, crea un prototipo de diseo y valida el prototipo aplicndolo a situaciones de uso. El micro desarrollo define un conjunto de reglas que regulan el uso de operaciones y atributos y las polticas del dominio especfico para la administracin de la memoria, manejo de errores y otras funciones; desarrolla situaciones que describen la semntica de las reglas y polticas; crea un prototipo para cada poltica; instrumenta y refina el prototipo; y revisa cada poltica para as transmitir su visin arquitectnica.

El mtodo de Rumbaugh: engloba una actividad de diseo que alienta al diseo a ser conducido a dos diferentes niveles de abstraccin. El de sistema se centra en el esquema de los componentes que se necesitan para construir un sistema o producto completo

El mtodo de Jacobson: El diseo para ISOO (Ingeniera del software orientada a objetos), es una versin simplificada del mtodo propietario Objectory, tambin desarrollado por Jacobson. El modelo de diseo enfatiza la planificacin para el modelo de anlisis ISOO. En principio, el modelo idealizado de anlisis se adapta para acoplarse al ambiente del mundo real. Despus los objetos de diseo primarios, llamados bloques, son creados y catalogados como bloques de interfaz, bloques de entidades y bloques de control.

El mtodo de Coad y Yourdon: se desarroll estudiando cmo es que los diseadores orientados a objetos efectivos hacen su trabajo. La aproximacin de diseo dirige no slo la aplicacin, sino tambin la infraestructura de la aplicacin, y se enfoca en la representacin de cuatro componentes mayores de sistemas: la componente de dominio del problema, la componente de interaccin humana, la componente de administracin de tareas y la de administracin de datos.

El mtodo de Wirfs-Brock: definen un conjunto de tareas tcnicas, en la cual el anlisis conduce sin duda al diseo. Los protocolos3 para cada clase se construyen refinando contratos entre objetos. Cada operacin (responsabilidad) y protocolo (diseo de interfaz) se disea hasta un nivel de detalle que guiar la implementacin. Se desarrollan las especificaciones para cada clase (definir responsabilidades privadas y detalles de operaciones) y cada subsistema (identificar las clases encapsuladas y la interaccin entre subsistemas).

ETAPAS DEL DOO

Describir cada subsistema y asignar a procesadores y tareas.

2. Elegir una estrategia para implementar la administracin de datos, soporte de interfaz y administracin de tareas.

3. Disear un mecanismo de control, para el sistema apropiado.

4. Disear objetos creando una representacin procedural para cada operacin, y estructuras de datos para los atributos de clase.

Disear mensajes, usando la colaboracin entre objetos y relaciones.

6. Crear el modelo de mensajera.

7. Revisar el modelo de diseo y renovarlo cada vez que se requiera.

FLUJO DE PROCESO PARA DOO

EL PROCESO DE DISEO DE SISTEMA

El proceso de diseo del sistema abarca las siguientes actividades:

Particin del modelo de anlisis en subsistemas.

Identificar la concurrencia dictada por el problema.

Asignar subsistemas a procesadores y tareas.

Desarrollar un diseo para la interfaz de usuario.

Elegir una estrategia bsica para implementar la administracin (gestin) de datos.

Identificar recursos globales y los mecanismos de control requeridos para su acceso.

Disear un mecanismo de control apropiado para el sistema, incluyendo administracin de tareas.

Considerar cmo deben manejarse las condiciones de frontera.

Revisar y considerar Trade-offs.

PROCESO DE DISEO DE OBJETOS

El diseo de objetos tiene que ver con el diseo detallado de los objetos y sus interacciones. Se completa dentro de la arquitectura global, definida durante el diseo del sistema y de acuerdo con las reglas y protocolos de diseo aceptados. El diseo del objeto est relacionado en particular con la especificacin de los tipos de atributos, cmo funcionan las operaciones y cmo los objetos se enlazan con otros objetos.

Actividades:

Descripcin de objetos

Diseo de algoritmos y estructuras de datos

PATRONES DE DISEO

Se encontrarn patrones repetidos de clases y objetos de comunicacin, en muchos sistemas orientados a objetos. Estos patrones resuelven problemas especficos de diseo , y vuelven al diseo orientado a objetos ms flexible, elegante y extremadamente reutilizable. Ayudan a los diseadores a reutilizar diseos exitosos basando nuevos diseos en experiencia previa.

En la actualidad, se ha desarrollado y catalogado un nmero relativamente pequeo de patrones. De cualquier manera, los ltimos cinco aos han sido testigos de una tremenda explosin, en trminos de inters industrial. Los patrones, junto con los componentes, ofrecen la esperanza de que la ingeniera de software, eventualmente, se parezca a otras disciplinas de ingeniera, con clases volvindose el anlogo en software de componentes electrnicos, y los patrones volvindose el anlogo en software de pequeos circuitos hechos de componentes.

PRUEBAS ORIENTADAS

A OBJETOS

EL objetivo de las pruebas, expresado de forma sencilla, es encontrar el mayor nmero posible de errores con una cantidad razonable de esfuerzo, aplicado sobre un lapso de tiempo realista.

A pesar de que este objetivo fundamental permanece inalterado para el software orientado a objetos, la naturaleza de los programas OO cambian las estrategias y las tcticas de prueba.

La prueba de los sistemas OO presentan un nuevo conjunto de retos al ingeniero del software. La definicin de pruebas debe ser ampliada para incluir tcnicas que descubran errores (revisiones tcnicas formales), aplicadas para los modelos de A00 y DOO. La integridad, complecin y consistencia de las representaciones O0 deben ser evaluadas conforme se construyen. Las pruebas de unidad pierden mucho de su significado, y las estrategias de integracin cambian de modo significativo. En resumen, las estrategias y tcticas de prueba deben tomarse en cuenta para las caractersticas propias del software OO.

PRUEBAS DE LOS MODELOS DE AOO Y DOO

Los modelos de anlisis y diseo no pueden probarse en el sentido convencional, ya que no pueden ejecutarse. Sin embargo, se pueden utilizar las revisiones tcnicas formales para examinar la exactitud y consistencia de ambos modelos de anlisis y diseo.

Exactitud de los modelos de AOO y DOO

La notacin y sintaxis que se utiliza para representar los modelos de anlisis y diseo se corresponder con el mtodo especfico de anlisis y diseo, elegido para el proyecto. Por consiguiente, la exactitud sintctica se juzga en el uso apropiado de la simbologa; cada modelo se revisa para asegurarse de que se han mantenido las convenciones propias del modelado. Durante el anlisis y diseo, la exactitud semntica debe juzgarse basada en la conformidad del modelo con el dominio del problema en el mundo real. Si el modelo refleja con exactitud el mundo real (al nivel de detalle apropiado a la etapa de desarrollo en la que se revisa el modelo), entonces es semnticamente correcto. Para determinar si el modelo en realidad refleja el mundo real, debe presentarse a expertos en el dominio del problema, quienes examinarn las definiciones de las clases y sus jerarquas, para detectar omisiones o ambigedades. Las relaciones entre clases (conexiones de instancia) se evalan para determinar si reflejan con exactitud conexiones del mundo real.

Consistencia de los modelos de AOO

La consistencia de los modelos de A OO y DOO debe juzgarse considerando las relaciones entre entidades dentro del modelo. Un modelo inconsistente tiene representaciones en una parte, que no se reflejan correctamente en otras partes del modelo .

ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS

La estrategia clsica para la prueba de software de ordenador, comienza con probar lo pequeo y funciona hacia fuera haciendo probar lo grande. Siguiendo la jerga de la prueba de software , se comienza con las pruebas de unidad, despus se progresa hacia las pruebas de integracin y se culmina con las pruebas de validacin del sistema. En aplicaciones convencionales, las pruebas de unidad se centran en las unidades de programa compilables ms pequeas el subprograma (por ejemplo, mdulo, subrutina, procedimiento, componente). Una vez que cada una de estas unidades han sido probadas individualmente, se integran en una estructura de programa, mientras que se ejecutan una serie de pruebas de regresin para descubrir errores, debidos a las interfaces entre los mdulos y los efectos colaterales producidos por aadir nuevas unidades. Por ltimo, el sistema se comprueba como un todo para asegurarse de que se descubren los errores en requisitos.

Las pruebas de unidad en el contexto de la OO

Cuando se considera el software orientado a objetos, el concepto de unidad cambia. La encapsulacin conduce a la definicin de clases y objetos. Esto significa que cada clase y cada instancia de una clase (objeto), envuelven atributos (datos) y operaciones (tambin conocidos como mtodos o servicios), que manipulan estos datos. En vez de probar un mdulo individual, la unidad ms pequea comprobable es la clase u objeto encapsulado. Ya que una clase puede contener un nmero de operaciones diferentes, y una operacin particular debe existir como parte de un nmero de clases diferentes, el significado de la unidad de prueba cambia drsticamente.

Las pruebas de integracin en el contexto OO

Ya que el software orientado a objetos no tiene una estructura de control jerrquico, las estrategias convencionales de integracin descendente (top-down) y ascendente (bottom-up) 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.

MTRICAS TCNICAS

PARA SISTEMAS

ORIENTADOS A OBJETOS

las mtricas y mediciones son componentes clave para cualquier disciplina de ingeniera y la ingeniera de software orientada a objetos no es una excepcin. Desgraciadamente, el uso de mtricas para sistemas O0 ha progresado mucho ms despacio que el uso de otros mtodos OO.

Ed Berard menciono que :

desconfan de cualquier cosa que parezca o suene a medicin. Son rpidos, bastante rpidos para sealar las imperfecciones, en los argumentos de cualquiera que hable acerca de las mediciones a los productos de software, procesos de software, y especialmente personas involucradas en software.

Estas mediciones son tiles ya que nos permiten al ingeniero evaluar el software al inicio del proceso, haciendo cambios que reducirn la complejidad y mejorarn la viabilidad, a largo plazo, del producto final.

Los objetivos primarios para las mtricas orientadas a objetos no son diferentes de aquellos de las mtricas desarrolladas para el software convencional:

para entender mejor la calidad del producto.

para evaluar la efectividad del proceso.

para mejorar la calidad del trabajo llevado a Cabo al nivel del proyecto.

EL PROPSITO DE LAS MTRICAS ORIENTADAS A OBJETOS

! Gracias