Cap. 20 20.

1 El paradigma orientado a objetos

Esto cuando declara [BER93]: Los beneficios de la tecnologa orientada a objetos se fortalecen si se
usa antes y durante el proceso de ingeniera del software. Esta tecnologa orientada a objetos considerada debe hacer sentir su impacto en todo el proceso de ingeniera del software. Un simple uso de programacin orientada a objetos (POO) no brindar los mejores resultados. Los ingenieros del software y sus directores deben considerar tales elementos el anlisis de requisitos orientado a objetos (AROO), el diseo orientado a objetos (DOO), el anlisis del dominio orientado a objetos (ADOO), sistemas de gestin de bases de dalos orientadas a objetos (SGBDOO) y la ingeniera del software orientada a objetos asistida por computadora (ISOOAC).

20.2.1. Clases y objetos Los conceptos fundamentales que llevan a un diseo de alta calidad (Captulo 13) son igualmente aplicables a sistemas desarrollados usando mtodos convencionales y orientados a objetos. Por esta razn, 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. Taylor [TAY90] usa la notacin que se muestra a la derecha de la Figura 20.4 para describir una clase (y objetos derivados de una clase).

20.2.2. Atributos Ya hemos visto que los atributos estn 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 estn a menudo descritas con palabras que indican caractersticas estables. La mayora de los objetos fsicos tienen caractersticas tales como forma, peso, color y tipo de material. Las personas tienen caractersticas como fecha de nacimiento, padres, nombre y color de los ojos. Una caracterstica puede verse como una relacin binaria entre una clase y cierto dominio. 20.2.3. Operaciones, mtodos y servicios Un objeto encapsula datos (representados como una coleccin de atributos) y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, mtodos o servicios' y pueden ser vistos como mdulos en un sentido convencional.

Los objetos se manifiestan de alguna de las formas y pueden ser: 1. entidades externas 2. cosas 3. ocurrencias o sucesos 4. papeles o roles 5. unidades organizacionales 6. lugares 7. estructuras

Coad y Yourdon [COA911 sugieren seis caractersticas de seleccin a usar cada vez que un analista considera si incluye o no un objeto potencial en el modelo de anlisis: 1-Informacin retenida: el objeto potencial ser de utilidad durante el anlisis solamente si la informacin 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 mltiples: durante el anlisis de requisitos, se debe centrar la atencin en la informacin principal (un objeto con un solo atributo puede, en efecto, ser til durante el diseo, pero seguramente ser mejor presentado como un atributo de otro objeto durante la actividad de anlisis); 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 informacin esencial para la produccin de cualquier solucin para el sistema, sern casi siempre definidas como objetos en el modelo de requisitos.

Cap. 21 Anlisis orientado a objetos

21.1 Anlisis 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 A00 pueden acoplarse con un enfoque de ingeniera de la informacin (Captulo 10) 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. 21.4 El proceso de AOO El proceso de A00 no comienza con una preocupacin por los objetos. Ms bien comienza con una comprensin de la manera en la que se usar el sistema: por las personas, si el sistema es de interaccin con el hombre; por otras mquinas, si el sistema est envuelto en un control de procesos; o por otros programas; si el sistema coordina y controla otras aplicaciones. Una vez que se ha definido el escenario, comienza el modelado del software. Las secciones que siguen definen una serie de tcnicas que pueden usarse para recopilar requisitos bsicos del usuario y despus definen un modelo de anlisis para un sistema orientado a objetos.

21.4.1. Casos de uso

Como examinamos en el Captulo 11, los casos de uso modelan el sistema desde el punto de vista del usuario. Creados durante la obtencin de requisitos, los casos de uso deben cumplir los siguientes objetivos: definir los requisitos funcionales y operativos del sistema (producto), diseando un escenario de uso acordado por el usuario final, y el equipo de desarrollo; proporcionar una descripcin clara y sin ambigedades de cmo el usuario final interacta con el sistema y viceversa, y comportamientos que se adaptan al escenario utilizado (casos de uso) del sistema.

Cap. 22 22.1 Diseos para orientados a objetos

sistemas

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. 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. 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. La capa de responsabilidades. Contiene estructuras de datos y diseos algortmicos, para todos los atributos y operaciones de cada objeto.

22.1.1. Enfoque convencional vs. O0

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.

Fichman y Kemerer [FIC92] sugieren diez componentes de diseo modelado, que pueden usarse para comparar varios mtodos convencionales y orientados a objetos:

1. representacin de la jerarqua de mdulos. 2. especificacin de las definiciones de datos.

3. especificacin de la lgica procedimental. 4. indicacin de secuencias de proceso final-a-final 5. representacin de estados y transiciones de los 6. definicin de clases y jerarquas. 7. asignacin de operaciones a las clases. 8. definicin detallada de operaciones. 9. especificacin de conexiones de mensajes. 10. identificacin de servicios exclusivos.

22.1.2. Aspectos del diseo Bertrand Meyer [MEY90] sugiere cinco criterios para juzgar la capacidad de mtodos de diseo para conseguir modularidad, y los relaciona al diseo orientado a objetos: 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. 22.1.3. El Panorama de DO0 Como se vio en el Capitulo 21, una gran variedad de mtodos de anlisis y diseo orientados a objetos fue propuesta y utilizada durante los ochenta y los noventa. Estos mtodos establecieron los fundamentos para la notacin moderna de DOO, heursticas de diseo y modelos. A continuacin, haremos una breve revisin global de los primeros mtodos de DOO: El mtodo de Booch. El mtodo Booch [B0094] abarca un proceso de micro desarrollo y un proceso de macro desarrollo. En el contexto del diseo, el macro desarrollo engloba El mtodo de Rumbaugh. La tcnica de modelado de objetos (TMO) [RUM91] engloba una actividad de diseo que alienta al diseo a ser conducido a dos diferentes niveles de abstraccin. El dise 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) [JAC92] 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.

El mtodo de Coad y Yourdon. ste mtodo para 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: El mtodo de Wirfs-Brock. Wirfs-Brock, Wilkerson y Weiner 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) Para llevar a cabo un diseo orientado a objetos, un ingeniero de software debe ejecutar las siguientes etapas generales: 1. 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 procedura1 para cada operacin, y estructuras de datos para los atributos de clase. 5. 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

22.2 Proceso de diseo del sistema El diseo de sistema desarrolla el detalle arquitectnico requerido para construir un sistema o producto. 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. Cules son las etapas del proceso de diseo de sistemas? 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 off

Buschmann y sus colegas [BUS961 sugieren el siguiente enfoque de diseo para estratificacin por capas:

1. Establecer los criterios de estratificacin por capas. Esto significa decidir cmo se agruparn los subsistemas en una arquitectura de capas. 2. Determinar el nmero de capas. Muchas de ellas complican innecesariamente; muy pocas debilitan la independencia funcional. 3. Nombrar las capas y asignar subsistemas (con sus clases encapsuladas) a una capa. Asegurarse de que la comunicacin entre subsistemas (clases) en una capa*, y otros subsistemas (clases) en otra capa, siguen la filosofa de diseo de la arquitectura. 4. Disear interfaces para cada capa. 5. Refinar los subsistemas, para establecer la estructura de clases para cada capa.