ISW-S21-Analisis Orientado 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 21 ANÁLISIS ORIENTADO

A OBJETOS Conocer y utilizar el paradigma Orientado a Objetos.

Análisis Orientado a Objetos

Wilbert Dalguerre ordóñez 1

Contenido

ANÁLISIS ORIENTADO A OBJETOS ............................................................ 2

ANÁLISIS ORIENTADO A OBJETOS ........................................................................................ 3

Enfoques convencionales y enfoques OO ............................................................................ 3

El panorama del AOO ........................................................................................................... 3

Un enfoque unificado para el AOO ...................................................................................... 5

ANÁLISIS DEL DOMINIO ........................................................................................................ 7

Análisis de reutilización y del dominio ................................................................................. 7

El proceso de análisis del dominio ....................................................................................... 8

COMPONENTES GENÉRICOS DEL MODELO DE ANÁLISIS OO ............................................. 10

EL PROCESO DEL ANÁLISIS OO ........................................................................................... 12

Casos de uso ....................................................................................................................... 12

Modelado de clases-responsabilidades-colaboraciones .................................................... 13

Clases .................................................................................................................................. 13

Responsabilidades .............................................................................................................. 15

Colaboradores .................................................................................................................... 17

Definición de estructuras y jerarquías ............................................................................... 19

Definición de subsistemas .................................................................................................. 19

EL MODELO OBJETO RELACIÓN .......................................................................................... 20

EL MODELO OBJETO COMPORTAMIENTO ......................................................................... 22

Identificación de sucesos con casos de uso ....................................................................... 22

Representaciones de estados ............................................................................................. 24

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



ANÁLISIS ORIENTADO A OBJETOS

Cuando se tiene que construir un nuevo producto o sistema,

¿cómo lo caracterizamos de forma tal que sea

tratado por la ingeniería del software orientado a

objetos? ¿Hay preguntas especiales que queramos

hacer al cliente? ¿Cuáles son los objetos relevantes? ¿Cómo

se relacionan entre sí? ¿Cómo se comportan los objetos en el contexto del sistema? ¿Cómo especificamos o modelamos un problema de forma tal que podamos crear un diseño eficaz? A cada una de estas interrogantes se responde dentro del contexto del análisis orientado a objetos (AOO), primera actividad técnica que se desarrolla como parte de la ingeniería del software OO. En lugar de examinar un problema utilizando el modelo de información clásico de flujo de datos, el A00 introduce varios conceptos nuevos. Coad y Yourdon consideran el tema cuando escriben: El A00 (Análisis Orientado a Objetos) se basa en conceptos que ya aprendimos en la guardería: objetos y atributos, clases y miembros, todos y partes. Por qué nos ha llevado tanto tiempo aplicar estos conceptos al análisis y especificación de sistemas es algo que nadie sabe a ciencia cierta... El A00 se basa en un conjunto de principios básicos. Para construir un modelo de análisis se aplican cinco principios básicos: (1) se modela el dominio de la información; (2) se describe la función; (3) se representa el comportamiento del modelo; (4) los modelos de datos, funcional y de comportamiento se dividen para mostrar más detalles; y (5) los modelos iniciales representan la esencia del problema mientras que los últimos aportan detalles de la implementación. El propósito del AOO es definir todas las clases que son relevantes al problema que se va a resolver, las operaciones y atributos asociados, las relaciones y comportamientos asociadas con ellas. Para cumplirlo se deben ejecutar las siguientes tareas:

1. Los requisitos básicos del usuario deben comunicarse entre el cliente y el ingeniero del software

2. Identificar las clases (es decir, definir atributos y métodos).



3. Se debe especificar una jerarquía 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.

ANÁLISIS ORIENTADO A OBJETOS

El objetivo del análisis 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 métodos de análisis convencional, forman un modelo de análisis multi-parte para satisfacer este objetivo. El modelo de análisis ilustra información, funcionamiento y comportamiento dentro del contexto de los elementos del modelo de objetos.

Enfoques convencionales y enfoques OO ¿Es el análisis orientado a objetos realmente diferente del enfoque del análisis estructurado? Aunque el debate continúa, Fichman y Kemerer responden a la pregunta directamente: Concluimos que el enfoque del análisis orientado a objetos representa un cambio radical sobre las metodologías orientadas a procesos, tales como el análisis estructurado, pero sólo un cambio incremental respecto a las metodologías orientadas a datos, tales como la ingeniería de la información. Las metodologías orientadas a procesos desvían la atención de las prioridades inherentes a los objetos durante el proceso de modelado y conducen a un modelo del dominio del problema ortogonal con los tres principios esenciales de la orientación a objetos: encapsulamiento, clasificación de objetos y herencia. Dicho simplemente, el análisis estructurado toma una visión diferente de los requisitos del modelo entrada-proceso-salida. Los datos se consideran separadamente de los procesos que los transforman. El comportamiento del sistema, aunque importante, tiende a desempeñar un papel secundario en el análisis estructurado. El análisis estructurado hace un fuerte uso de la descomposición funcional (partición del diagrama de flujo de datos).

El panorama del AOO La popularidad de las tecnologías de objetos ha generado docenas de métodos de A00 desde finales de los 80 y durante los 90. Cada uno de ellos introduce un proceso para el análisis de un producto o sistema, un conjunto de modelos que evoluciona fuera del proceso, y



una notación que posibilita al ingeniero del software crear cada modelo de una manera consistente. Entre los más ampliamente utilizados se encuentran.

El método de Booch. El método de Booch abarca un «micro proceso de desarrollo» y un «macro proceso de desarrollo». El nivel micro define un conjunto de tareas de análisis que se replican 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 semántica de dichas clases y objetos, define las relaciones entre clases y objetos y realiza una serie de refinamientos para elaborar el modelo del análisis. El método de Rumbaugh. Rumbaugh y sus colegas desarrollaron la Técnica de Modelado de Objetos (OMT) para el análisis, diseño del sistema y diseño a nivel de objetos. La actividad de análisis crea tres modelos: el modelo de objetos (una representación de objetos, clases, jerarquías y relaciones), el modelo dinámico (una representación del comportamiento del sistema y los objetos) y el modelo funcional (una representación a alto nivel del flujo de información a través del sistema similar al DFD).

El método de Jacobson. También llamado OOSE (en español Ingeniería del Software Orientada a Objetos), el método de Jacobson es una versión simplificada de Objectory, un método patentado, también desarrollado por Jacobson. Este método se diferencia de los otros por la importancia que da al caso de uso -una descripción o escenario que describe cómo el usuario interactúa con el producto o sistema-.

El método de Coad y Yourdon. El método de Coad y Yourdon se considera, con frecuencia, como uno de los métodos del A00 más sencillos de aprender. La notación del modelado es relativamente simple y las reglas para desarrollar el modelo de análisis son evidentes. A continuación sigue una descripción resumida del proceso de A00 de Coad y Yourdon:

1. Identificar objetos, usando el criterio de «qué buscar». 2. Definir una estructura de generalización-especificación. 3. Definir una estructura de todo-parte. 4. Identificar temas (representaciones de componentes de

subsistemas). 5. Definir atributos. 6. Definir servicios.

El método de Wirfs-Brock. El método de Wirfs- Brock no hace una distinción clara entre las tareas de análisis y diseño. En su lugar, propone un proceso continuo que comienza con la valoración de una



especificación del cliente y termina con el diseño. A continuación se esbozan brevemente las tareas relacionadas con el análisis de Wirfs-Brock: Evaluar la especificación del cliente.

1. Usar un análisis gramatical para extraer clases candidatas

de la especificación. 2. Agrupar las clases en un intento de determinar superclases. 3. Definir responsabilidades para cada clase. 4. Asignar responsabilidades a cada clase. 5. Identificar relaciones entre clases. 6. Definir colaboraciones entre clases basándose en sus

responsabilidades. 7. Construir representaciones jerárquicas de clases para

mostrar relaciones de herencia. 8. Construir un gafo de colaboraciones para el sistema.

Aunque la terminología y etapas del proceso para cada uno de estos métodos de AOO difieren, los procesos generales de A00 son en realidad muy similares. Para realizar un análisis orientado a objetos, un ingeniero del software debería ejecutar las siguientes etapas genéricas:

1. Obtener los requisitos del cliente para el sistema. 2. Identificar escenarios o casos de uso. 3. Seleccionar clases y objetos usando los requisitos básicos

como guías. 4. Identificar atributos y operaciones para cada objeto del

sistema. 5. Definir estructuras y jerarquías que organicen las clases. 6. Construir un modelo objeto-relación. 7. Construir un modelo objeto-comportamiento. 8. Revisar el modelo de análisis OO con relación a los casos

de uso/escenarios.

Un enfoque unificado para el AOO Al final de la pasada década, Grady Booch, James Rumbaugh e Ivar Jacobson empezaron a colaborar para combinar y recopilar las mejores características de cada uno de sus métodos de diseño y análisis orientado a objetos en un método unificado. El resultado, denominado Lenguaje de Modelado Unificado (UML), se ha convertido en el método más utilizado por la industria. UML permite a un ingeniero del software expresar un modelo de análisis utilizando una notación de modelado con unas reglas sintácticas, semánticas y prácticas. Eriksson y Penker definen dichas reglas de la siguiente forma:



La sintaxis nos dice cómo mostrar y combinar los símbolos. La sintaxis es comparable a las palabras en el lenguaje natural: Es importante saber cómo se escriben y cómo combinarlas correctamente para formar una frase. Las reglas semánticas nos dicen lo que significa cada símbolo y cómo interpretarlo, tanto cuando aparece solo como cuando lo hace en combinación con otros. Es comparable al significado de las palabras en el lenguaje natural.

Las reglas prácticas definen el significado de los símbolos a través de los cuales se obtiene el modelo y se hace comprensible para otras personas. Esto correspondería, en lenguaje natural, a las reglas de construcción de frases claras y fácilmente comprensibles.

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 están 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 representación del análisis, 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 estática (clases, objetos y relaciones).

Vista del comportamiento: esta parte del modelo del análisis representa los aspectos dinámicos o de comportamiento del sistema. También muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en las vistas anteriores.

Vista de implementación: 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. En general, el modelo de análisis de UML se centra en las vistas del usuario y estructural. El modelo de diseño de UML se dirige más a las vistas del comportamiento y del entorno.



ANÁLISIS DEL DOMINIO

El análisis en sistemas orientados a objetos puede ocurrir a muchos niveles

diferentes de abstracción. A nivel de negocios o empresas, las técnicas

asociadas con el AOO pueden acoplarse con un enfoque de

ingeniería de la información 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 específica de negocios (o una categoría de productos o sistemas). A nivel de las aplicaciones, el modelo de objetos se centra en los requisitos específicos del cliente, pues éstos afectan a la aplicación que se va a construir. A nivel de abstracción más bajo, el AOO cae dentro del alcance general de la ingeniería del software orientado a objetos. En esta sección nos centraremos en el AOO que se realiza a un nivel medio de abstracción. Esta actividad, llamada análisis del dominio, tiene lugar cuando una organización desea crear una biblioteca de clases reutilizables (componentes) ampliamente aplicables a una categoría completa de aplicaciones.

Análisis de reutilización y del dominio Las tecnologías de objetos están influenciadas por la reutilización. Considere un ejemplo simple. El análisis de los requisitos para nuevas aplicaciones indica la necesidad de 100 clases. Se les asigna a dos equipos la tarea de construir la aplicación. Cada uno debe diseñar 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 más bajo que el coste del producto del equipo A.

3. La versión que se distribuya del producto producido por el equipo B tendrá menos defectos que la del producto del equipo A.

Aunque el margen por el cual el trabajo del equipo B excederá al del A está abierto a debate, pocos argumentarán que la reusabilidad aporta una ventaja substancial al equipo B. ¿Pero de dónde vino la «biblioteca de clases robusta »? ¿Y cómo se determinó que las entradas de la biblioteca eran apropiadas para su uso en nuevas aplicaciones? Para responder estas preguntas, la organización que creó y mantuvo dicha biblioteca tuvo que aplicar el análisis del dominio.

El proceso de análisis del dominio Firesmith describe el análisis del dominio del software de la siguiente manera:

El análisis del dominio del software es la identificación, análisis y especificación de requisitos comunes de un dominio de aplicación específico, normalmente para su reutilización en múltiples proyectos dentro del mismo dominio de aplicación (el análisis orientado a objetos del dominio es la identificación, análisis y especificación de capacidades comunes y reutilizables dentro de un dominio de aplicación específico, en términos de objetos, clases, sub-montajes y marcos de trabajo comunes.

El «dominio de aplicaciones específico» puede variar desde aviónica hasta banca, desde juegos de vídeo multimedia hasta aplicaciones dentro de un escáner CAT. El objetivo del análisis del dominio es claro: encontrar o crear aquellas clases ampliamente aplicadas, de tal manera que sean reutilizables. Usando la terminología introducida al inicio del libro, el análisis del dominio puede verse como la actividad de cobertura para el proceso del software. Con esto queremos decir que el análisis del dominio es una actividad en curso de la ingeniería del software no ligada a ningún proyecto de software. En cierta forma, el papel de un análisis del dominio es similar al de un maestro tornero dentro de un entorno de fabricación fuerte. El trabajo del maestro tornero es diseñar y construir herramientas que pueden usarse por varias personas que trabajan en aplicaciones similares, pero no necesariamente idénticas. El papel del analista del dominio es diseñar y construir componentes reutilizables que puedan ser utilizados por diferentes personas que trabajan en aplicaciones similares pero no necesariamente iguales. Se examinan las fuentes del dominio de conocimiento en un intento de identificar objetos que se puedan



reutilizar a lo largo de todo el dominio. En esencia el análisis del dominio es muy similar a la ingeniería del conocimiento. El ingeniero del conocimiento investiga un área de interés específica, intentando extraer hechos claves que se puedan usar para la construcción de un sistema experto o una red neuronal artificial. Durante el análisis del dominio ocurre la extracción de objetos (y clases).

Definir el dominio a investigar. Para llevar a cabo esta tarea, el analista debe primero aislar el área de negocio, tipo de sistema o categoría del producto de interés. A continuación, se deben extraer los «elementos» tanto OO como no OO. Los elementos OO incluyen especificaciones, diseños y código para clases de aplicaciones OO ya existentes; clases de soporte (ejemplo: clases de Interfaz Gráfica 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 OO abarcan políticas, procedimientos, planes, estándares y guías; partes de aplicaciones no OO (incluyendo especificación, diseño e información de prueba), métricas y CYD del software no OO.

Clasificar los elementos extraídos del dominio. Los elementos se organizan en categorías y se establecen las características generales que definen la categoría. Se propone un esquema de clasificación para las categorías y se definen convenciones para la nomenclatura de cada elemento. Se establecen jerarquías de clasificación en caso de ser apropiado.

Recolectar una muestra representativa de aplicaciones en el dominio. Para realizar esta tarea, el analista debe asegurar que la aplicación en cuestión tiene elementos que caen dentro de las categorías ya definidas. Berard observa que durante las primeras etapas de uso de las tecnologías de objetos, una organización del software tendrá muy pocas, si hay alguna, aplicaciones OO. Debido a esto, el analista de dominio debe «identificar los objetos conceptuales (opuestos a los físicos) en cada aplicación no OO.

Analizar cada aplicación 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

identificado como reutilizable. 3. Definir adaptaciones al objeto que también pueden ser

reutilizables. 4. Estimar el porcentaje de aplicaciones en el dominio que

pueden reutilizar el objeto. 5. Identificar los objetos por nombre y usar técnicas de gestión

de configuración para controlarlos.



Además, una vez que se han definido los objetos, el analista debe estimar qué porcentaje de una aplicación típica pudiera construirse usando los objetos reutilizables.

Desarrollar un modelo de análisis para los objetos. El modelo de análisis servirá como base para el diseño y construcción de los objetos del dominio. Adicionalmente a estas etapas, el analista del dominio también debe crear un conjunto de líneas maestras para la reutilización, y desarrollar un ejemplo que ilustre cómo los objetos del dominio pudieran usarse para crear una aplicación nueva. El análisis del dominio es la primera actividad técnica en una amplia disciplina que algunos llaman ingeniería del dominio. Cuando un negocio, sistema o producto del dominio es definido como estratégico 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 ingeniería del dominio son: bajo coste, mayor calidad y menor tiempo de comercialización.

COMPONENTES GENÉRICOS DEL MODELO DE ANÁLISIS OO

El proceso de análisis orientado a objetos se adapta a

conceptos y principios básicos de análisis.

Aunque la terminología, notación y actividades

difieren respecto de los usados en métodos

convencionales, el AOO (en su núcleo) resuelve los mismos

objetivos subyacentes. Rumbaugh examina esto cuando

asegura que:

El análisis se ocupa de proyectar un modelo preciso, conciso, comprensible y correcto del mundo real. El propósito de Análisis Orientado a Objetos es modelar el mundo real de forma tal que sea comprensible. Para esto se deben examinar los requisitos, analizar las implicaciones que se deriven de ellos y reafirmarlos de manera rigurosa. Se deben abstraer primero las características del mundo real y dejar los pequeños detalles para más tarde.



Para desarrollar un «modelo preciso, conciso, comprensible y correcto del mundo real», un ingeniero del software debe seleccionar una notación que se soporte a un conjunto de componentes genéricos de AOO. Monarchi y Puhr definen un conjunto de componentes de representación genéricos que aparecen en todos los modelos de análisis OO. Los componentes estáticos son estructurales por naturaleza, e indican características que se mantienen durante toda la vida operativa de una aplicación. Los componentes dinámicos se centran en el control, y son sensibles al tiempo y al tratamiento de sucesos. Estos últimos definen cómo interactúa un objeto con otros a lo largo del tiempo. Pueden identificarse los siguientes componentes:

Vista estática de clases semánticas. Se imponen los requisitos y se extraen (y representan) las clases como parte del modelo de análisis. Estas clases persisten a través de todo el período de vida de la aplicación y se derivan basándose en la semántica de los requisitos del cliente.

Vista estática de los atributos. Toda clase debe describirse explícitamente. Los atributos asociados con la clase aportan una descripción de la clase, así como una indicación inicial de las operaciones relevantes a esta clase.

Vista estática de las relaciones. Los objetos están «conectados» unos a otros de varias formas. El modelo de análisis debe representar las relaciones de manera tal que puedan identificarse las operaciones (que afecten a estas conexiones) y que pueda desarrollarse un buen diseño de intercambio de mensajes. Vista estática 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 través de la definición de una secuencia de operaciones que los ejecutan.

Vista dinámica de la comunicación. Los objetos deben comunicarse unos con otros y hacerlo basándose en una serie de mensajes que provoquen transiciones de un estado a otro del sistema.

Vista dinámica del control y manejo del tiempo. Debe describirse la naturaleza y duración de los sucesos que provocan transiciones de estados. De Champeaux y sus colegas definen una vista ligeramente diferente de las representaciones del AOO. Las componentes estáticas y dinámicas se identifican para el objeto internamente y para las representaciones entre objetos. Una vista dinámica e interna del objeto puede caracterizarse como la historia de vida del objeto, esto



es, los estados que alcanza el objeto a lo largo del tiempo, al realizarse una serie de operaciones sobre sus atributos.

EL PROCESO DEL ANÁLISIS OO

El proceso de AOO no comienza con una preocupación por los objetos. Más bien comienza con una comprensión de la manera en la que se usará el sistema: por las personas, si el sistema es de interacción con el hombre; por otras máquinas, 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 técnicas que pueden usarse para recopilar requisitos básicos del usuario y después definen un modelo de análisis para un sistema orientado a objetos.

Casos de uso Los casos de uso modelan el sistema desde el punto de vista del usuario. Creados durante la obtención de requisitos, los casos de uso deben cumplir los siguientes objetivos: definir los requisitos funcionales y operativos del sistema (producto), diseñando un escenario de uso acordado por el usuario final, y el equipo de desarrollo; proporcionar una descripción clara y sin ambigüedades de cómo el usuario final interactúa con el sistema y viceversa, y proporcionar una base para la validación de las pruebas. Durante el AOO los casos de uso sirven como base para los primeros elementos del modelo de análisis. Utilizando UML se puede crear una representación visual de los casos de uso llamada diagrama de casos de uso. Como otros elementos del análisis, los casos de uso pueden representarse a diferentes niveles de abstracción. Los diagramas de casos de uso contienen casos de uso y actores, siendo estos últimos las entidades que interactúan con el sistema. Pueden ser humanos u otras máquinas o sistemas que tengan definidas interfaces con nuestro sistema.

El sistema de seguridad Hogar-Seguro, discutido en capítulos anteriores, puede usarse para ilustrar cómo pueden desarrollarse casos de uso. Recordando los requisitos básicos de Hogar-Seguro, podemos definir tres actores: el propietario (el usuario), los sensores (dispositivos adjuntos al sistema) y el subsistema de monitorización y respuesta (la estación central que monitoriza Hogar-Seguro). Un diagrama de casos de uso puede ser de alto nivel para y se representan con elipses. Cada caso de uso de alto nivel puede detallarse mediante diagramas de casos de uso de nivel inferior. Se



crea un conjunto completo de diagramas de casos de uso para todos los actores.

Modelado de clases-responsabilidades-colaboraciones Una vez que se han desarrollado los escenarios de uso básicos para el sistema, es el momento de identificar las clases candidatas e indicar sus responsabilidades y colaboraciones. El modelado de clases-responsabilidades-colaboraciones (CRC) aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto. Ambler describe el modelado CRC de la siguiente manera: Un modelo CRC es realmente una colección de tarjetas índice estándar que representan clases. Las tarjetas están 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. En realidad, el modelo CRC puede hacer uso de tarjetas índice virtuales o reales. El caso es desarrollar una representación organizada de las clases. Las responsabilidades son los atributos y operaciones relevantes para la clase. Puesto de forma simple, una responsabilidad es «cualquier cosa que conoce o hace la clase». Los colaboradores son aquellas clases necesarias para proveer a una clase con la información necesaria para completar una responsabilidad. En general, una colaboración implica una solicitud de información o una solicitud de alguna acción.

Clases Los objetos se manifiestan en una variedad de formas: entidades externas, cosas, ocurrencias o sucesos, roles, unidades organizativas, lugares, o estructuras. Una técnica para identificarlos en el contexto de un problema del software es realizar un análisis gramatical con la narrativa de procesamiento para el sistema. Todos los nombres se transforman en objetos potenciales. Sin embargo, no todo objeto potencial podrá incluirse en el modelo. Un objeto potencial debe satisfacer estas seis características para poder ser considerado como posible miembro del modelo:

1. Retener información: el objeto potencial será útil durante el

análisis si la información 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. Múltiples atributos: durante el análisis de requisitos nos centramos más en la información más importante. Un objeto con un solo atributo puede, en efecto, ser útil durante el



diseño, pero probablemente será un atributo de otro objeto durante el análisis 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 información esencial para la operación de una solución para el sistema casi siempre se definen como objetos en el modelo de requisitos.

Una clase potencial debe satisfacer las seis características de selección anteriores si va a ser incluida en el modelo CRC. Firesmith extiende las características de clasificación sugiriendo, además de las existentes, las siguientes:

1. Clases dispositivo. Modelan entidades externas tales como

sensores, motores y teclados. 2. Clases propiedad. Representan alguna propiedad importante

del entorno del problema (por ejemplo: establecimiento de créditos dentro del contexto de una aplicación de préstamos hipotecarios).

3. Clases interacción. Modelan interacciones que ocurren entre otros objetos (por ejemplo: una adquisición o una licencia).

Adicionalmente, los objetos y clases pueden clarificarse por un conjunto de características: Tangibilidad. ¿Representa la clase algo tangible o palpable (por ejemplo, un teclado o sensor), o representa información más abstracta (por ejemplo: una salida prevista)?

Inclusividad. ¿Es la clase atómica (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 la ejecución 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 a- sus recursos)?



Responsabilidades Las responsabilidades son los atributos y operaciones. Los atributos representan características estables de una clase, esto es, información sobre la clase que debe retenerse para llevar a cabo los objetivos del software especificados por el cliente. Los atributos pueden a menudo extraerse del planteamiento de alcance o discernirse a partir de la comprensión de la naturaleza de la clase. Las operaciones pueden extraerse desarrollando un análisis gramatical sobre la narrativa de procesamiento del sistema. Los verbos se transforman en candidatos a operaciones. Cada operación elegida para una clase exhibe un comportamiento de la clase. Wirfs-Brock y sus colegas sugieren cinco pautas para especificar responsabilidades para las clases:

1. La inteligencia del sistema debe distribuirse de manera

igualitaria. Toda aplicación encierra un cierto grado de inteligencia, por ejemplo, lo que sabe el sistema y lo que puede hacer. Esta inteligencia puede distribuirse ente las clases de varias maneras. Las clases «tontas» (aquellas con pocas responsabilidades) pueden modelarse de manera que actúen como sirvientes de unas pocas clases «listas» (aquellas con muchas responsabilidades). Aunque este enfoque hace que el flujo de control dentro de un sistema sea claro, posee algunas desventajas: (1) Concentra toda la inteligencia en pocas clases, haciendo los cambios más difíciles; (2) Tiende a necesitar más clases y por lo tanto el esfuerzo de desarrollo aumenta. Por esta razón, la inteligencia del sistema debe distribuirse de manera igualitaria entre las clases de una aplicación. Como cada objeto conoce y actúa obre algunos pocos elementos (generalmente bien definidos y claros), la cohesión del sistema se ve incrementada. Adicionalmente, los efectos colaterales provocados por cambios tienden a amortiguarse debido a que la inteligencia del sistema se ha descompuesto entre muchos objetos.

Para determinar si la inteligencia del sistema está distribuida equitativamente, las responsabilidades definidas en cada tarjeta índice del modelo CRC deben ser evaluadas para determinar si cada clase posee una lista de responsabilidades extraordinariamente grande. Esto indica una concentración de inteligencia. Además, las responsabilidades de cada clase deben mostrar el mismo nivel de abstracción. Por ejemplo, entre la lista de operaciones de una clase agregada llamada Comprobación de cuenta existen dos responsabilidades: saldo-de-la-cuenta y verificar-talones-cobrados. La primera operación (responsabilidad) implica un complejo procedimiento matemático y lógico. La segunda es una simple



actividad para empleados. Debido a que estas dos actividades no están al mismo nivel de abstracción, verificar-talones-cobrados debe situarse dentro de las responsabilidades de la clase Comprobación de entradas, la cual está contenida en la clase agregada Comprobación de cuenta.

2. Cada responsabilidad debe establecerse lo más general

posible. Esta directriz implica que las responsabilidades generales (tanto los atributos como las operaciones) deben residir en la parte alta de la jerarquía de clases (puesto que son genéricas, se aplicarán a todas las subclases). Adicionalmente, debe usarse el polimorfismo para definir las Operaciones que generalmente se aplica a la superclase, pero que se implementan de manera diferente en cada una de las subclases.

3. La información y el comportamiento asociado a ella, debe encontrarse dentro de la misma clase. Esto implementa el principio OO de encapsulamiento. Los datos y procesos que manipulan estos datos deben empaquetarse como una unidad cohesionada.

4. La información sobre un elemento debe estar localizada dentro de una clase, no distribuida a través de varias clases. Una clase simple debe asumir la responsabilidad de almacenamiento y manipulación de un tipo específico de información. Esta responsabilidad no debe compartirse, de manera general, entre varias clases. Si la información está distribuida, el software se torna más difícil de mantener y probar.

5. Compartir responsabilidades entre clases relacionadas cuando sea apropiado. Existen muchos casos en los cuales una gran variedad de objetos exhibe el mismo comportamiento al mismo tiempo. Como un ejemplo, considere un videojuego que debe mostrar los siguientes objetos: jugador, cuerpo-del-jugador, brazos-del-jugador, cabeza-del-jugador. Cada uno de estos atributos tiene sus propios atributos (ejemplo: posición, orientación, color, velocidad), y todos deben actualizarse y visualizarse al mover el usuario el joystick. Las responsabilidades actualizar y visualizar deben, por lo tanto, compartirse por los objetos señalados. El jugador sabe cuándo algo ha cambiado y se requiere actualizar; colabora con los otros objetos para alcanzar una nueva posición u orientación, pero cada objeto controla su propia visualización.



Colaboradores Las clases cumplen con sus responsabilidades de una de las dos siguientes maneras: (1) una clase puede usar sus propias operaciones para manipular sus propios atributos, cumpliendo por lo tanto con una responsabilidad particular, o (2) puede colaborar con otras clases. Wirfs-Brock y sus colegas definen las colaboraciones de la siguiente forma:

Las colaboraciones representan solicitudes de un cliente a un servidor en el cumplimiento de una responsabilidad del cliente. Una colaboración es la realización de un contrato entre el cliente y el servidor. Decimos que un objeto colabora con otro, si para ejecutar una responsabilidad necesita enviar cualquier mensaje al otro objeto. Una colaboración simple fluye en una dirección, representando una solicitud del cliente al servidor. Desde el punto de vista del cliente, cada una de sus colaboraciones está asociada con una responsabilidad particular implementada por el servidor.

Las colaboraciones identifican relaciones entre clases. Cuando todo un conjunto de clases colabora para satisfacer algún requisito, es posible organizarlas en un subsistema (un elemento del diseño).

Las colaboraciones se identifican determinando si una clase puede satisfacer cada responsabilidad. Si no puede, entonces necesita interactuar con otra clase. De aquí surge lo que hemos llamado una colaboración. Como un ejemplo, considere la aplicación Hogar-Seguro. Como una parte del procedimiento de activación, el objeto panel de control debe determinar si existen sensores abiertos. Se define una responsabilidad llamada determinar-estado-del-sensor. Si hay sensores abiertos, el panel de control debe poner el atributo estado al valor «no preparado». La información del sensor puede obtenerse del objeto sensor. Por lo tanto, la responsabilidad determinar-estado-del-sensor puede ejecutarse solamente si el panel de control trabaja en colaboración con el sensor.

Para ayudar en la identificación de colaboradores, el analista puede examinar tres relaciones genéricas diferentes entre clases: (1) la relación es-parte-de, (2) la relación tiene-conocimiento-sobre, y (3) la relación depende-de. A través de la creación de un diagrama de relación entre clases, el analista desarrolla las conexiones necesarias para identificar estas relaciones. Cada una de las tres relaciones genéricas se considera brevemente en los párrafos siguientes. Todas las clases que forman parte de una clase agregada están conectadas a ésta a través de una relación es parte- de. Considere las clases definidas para el juego de vídeo mencionado anteriormente, la clase cuerpo-del jugador es-parte-de, al igual que cuerpo-del-jugador, brazos-del-jugador y cabeza-del-jugador. Cuando una clase debe



obtener información sobre otra, se establece la relación tiene-conocimiento-sobre. La responsabilidad determinar-estado-del-sensor es un ejemplo de la relación tiene-conocimiento-sobre. La relación depende-de implica que dos clases poseen una dependencia no realizable a través de tiene-conocimiento- sobre o es-parte-de. Por ejemplo, la cabeza-del jugador debe estar siempre conectada al cuerpo del- jugador (a menos que el videojuego en particular sea muy violento), aunque cada objeto puede existir sin conocimiento directo sobre el otro. Un atributo del objeto cabeza-del-jugador llamado posición-central se obtiene de la posición-central del objeto cuerpo-del jugador. Esta información se obtiene a través de un tercer objeto, jugador, el cual la obtiene del cuerpo-del-jugador. Por lo tanto, la cabeza-del-jugador depende-de cuerpo-del-jugador.

En todos los casos, el nombre de la clase colaboradora se registra en la tarjeta índice del modelo CRC al lado de la responsabilidad que ha generado dicha colaboración. Por lo tanto, la tarjeta índice contiene una lista de responsabilidades y de colaboraciones correspondientes que posibilitan se realicen las responsabilidades su realización. Cuando se ha desarrollado un modelo CRC por completo, los representantes del cliente y de las organizaciones de ingeniería del software pueden recorrer el modelo haciendo uso del siguiente enfoque.

1. A todos los participantes de la revisión (del modelo CRC) se

les da un subconjunto de las tarjetas índice del modelo CRC. Las tarjetas que colaboran deben estar separadas (esto es, ningún revisor debe poseer dos tarjetas que colaboren).

2. Todos los escenarios (y sus correspondientes diagramas de casos de uso) deben organizarse en categorías.

3. El director de la revisión lee el caso de uso con atención. Cuando el director llega a un objeto identificado, se traspasa la señal a la persona que posee la clase tarjeta índice correspondiente. Por ejemplo, un caso de uso mencionado anteriormente contiene la siguiente narración:

El propietario de la casa observa el panel de control de Hogar-seguro para determinar si el sistema está listo para entrada de datos. Si el sistema no está listo, el propietario debe cerrar, físicamente, las ventanas y puertas para que aparezca el indicador de «listo». [Un indicador no listo implica que un sensor está abierto, esto es que una puerta o ventana está abierta.

Cuando el director de la revisión llega al «panel de control» en la narrativa del caso de uso, se pasa la señal a la persona que posee la tarjeta panel de control. La frase «implica que un sensor está abierto» requiere que la tarjeta índice contenga una responsabilidad que validará esta implicación (la responsabilidad determinar-estado-del-



sensor realiza esta acción). Al lado de la responsabilidad en la tarjeta índice está el colaborador sensor. La señal se pasa entonces al objeto sensor.

4. Cuando se pasa la señal, se le pide al que posee la tarjeta

de la clase que describa las responsabilidades mencionadas en la tarjeta. El grupo determina si una (o más) de las responsabilidades satisface el requisito del caso de uso.

5. Si las responsabilidades y colaboraciones mencionadas en las tarjetas índice no pueden acomodarse al caso de uso, se hacen modificaciones a las tarjetas. Esto puede incluir la definición de nuevas clases (y sus correspondientes tarjetas índice CRC) o la especificación de responsabilidades y colaboraciones nuevas o revisadas en tarjetas existentes.

Este modus operandi continúa hasta terminar el caso de uso. Cuando terminan todos los casos de uso, continúa el análisis OO.

Definición de estructuras y jerarquías Una vez que se han identificado las clases y objetos usando el modelo CRC, el analista comienza a centrarse en la estructura del modelo de clases y las jerarquías resultantes que surgen al emerger clases y subclases. Usando la notación UML podemos crear gran variedad de diagramas. Debe crearse una estructura de generalización- especialización para las clases identificadas. Para ilustrarlo considere el objeto sensor definido para Hogar-Seguro. Aquí, la generalización, sensor, se refina en un conjunto de especializaciones: sensor de entrada, sensor de humo y sensor de movimiento. Los atributos y operaciones identificados en el sensor son heredados por las especializaciones de la clase. Hemos creado una jerarquía de clases simple. En otros casos, un objeto representado según el modelo inicial puede estar compuesto realmente de un número de partes las cuales pueden definirse a su vez como objetos. Estos objetos agregados pueden representarse como una estructura componente-agregado y se definen usando una notación en la que el rombo implica una relación de ensamblaje. Las representaciones estructurales proveen al analista de los medios para particionar el modelo CRC y para representar esta partición gráficamente. La expansión de cada clase aporta los detalles necesarios para revisión y para el subsiguiente diseño.

Definición de subsistemas Un modelo de análisis para una aplicación compleja puede tener cientos de clases y docenas de estructuras. Por esta razón, es necesario definir una representación concisa que sea un resumen de



los modelos CRC y estructural descritos anteriormente. Los subconjuntos de clases que colaboran entre sí para llevar a cabo un conjunto de responsabilidades cohesionadas, se les llama normalmente subsistemas o paquetes (en terminología UML). Los subsistemas o paquetes son abstracciones que aportan una referencia o puntero a los detalles en el modelo de análisis. Si se observa desde el exterior, un subsistema puede tratarse como una caja negra que contiene un conjunto de responsabilidades y que posee sus propios colaboradores (externos). Un subsistema implementa uno o más contratos con sus colaboradores externos. Un contrato es una lista específica de solicitudes que los colaboradores pueden hacer a un subsistema. Los subsistemas pueden representarse dentro del contexto del modelo CRC creando una tarjeta índice del subsistema. La tarjeta índice del subsistema indica el nombre del subsistema, los contratos que debe cumplir y las clases u otros subsistemas que soportan el contrato. Los paquetes son idénticos a los subsistemas en intención y contenido, pero se representan gráficamente en UML. Por ejemplo, suponga que el panel de control de Hogar-Seguro, conteniendo múltiples monitores, una sofisticada distribución de teclas y otras características. Éste pudiera modelarse como una estructura todo-partes. Si el modelo de requisitos contuviera docenas de estas estructuras (Hogar-Seguro no las tendrá), sería difícil absorber la representación completa de una vez. Definiendo una referencia de temas, como se muestra en la figura, pudiera referenciarse toda la estructura a través de un simple icono (la carpeta de ficheros). Las referencias de paquetes se crean generalmente para cualquier estructura que posea múltiples objetos.

EL MODELO OBJETO RELACIÓN

El enfoque del modelado CRC usada en secciones anteriores ha establecido los primeros elementos de las relaciones

de clases y objetos. El primer paso en el establecimiento de

las relaciones es comprender las responsabilidades de cada clase.

La tarjeta índice del modelo CRC contiene una lista de

responsabilidades. El siguiente paso es definir aquellas clases

colaboradoras que ayudan en la realización de cada responsabilidad.

Esto establece la «conexión» entre las clases. Entre dos clases cualesquiera que



estén conectadas existe una relación. Debido a esto los colaboradores siempre están relacionados de alguna manera. El tipo de relación más común es la binaria (existe una relación entre dos clases). Cuando se analiza dentro del contexto de un sistema OO, una relación binaria posee una dirección específica que se define a partir de qué clase desempeña el papel del cliente y cuál actúa como servidor. Rumbaugh y sus colegas sugieren que las relaciones pueden derivarse a partir del examen de los verbos o frases verbales en el establecimiento del alcance o casos de uso para el sistema. Usando un análisis gramatical, el analista aísla verbos que indican localizaciones físicas o emplazamientos (cerca de, parte de, contenido en), comunicaciones (transmite a, obtenido de), propiedad (incorporado por, se compone de) y cumplimiento de una condición (dirige, coordina, controla). Estos aportan una indicación de la relación. La notación del lenguaje unificado de modelado para el modelo objeto-relación utiliza una simbología adaptada de las técnicas del modelo entidad-relación. En esencia, los objetos se conectan con otros objetos utilizando relaciones con nombres. Se especifica la cardinalidad de la conexión y se establece toda una red de relaciones. El modelo objeto-relación (como el modelo entidad relación) puede obtenerse en tres pasos o etapas:

1. Usando las tarjetas índice CRC, puede dibujarse una red de objetos colaboradores. Primero se dibujan los objetos conectados por líneas sin etiquetas que indican la existencia de alguna relación entre los objetos conectados. Una alternativa es mostrar los nombres de los roles de cada clase en la relación en lugar del nombre de la relación.

2. Revisando el modelo CRC de tarjetas índices, se evalúan responsabilidades y colaboradores y cada línea de conexión sin etiquetar recibe un nombre. Para evitar ambigüedades, una punta de flecha indica la «dirección» de la relación.

3. Una vez que se han establecido y nombrado las relaciones, se evalúa cada extremo para determinar la cardinalidad. Existen cuatro opciones: 0 a 1, 1 a 1, 0 a muchos, ó 1 a muchos. Por ejemplo, el sistema Hogur-Seguro contiene un único panel de control (la cardinalidad 1 lo indica). Al menos un sensor debe estar presente para que el panel de control lo active. Sin embargo, varios sensores pueden estar presentes (la relación 1 ..* lo indica). Un sensor puede reconocer 1 o más sucesos de sensor (ejemplo: se detecta humo u ocurre una caída, pues el símbolo 1..* lo indica).

Los pasos anteriormente mostrados continúan hasta que se produzca un modelo objeto-relación completo. En el desarrollo de un modelo objeto-relación, el analista añade aún alguna otra dimensión al modelo de análisis general. No solamente se identifican las relaciones entre objetos, sino que se definen todas las vías importantes de



mensajes. En nuestra descripción, hicimos referencia a las flechas que conectan símbolos de paquetes. También son vías de mensajes. Cada flecha implica el intercambio de mensajes entre subsistemas en el modelo.

EL MODELO OBJETO COMPORTAMIENTO

El modelo CRC y el de objeto-relación representan

elementos estáticos del modelo de análisis

OO. Ahora es el momento para hacer

una transición al comportamiento dinámico

del sistema o producto OO. Para ejecutar este paso

debemos representar el comportamiento del sistema

como una función de sucesos específicos y tiempo. El modelo

objeto- comportamiento indica cómo responderá un sistema OO a sucesos externos o estímulos. Para crear el modelo, el analista debe ejecutar los siguientes pasos:

1. Evaluar todos los casos de uso para comprender totalmente

la secuencia de interacción dentro del sistema. 2. Identificar sucesos que dirigen la secuencia de interacción y

comprender cómo estos sucesos se relacionan con objetos específicos.

3. Crear una traza de sucesos para cada caso de uso. 4. Construir un diagrama de transición de estados para el

sistema. 5. Revisar el modelo objeto-comportamiento para verificar

exactitud y consistencia.

Identificación de sucesos con casos de uso El caso de uso representa una secuencia de actividades que incluyen a actores y al sistema. En general, un suceso ocurre cada vez que un sistema OO y un actor (recuerde que un actor puede ser una persona, un dispositivo o incluso un sistema externo) intercambian información. Es importante recordar que un suceso es Booleano. Esto es, un suceso no es la información que se intercambia, es el hecho de que la información ha sido intercambiada. Un caso de uso se examina por



puntos de intercambio de información. Para ilustrarlo, reconsidere el caso de uso descrito a continuación:

1. El propietario observa el panel de control de Hogar-Seguro

para determinar si el sistema está listo para recibir datos. Si el sistema no está listo, el propietario debe cerrar físicamente ventanas y puertas de tal manera que el indicador de disponibilidad esté presente. [Un indicador de no preparado implica que el sensor está abierto, por ejemplo, que una puerta o ventana está abierta.]

2. El propietario usa el teclado para teclear una contraseña de cuatro dígitos. La contraseña se compara con la contraseña válida almacenada en el sistema. Si la contraseña es incorrecta, el panel de control avisará una vez y se restaurará por sí mismo para recibir datos adicionales. Si la contraseña es correcta, el panel de control espera por las acciones siguientes.

3. El propietario selecciona y teclea permanecer o continuar para activar el sistema. Permanecer activa solamente los sensores del perímetro (los sensores internos detectores de movimiento están desactivados). Continuar activa todos los sensores.

4. Cuando ocurre la activación, el propietario puede observar una luz roja de alarma.

Las partes de texto subrayadas anteriormente indican sucesos. Deberá identificarse un actor para cada suceso: la información que se intercambia debe anotarse. Y deberán indicarse otras condiciones o restricciones. Como ejemplo de un suceso típico, considere la frase subrayada del caso de uso propietario usa el teclado para teclear una contraseña de cuatro dígitos. En el contexto del modelo de análisis OO el actor propietario transmite un suceso al objeto panel de control. El suceso puede llamarse contraseña introducida. La información transferida son los cuatro dígitos que forman la contraseña, pero ésta no es una parte esencial del modelo de comportamiento. Es importante notar que algunos sucesos tienen un impacto explícito en el flujo de control del caso de uso, mientras que otros no impactan directamente en este flujo de control. Por ejemplo el suceso contraseña introducida no cambia explícitamente el flujo de control del caso de uso, pero los resultados del suceso comparar contraseña (derivada de la interacción contraseña se compara con la contraseña válida almacenada en el sistema) tendrá un impacto explícito en la información y flujo de control del software Hogar-Seguro. Una vez que todos los sucesos han sido identificados, se asocian a los objetos incluidos. Los actores (entidades externas) y objetos pueden responsabilizarse de la generación de sucesos (ejemplo: propietario genera el suceso contraseña introducida) o reconociendo sucesos



que han ocurrido en otra parte (ejemplo: el panel de control reconoce el resultado binario del suceso comparar contraseña).

Representaciones de estados En el contexto de sistemas OO deben considerarse dos caracterizaciones de estados: (1) el estado de cada objeto cuando el sistema ejecuta su función, y (2) el estado del sistema observado desde el exterior cuando éste ejecuta su función.

El estado de un objeto adquiere en ambos casos características pasivas y activas. Un estado pasivo es simplemente el estado actual de todos los atributos de un objeto. Por ejemplo, el estado pasivo del objeto agregado jugador (en la aplicación del videojuego examinado anteriormente) incluirá posición y orientación actual del jugador (atributos del objeto) así como otras características de jugador que son relevantes al juego (ejemplo: un atributo que indique permanecen deseos mágicos). El estado activo de un objeto indica el estado actual cuando éste entra en una transformación continua o proceso. El objeto jugador poseerá los siguientes estados activos: en movimiento, en descanso, lesionado, en recuperación, atrapado, perdido entre otros. Para forzar la transición de un objeto de un estado activo a otro debe ocurrir un suceso (a veces, llamado disparador). Un componente de un modelo objeto-comportamiento es una representación simple de los estados activos de cada objeto y los sucesos (disparadores) que producen los cambios entre estos estados activos. La Figura siguiente ilustra una representación simple de los estados activos para el objeto panel de control en el sistema HogarSeguro. Cada flecha en la Figura representa una transición de un estado activo del objeto a otro. Las etiquetas mostradas en cada flecha representan los sucesos que disparan la transición. Aunque el modelo de estado activo aporta una visión interna muy útil de la «historia de vida» de un objeto, es posible especificar información adicional para aportar más profundidad en la comprensión del comportamiento de un objeto. Adicionalmente a especificar el suceso que provoca la ocurrencia de la transición, el análisis puede también especificar una guarda y una acción. Una guarda es una condición Booleana, que debe satisfacerse para posibilitar la ocurrencia de una transición. Por ejemplo, la condición de guarda para la transición desde el estado «en descanso» al de «comparando» en la Figura puede determinarse a través del examen del caso de uso:

if (entrada de contraseña = 4 dígitos) then ejecutar transición al estado comparando;

En general, la guarda de una transición depende usualmente del valor de uno o más atributos de un objeto. En otras palabras, la condición



de guarda depende del estado pasivo del objeto. Una acción ocurre concurrentemente con la transición o como una consecuencia de ella y generalmente implica una o más operaciones (responsabilidades) del objeto. Por ejemplo, la acción conectada con el suceso contraseña introducida es una operación que accede a un objeto contraseña y realiza una comparación dígito a dígito para validar la contraseña introducida.

El segundo tipo de representación de comportamiento para el AOO considera una representación de estados para el producto general o sistema. Esta representación abarca un modelo simple de traza de sucesos que indica cómo los sucesos causan las transiciones de objeto a objeto y un diagrama de transición de estados que ilustra el comportamiento de cada objeto durante el procesamiento. Una vez que han sido identificados los sucesos para un caso de uso, el analista crea una representación acerca de cómo los sucesos provocan el flujo desde un objeto a otro. Esta representación, llamada traza de sucesos o de sucesos, es una versión abreviada del caso de uso que representa objetos clave y los sucesos que provocan el comportamiento de pasar de objeto a objeto.

UML utiliza diagramas de estado, de secuencia, de colaboración y de actividades para representar el comportamiento dinámico de los objetos y las clases identificadas como parte del modelo del análisis.



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&tbm=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=imghp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=software+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.140950.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb8&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.

Documents

ISW-S21-Analisis Orientado a Objetos