CAPTULO

21

ANLISIS ORIENTADO A OBJETOS

El A00 se basa en un conjunto de principios bsicos que se introdujeron en el Captulo 11.Para construir un modelo de anlisis se aplican cinco principios bsicos: (1) se modela el dominio de la informacin; (2) se describe la funcin; (3) se representa el comportamiento del modelo; (4) los modelos de datos, funcional y de comportamiento se dividen para mostrar ms detalles; (5) los modelos iniciales representan la esencia del problema mientras que los ltimos aportan detalles de la implementacin. Estos principios forman la base para el enfoque del A00 presentado en ese captulo. El propsito del A00 es definir todas las clases que son relevantes al problema que se va a resolver, las operaciones y atributos asokiados, 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.

En UML, un sistema viene representado por cinco vistas diferentes que lo describen desde diferentes perspectivas. Cada vista se representa mediante un conjunto de diagramas. En UML estn presentes las siguientes vistas: Vista del usuario. Representa el sistema (producto) desde la perspectiva de los usuarios (llamados actores en UML). El caso de uso es el enfoque elegido para modelar esta vista. Esta importante representacin del anlisis, que describe un escenario de uso desde la perspectiva del usuario final, Vista estructural: los datos y la funcionalidad se muestran desde dentro del sistema, es decir, modela la estructura esttica (clases, objetos y relaciones). Vista del comportamiento: esta parte del modelo del anlisis representa los aspectos dinmicos o de comportamiento del sistema. Tambin muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en las vistas anteriores Vista de implementacin: los aspectos estructurales y de comportamiento se representan aqu tal y como van a ser implementados. Vista del entorno: aspectos estructurales y de comportamiento en el que el sistema a implementar se representa. 21.2.1. 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 equipo A no tiene acceso a una biblioteca de clases, por lo que debe desarrollar las 100 clases desde el principio. El equipo B usa una biblioteca de clases robusta y encuentra que ya existen 55 clases. Seguro que: 1. El equipo B finalizar el proyecto mucho antes que el A. 2. El coste del producto del equipo B ser significativamente ms bajo que el coste del producto del equipo A.

3. La versin que se distribuya del producto producido por el equipo B tendr menos defectos que la del producto del equipo A. 21.2.2. El proceso de anlisis del dominio 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 Definir el dominio a investigar: Para llevar a cabo esta tarea, el analista debe primero aislar el rea de negocio, tipo de sistema o categora del producto de inters. A continuacin, se deben extraer los elementos tanto O0 como no OO. Los elementos O0 incluyen especificaciones, diseos y cdigo para clases de aplicaciones O0 ya existentes; clases de soporte (P.e.: clases de Interfaz Grfica de Usuario o clases de acceso a bases de datos); bibliotecas de componentes comerciales ya desarrolladas (CYD) relevantes al dominio y casos de prueba. Los elementos no O0 abarcan polticas, procedimientos, planes, estndares y guas; partes de aplicaciones no O0 (incluyendo especificacin, diseo e informacin de prueba), mtricas y CYD del software no OO. Clasificar los elementos extrados del dominio. Los elementos se organizan en categoras y se establecen las caractersticas generales que definen la categora. Se propone un esquema de clasificacin para las categoras y se definen convenciones para la nomenclatura de cada elemento. Se establecen jerarquas de clasificacin en caso de ser apropiado Recolectar una muestra representativa de aplicaciones en el dominio. Para realizar esta tarea, el analista debe asegurar que la aplicacin en cuestin tiene elementos que caen dentro de las categoras ya definidas Analizar cada aplicacin dentro de la muestra. El analista debe seguir las etapas siguientes:

(1) Identificar objetos candidatos reutilizables. (2) Indicar las razones que hacen que el objeto haya sido (3) identificado como reutilizable. (4) Definir adaptaciones al objeto que tambin pueden (5) ser reutilizables. (6) Estimar el porcentaje de aplicaciones en el dominio (7) que pueden reutilizar el objeto. (8) Identificar los objetos por nombre y usar tcnicas de (9) gestin de configuracin para controlarlos Desarrollar un modelo de anlisis para los objetos. El modelo de anlisis servir como base para el diseo y construccin de los objetos del dominio. Adicionalmente a estas etapas, el analista del dominio tambin debe crear un conjunto de lneas maestras para la reutilizacin, y desarrollar un ejemplo que ilustre cmo los objetos del dominio pudieran usarse para crear una aplicacin nueva. El anlisis del dominio es la primera actividad tcnica en una amplia disciplina que algunos llaman ingeniera del dominio. Cuando un negocio, sistema o producto del dominio es definido como estratgico a largo plazo, puede desarrollarse un esfuerzo continuado para crear una biblioteca reutilizable robusta. El objetivo es ser capaz de crear software dentro del dominio con un alto porcentaje de componentes reutilizables. Argumentos a favor de un esfuerzo dedicado a la ingeniera del dominio son: bajo coste, mayor calidad y menor tiempo de comercializacin. conjunto de componentes de representacin genricos que aparecen en todos los modelos de anlisis O05. Los componentes estticos son estructurales por naturaleza, e indican caractersticas que se mantienen durante toda la vida operativa de una aplicacin. Los componentes dinmicos se centran en el control, y son sensibles al tiempo y al tratamiento de sucesos. Vista esttica de clases semnticas. Una taxonoma de clases tpicas se mostr en el Captulo 20. Se imponen los requisitos y se extraen (y representan) las clases como parte del modelo de anlisis. Estas clases persisten a travs de

todo el perodo de vida de la aplicacin y se derivan basndose en la semntica de los requisitos del cliente. Vista esttica de los atributos. Toda clase debe describirse explcitamente. Los atributos asociados con la clase aportan una descripcin de la clase, as como una indicacin inicial de las operaciones relevantes a esta clase. Vista esttica de las relaciones. Los objetos estn conectados unos a otros de varias formas. El modelo de anlisis debe representar las relaciones de manera tal que puedan identificarse las operaciones (que afecten a estas conexiones) y que pueda desarrollarse un buen diseo de intercambio de mensajes. Vista esttica de los comportamientos. Las relaciones indicadas anteriormente definen un conjunto de comportamientos que se adaptan al escenario utilizado (casos de uso) del sistema. Estos comportamientos se implementan a travs de la definicin de una secuencia de operaciones que los ejecutan Vista dinmica de la comunicacin. Los objetos deben comunicarse unos con otros y hacerlo basndose en una serie de mensajes que provoquen transiciones de un estado a otro del sistema. Vista dinmica del control y manejo del tiempo. Debe describirse la naturaleza y duracin de los sucesos que provocan transiciones de estados. 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. 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 proporcionar una base para la validacin de las pruebas

Durante el A00 los casos de uso sirven como base para los primeros elementos del modelo de anlisis. Utilizando UML se puede crear una representacin visual de los casos de uso llamada diagrama de casos de uso. Como otros elementos del anlisis, los casos de uso pueden representarse a diferentes niveles de abstraccin. Los diagramas de casos de uso contienen casos de uso y actores, siendo estos ltimos las entidades que interactan con el sistema. Pueden ser humanos u otras mquinas o sistemas que tengan definidas interfaces con nuestro sistema. 21.4.2. Modelado de clases-responsabilidadescolaboraciones Una vez que se han desarrollado los escenarios de uso bsicos para el sistema, es el momento de identificar las clases candidatas e indicar sus responsabilidades y colaboraciones. El modelado de clasesresponsabilidadescolaboraciones (CRC) [WIR90] aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto. Describe el modelado CRC de la siguiente manera: Un modelo CRC es realmente una coleccin de tarjetas ndice estndar que representan clases. Las tarjetas estn divididas en tres secciones. A lo largo de la cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores. Un objeto potencial debe satisfacer estas seis caractersticas para poder ser considerado como posible miembro del modelo: 1. retener informacin: el objeto potencial ser til durante el anlisis si la informacin sobre el mismo debe guardarse para que el sistema funcione

2. Servicios necesarios: el potencial objeto debe tener un conjunto de operaciones identificables que permitan cambiar los valores de sus atributos. 3. Mltiples atributos: durante el anlisis de requisitos nos centramos ms en la informacin ms importante. Un objeto con un solo atributo puede, en efecto, ser til durante el diseo, pero probablemente ser un atributo de otro objeto durante el anlisis de actividades. 4. Atributos comunes: el conjunto de atributos definido para la clase debe ser aplicable a todas las ocurrencias del objeto 5. Operaciones comunes: el objeto potencial debe definir un conjunto de operaciones aplicables, al igual que antes, a todos los objetos de la clase. 6. Requisitos esenciales: las entidades externas que aparecen en el espacio del problema y producen informacin esencial para la operacin de una solucin para el sistema casi siempre se definen como objetos en el modelo de requisitos. Una clase potencial debe satisfacer las seis caractersticas de seleccin anteriores si va a ser incluida en el modelo CRC. Clases dispositivo. Modelan entidades externas tales como sensores, motores y teclados. Clases propiedad. Representan alguna propiedad importante del entorno del problema (por ejemplo: establecimiento de crditos dentro del contexto de una aplicacin de prstamos hipotecarios). Clases interaccin. Modelan interacciones que ocurren entre otros objetos (por ejemplo: una adquisicin o una licencia). Adicionalmente, los objetos y clases pueden clarificarse por un conjunto de caractersticas: Tungihilidad. Representa la clase algo tangible o palpable (por ejemplo, un teclado o sensor), o representa informacin ms abstracta (por ejemplo: una salida prevista)?

Inclusividad. Es la clase atmica (es decir, no incluye otras clases) o es agregada (incluye al menos un objeto anidado)? Secuencia. Es la clase concurrente (es decir posee su propio hilo de control) o secuencial (es controlada por recursos externos)? Persistencia. La clase es temporal (se crea durante !a ejecucin del programa y es eliminada una vez que ste termina), o permanente (es almacenada en una base de datos)? Integridad. Es la clase corrompible (es decir, no protege sus recursos de influencias externas) o es segura (la clase refuerza los controles de accesos asus recursos)? El modelo objeto-comportamiento indica cmo responder un sistema 00 a sucesos externos o estmulos. Para crear el modelo, el analista debe ejecutar los siguientes pasos: (1) 1.Evaluar todos los casos de uso (Seccin 21.4.1) para comprender totalmente la secuencia de interaccin dentro del sistema. (2) Identificar sucesos que dirigen la secuencia de interaccin y comprender cmo estos sucesos se relacionan con objetos especficos. (3) Crear una traza de sucesos [RUM91] para cada caso de uso. (4) Construir un diagrama de transicin de estados para el sistema. (5) Revisar el modelo objeto-comportamiento para verificar exactitud y consistencia. Los mtodos de A00 permiten a un ingeniero del software modelar un problema representando las caractersticas tanto dinmicas como estticas de las clases y sus relaciones como componentes principales del modelado. Como los mtodos precedentes, el lenguaje unificado de modelado UML construye un modelo de anlisis con las siguientes caractersticas: (1) representacin de las clases y jerarquas de clases, (2) creacin de modelos objeto-relacin, y (3) obtencin de modelos objeto comportamiento.

El anlisis de sistemas orientados a objetos se realiza a muchos niveles diferentes de abstraccin. En los niveles de empresa o de negocio las tcnicas asociadas con el anlisis se pueden conjugar con el enfoque de ingeniera del proceso de negocio. A estas tcnicas a menudo se las llama de anlisis del dominio. En el nivel de implementacin el modelo de objetos se centra en los requisitos especificados por el cliente tal y como stos afectan a la aplicacin a construir. El proceso de A00 comienza con la definicin de casos de uso (escenarios que describen cmo se va a utilizar el sistema). La tcnica de modelado de clasesresponsabilidades- colaboraciones (CRC) se aplica para documentar las clases y sus atributos y operaciones. Tambin proporciona una vista inicial de las colaboraciones que ocurren entre los objetos. El siguiente paso en el A00 es la clasificacin de objetos y la creacin de una jerarqua de clases. Los sistemas (paquetes) se pueden utilizar para encapsular objetos relacionados. El modelo objeto-relacin proporciona informacin sobre las conexiones entre las clases, mientras que el modelo objeto-comportamiento representa el comportamiento de los objetos individualmente y el global de todo el sistema.