Ingeniería del Software - 5ta Edición - Roger S. Pressman

hwttwp:w//l.iberlesroialu-ucniiovnerasritiaor.ina.ebtlogspot.com

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

Es importante observar que no existe un acuerdo universal sobre los «conceptos»que sirven de base para el AOO,
pero un limitado número de ideas clave se repten a menudo, y son éstas las que consideraremosen este capítulo.

El objetivo del análisis orientado a objetos es desarro- El método de Booch. El método de Booch [B0094]
llar una serie de modelos que describan el software de abarca un amicroproceso de desarrollo» y un «macro-
computadora al trabajar para satisfacer un conjunto de proceso de desarrollo». El nivel micro define un conjunto
requisitos definidos por el cliente. El AOO, como los de tareas de análisis que se reaplican en cada etapa en el
métodos de análisis convencional descritos en el Capí- macro proceso. Por esto se mantienen un enfoque evo-
tulo 12, forman un modelo de análisis multiparte para lutivo. El micro proceso de desarrollo identifica clases y
satisfacer este objetivo. El modelo de análisis ilustra objetos y la semántica de dichas clases y objetos, define
información, funcionamiento y comportamiento dentro las relaciones entre clases y objetosy realiza una serie de
del contexto de los elementos del modelo de objetos refinamientospara elaborar el modelo del análisis.
descrito en el Capítulo 20.

21.1.1. Enfoques convencionales y enfoques O0 con objetos www.elsolucionario.net

¿Es el análisis orientado a objetos realmente diferente del ación como
ení 'que del análisis estructuradopresentado en el Capí-
tul1 12?Aunque el debate continúa, Fichman y Keme- El método de Rumbaugh. Rumbaugh [RUM91] y
rer FIC921 responden a la pregunta directamente: sus colegas desarrollaron la Técnica de Modelado de
Objetos (OMT) para el análisis, diseño del sistema y
Concluimos que el enfoque del análisis orientado a obje- diseño a nivel de objetos. La actividad de análisis crea
tos...representa un cambioradical sobrelasmetodologíasorien- tres modelos: el modelo de objetos (una representación
tadas a procesos, tales como el análisis estructurado,pero sólo de objetos, clases, jerarquías y relaciones), el modelo
un cambio incremental respecto a las metodologíasorientadas dinámico (una representación del comportamiento del
a datos, tales como la ingeniería de la información. Las m e t e sistema y los objetos) y el modelo funcional (una repre-
dologías orientadas a procesos desvían la atención de las prio- sentación a alto nivel del flujo de información a través
ridades inherentesa los objetos duranteel proceso de modelado del sistema similar al DFD).
y conducen a un modelo del dominio del problema ortogonal
con los tres principios esenciales de la orientación a objetos: El método de Jacobson. También llamado OOSE
encapsulamiento, clasificaciónde objetos y herencia. (en español Ingeniería del Software Orientada a Obje-
tos), el método de Jacobson [JAC92]es una versión sim-
Dicho simplemente,el análisis estructuradotoma una plificada de Objectory, un método patentado, también
visión diferente de los requisitos del modelo entrada- desarrollado por Jacobson. Este método se diferencia de
proceso-salida. Los datos se consideran separadamente los otros por la importancia que da al caso de uso- u n a
de los procesos que los transforman. El comportamien- descripción o escenario que describe cómo el usuario
to del sistema, aunque importante, tiende a desempeñar interactúa con el producto o sistema-.
un papel secundario en el análisis estructurado. El aná-
lisis estructurado hace un fuerte uso de la descomposi- El método de Coad y Yourdon. El método de Coad
ción funcional (partición del diagrama de flujo de datos, y Yourdon [COA911 se considera, con frecuencia, como
Capítulo 12). uno de los métodos del A 0 0 más sencillos de apren-
der. La notación del modelado es relativamente simple
21.1.2. El panorama del A 0 0 y las reglas para desarrollar el modelo de análisis son
evidentes. A continuación sigue una descripción resu-
La popularidad de las tecnologías de objetos ha gene- mida del proceso de A 0 0 de Coad y Yourdon:
rado docenas de métodos de A 0 0 desde finales de los
80 y durante los 90'. Cada uno de ellos introduce un Identificar objetos,usando el criterio de «qué buscar».
proceso para el análisis de un producto o sistema, un Definir una estructura de generalización-especifi-
conjunto de modelos que evoluciona fuera del proceso, cación.
y una notación que posibilita al ingeniero del software
crear cada modelo de una manera consistente. Entre los En general, los métodos de A 0 0 se identifican usando el (o los)
más ampliamente utilizados se encuentran': nombre($ del desarrollador del método, incluso si al método se le
ha dado un nombre o acrónimo único
' iadiscusión detallada de estos métodos y sus diferencias esta fuera

del alcance en este libro. Además, la industria se mueve hacia una
forma de modelado unificada en un único método, lo que hace que
las discusiones sobre los antiguos métodos sólo tengan sentido a
efectos históricos. El lector interesado puede consultar a Berard
[BER92]y Graham [GRA94]para una comparación más detallada.

362

www.elsolucionario.net CAPfTULO 21 ANALISIS ORIENTADO A OBJETOS
.

Definir una estructura de todo-parte. 21.1.3. Un enfoque unificado para el A 0 0 www.elsolucionario.net
Al final de la pasada década, Grady Booch, James Rum-
Identificar temas (representaciones de componentes baugh e Ivar Jacobson empezaron a colaborar para com-
de subsistemas). binar y recopilar las mejores características de cada uno
de sus métodos de diseño y análisis orientado a objetos
Definir atributos. en un método unificado. El resultado, denominado Len-
Definir servicios. guaje de Modelado Unificado (UML), se ha convertido
en el método más utilizado por la industria3.
El método de Wirfs-Brock. El método de Wirfs-
Brock [WIR90] no hace una distinción clara entre las UML permite a un ingeniero del software expresar
tareas de análisis y diseño. En su lugar, propone un pro- un modelo de análisis utilizando una notación de mode-
ceso continuo que comienza con la valoración de una lado con unas reglas sintácticas, semánticas y prácticas.
especificación del cliente y termina con el diseño. A Eriksson y Penker [ERI98] definen dichas reglas de la
continuación se esbozan brevemente las tareas relacio- siguiente forma:,
nadas con el análisis de Wirfs-Brock:
La sintaxis nos dice cómo mostrar y combinar los sím-
Evaluar la especificación del cliente. bolos. La sintaxis es comparable a las palabras en el lenguaje
Usar un análisis gramatical para extraer clases can- natural: es importante saber cómo se escriben y cómo com-
didatas de la especificación. binarlas correctamente para formar una frase. Las regias
Agrupar las clases en un intento de determinar super- semánticas nos dicen lo que significa cada símbolo y cómo
clases. interpretarlo, tanto cuando aparece solo como cuando 10 hace
Definir responsabilidades para cada clase. en combinación con otros. Es comparable al significado de
Asignar responsabilidades a cada clase. las palabras en el lenguaje natural.
Identificar relaciones entre clases.
Definir colaboraciones entre clases basándose en sus Las reglas prácticas definen el significadode los símbolos
responsabilidades. a través de los cuales se obtiene el modelo y se hace com-
Construir representacionesjerárquicas de clases para prensible para otras personas. Esto correspondería, en lengua-
mostrar relaciones de herencia. je natural, a las regias de construcción de frases claras y
Construir un g a f o de colaboracionespara el sistema. fácilmente comprensibles.

Aunque la terminologíay etapas del proceso para cada En UML, un sistema viene representado por cinco
uno de estos métodos deAOO difieren, los procesos gene- vistas diferentes que lo describen desde diferentes pers-
rales de A 0 0 son en realidad muy similares. Para reali- pectivas. Cada vista se representa mediante un conjun-
zar un análisis orientado a objetos, un ingeniero del to de diagramas. En UML están presentes las siguientes
softwaredebería ejecutar las siguientes etapas genéricas: vistas [ALH98]:
1. Obtener los requisitos del cliente para el sistema.
2. Identificar escenarios o casos de uso. Vista del usuario. Representa el sistema (producto)
3. Seleccionar clases y objetos usando los requisitos desde la perspectiva de los usuarios (llamados actores
en UML). El caso de uso es el enfoque elegido para
básicos como guías. modelar esta vista. Esta importante representación del
4. Identificar atributos y operaciones para cada objeto análisis, que describe un escenario de uso desde la pers-
pectiva del usuario final, se describió en el capítulo 114.
del sistema.
5. Definir estructuras y jerarquías que organicen las Vista estructural: los datos y la funcionalidad se
muestran desde dentro del sistema, es decir, modela la
clases. estructura estática (clases, objetos y relaciones).
6. Construir un modelo objeto-relación.
7. Construir un modelo objeto-comportamiento.
8. Revisar el modelo de análisis O 0 con relación a los

casos de usoJescenarios.

Estas etapas genéricas se tratan en mayor detalle en
las Seccionés 21.3 y 21.4.

Durante el A00 se aplico un conjunto genérico de pasos, Corno en todos los enfoquesde onálisis, lo obtención
independientemente del método de anblisis elegido.
de requisitos es lo clove. Asegúrese de que obtiene

lo vista correctadel usuario. El resto soldrá solo.

Booch, Rumbaugh y Jacobson han publicado una trilogía funda- 'Si aún no lo ha hecho, lea por favor la discusión sobre los casos de
mental de libros sobre UML.El lector interesado puede consultar
[B0099l, [RUM99l y UAC99l. uso de la Sección 1 1.2.4.

363

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

Vista del comportamiento:esta parte del modelo del Vista de implementación: los aspectos estructurales
análisis representa los aspectos dinámicos o de com- y de comportamientose representan aquí tal y como van
portamiento del sistema. También muestra las interac- a ser implementados.
ciones o colaboraciones entre los diversos elementos
estructurales descritos en las vistas anteriores. Vista del entorno: aspectos estructurales y de com-
portamiento en el que el sistema a implementar se repre-
’-Referencia Web/ senta.

En mini.net/tetus/oo-umI.html hay un amplio En general, el modelo de análisis de UML se centra
tutorial y una lista de recursos UML que incluye en las vistas del usuario y estructural.El modelo de dise-
herramientas, ortículos y ejemplos. ño de UML (tratado en el Capítulo 22) se dirige más a
las vistas del comportamiento y del entorno. En el Capí-
tulo 22 describiremos UML con más detalle.

O

El análisis en sistemas orientados a objetos puede ocu- la necesidad de 100 clases. Se le asigna a dos equipos www.elsolucionario.net
rrir a muchos niveles diferentes de abstracción. A nivel la tarea de construir la aplicación. Cada uno debe dise-
de negocios o empresas, las técnicas asociadas con el ñar y construir un producto final y, a su vez, está com-
A 0 0 pueden acoplarse con un enfoque de ingeniería puesto de personas con el mismo nivel de habilidad y
de la información (Capítulo 10)en un esfuerzo por defi- experiencia.
nir clases, objetos, relaciones y comportamientos que
modelen el negocio por completo. A nivel de áreas de Otrosbeneficios derivodosde /ureutilizuciánson
negocios, puede definirse un modelo de objetos que des- lo consistencioy la fumiliuridod. los putrones dentro
criba el trabajo de un área específica de negocios (o una
categoría de productos o sistemas). A nivel de las apli- del suhure serán más consistentes, tendiendo
caciones, el modelo de objetos se centra en los requisi- o fucilitur el montenimientodel producto. Asegúresede
tos específicos del cliente, pues éstos afectan a la estoblecer un conjunto de regla de reutilizocián
aplicación que se va a construir. poro conseguir dichos objetivos.

a$$ El equipo A no tiene acceso a una biblioteca de cla-
ses, por lo que debe desarrollar las 100 clases desde
CUVE el principio. El equipo B usa una biblioteca de clases
robusta y encuentra que ya existen 55 clases. Seguro
El objetivodel unálisisdel dominio es definir el conjunto que:
de cluses (objetosl que se encuentronen el dominio de
lo oplicucián. Dichus doses podrán reutilizorse muchos veces. 1. El equipo B finalizará el proyecto mucho antes que
el A.
El AOO, en su nivel de abstracción más alto (el nivel
de empresa), está más allá del alcance de este libro. Los 2. El coste del producto del equipo B será significati-
lectores interesados deberían ver a [EEL98], [CAR98], vamente más bajo que el coste del producto del
[FIN96], [MAT94], [SUL94] y [TAY95], los cuales equipo A.
hacen un análisis más detallado. A nivel de abstracción
más bajo, el A 0 0 cae dentro del alcance general de la 3. La versión que se distribuya del producto producido
ingeniería del software orientado a objetos y es el cen- por el equipo B tendrá menos defectos que la del pro-
tro de atención del resto de las secciones de este capí- ducto del equipo A.
tulo. En esta sección nos centraremos en el A 0 0 que
se realiza a un nivel medio de abstracción. Esta activi- Aunque el margen por el cual el trabajo del equipo
dad, llamada análisis del dominio, tiene lugar cuando B excederá al del A está abierto a debate, pocos argu-
una organización desea crear una biblioteca de clases mentarán que la reusabilidad aporta una ventaja subs-
reutilizables (componentes) ampliamente aplicables a tancial al equipo B.
una categoría completa de aplicaciones.
¿Pero de dónde vino la «biblioteca de clases robus-
21.2.1. Análisis de reutilización y del dominio ta»? ¿Y cómo se determinó que las entradas de la biblio-
teca eran apropiadas para su uso en nuevas aplicaciones?
Las tecnologías de objetos están influenciadas por la Para responder estas preguntas, la organización que creó
reutilización. Considere un ejemplo simple. El análi- y mantuvo dicha biblioteca tuvo que aplicar el análisis
sis de los requisitos para nuevas aplicaciones indican del dominio.

364

www.elsolucionario.net CAPfTULO 21 ANALISIS ORIENTADO A OBJETOS
.

21.2.2. El proceso de análisis del dominio La Figura 21.1 [ARA891 ilustra las entradas y sali- www.elsolucionario.net
Firesmith [FIR93] describe el análisis del dominio del das clave para el proceso de análisis del dominio. Se exa-
software de la siguiente manera: minan las fuentes del dominio de conocimiento en un
intento de identificar objetos que se puedan reutilizar a
El análisis del dominio del software es la identificación, lo largo de todo el dominio. En esencia el análisis del
análisis y especificación de requisitoscomunes de un domi- dominio es muy similar a la ingeniería del conocimien-
nio de aplicación específico, normalmente para su reutili- to. El ingeniero del conocimiento investiga un área de
zación en múltiples proyectos dentro del mismo dominio interés específica, intentando extraer hechos claves que
se puedan usar para la construcciónde un sistema exper-
de aplicación... (el análisis orientado a objetos del domi- to o una red neurona1 artificial. Durante el análisis del
dominio ocurre la extracción de objetos (y clases).
nio es la identificación, análisis y especificación de capa-
cidades comunes y reutilizables dentro de un dominio de Definir el dominio a investigar. Para llevar a cabo
aplicación específico, en términos de objetos, clases, sub- esta tarea, el analistadebe primero aislar el área de nego-
montajes y marcos de trabajo comunes... cio, tipo de sistema o categoría del producto de interés.
A continuación, se deben extraer los «elementos» tanto
El «dominio de aplicaciones específico» puede O 0 como no OO. Los elementos O 0 incluyen especifi-
variar desde aviónica hasta banca, desde juegos de caciones, diseños y código para clases de aplicaciones
vídeo multimedia hasta aplicaciones dentro de un escá- O 0 ya existentes;clases de soporte(P.e.: clases de Inter-
ner CAT. El objetivo del análisis del dominio es cla- faz Gráfica de Usuario o clases de acceso a bases de
ro: encontrar o crear aquellas clases ampliamente datos); bibliotecas de componentes comerciales ya desa-
aplicadas, de tal manera que sean reutilizables. rrolladas (CYD) relevantes al dominio y casos de prueba.
Los elementos no O 0 abarcan políticas, procedimien-
Usando la terminología introducida al inicio del tos, planes, estándares y guías; partes de aplicacionesno
libro, el análisis del dominio puede verse como la acti- O 0 (incluyendoespecificación,diseño e informaciónde
vidad de cobertura para el proceso del software. Con prueba), métricas y CYD del software no OO.
esto queremos decir que el análisis del dominio es una
actividad en curso de la ingeniería del software no Clasificarlos elementosextraídos del dominio. Los
ligada a ningún proyecto de software. En cierta for- elementos se organizan en categorías y se establecen las
ma, el papel de un análisis del dominio es similar al características generales que definen la categoría. Se
de un maestro tornero dentro de un entorno de fabri- propone un esquema de clasificación para las catego-
cación fuerte. El trabajo del maestro tornero es dise- rías y se definen convenciones para la nomenclatura de
ñar y construir herramientas que pueden usarse por cada elemento. Se establecenjerarquías de clasificación
varias personas que trabajan en aplicaciones simila- en caso de ser apropiado.
res, pero no necesariamente idénticas. El papel del
analista del dominio es diseñar y construir compo-
nentes reutilizables que puedan ser utilizados por dife-
rentes personas que trabajan en aplicaciones similares
pero no necesariamente iguales.

Fuentes Aplicaciones existentes Taxonomía de clases w
de Recursos del cliente Estándar de reusabilidad
Consejo de experto Modelos funcionales w Modelo
domimio Requisitos actuales/futuros Lenguajes del dominio del
del
análisis
:onocimiento
del
-* dominio
_.

FIGURA 21.1. Entrada y salida para análisis del dominio.

365

www.elsolucionario.net

.

INCENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

Recolectar una muestra representativade aplica- Además, una vez que se han definido los objetos, el www.elsolucionario.net
ciones en el dominio. Para realizar esta tarea, el ana- analista debe estimar qué porcentaje de una aplicación
lista debe asegurar que la aplicación en cuestión tiene típica pudiera construirse usando los objetos reutilizables.
elementos que caen dentro de las categorías ya defini-
das. Berard [BER93] observa que durante las primeras Desarrollar un modelo de análisis para los obje-
etapas de uso de las tecnologías de objetos, una orga- tos. El modelo de análisis servirá como base para el
nización del software tendrá muy pocas, si hay alguna, diseño y construcción de los objetos del dominio.
aplicaciones OO. Debido a esto, el analista de dominio
debe «identificar los objetos conceptuales (opuestos a Adicionalmente a estas etapas, el analista del domi-
los físicos) en cada aplicación [no 001~. nio también debe crear un conjunto de líneas maestras
para la reutilización, y desarrollar un ejemplo que ilus-
Analizar cada aplicación dentro de la muestra. El tre cómo los objetos del dominio pudieran usarse para
analista debe seguir las etapas siguientes [BER93]: crear una aplicación nueva.

Identificar objetos candidatos reutilizables. El análisis del dominio es la primera actividad téc-
nica en una amplia disciplina que algunos llaman inge-
Indicar las razones que hacen que el objeto haya sido niería del dominio. Cuando un negocio, sistema o
identificado como reutilizable. producto del dominio es definido como estratégico a
largo plazo, puede desarrollarse un esfuerzo continua-
Definir adaptaciones al objeto que también pueden do para crear una biblioteca reutilizablerobusta. El obje-
ser reutilizables. tivo es ser capaz de crear software dentro del dominio
con un alto porcentaje de componentes reutilizables.
Estimar el porcentaje de aplicaciones en el dominio Argumentos a favor de un esfuerzo dedicado a la inge-
que pueden reutilizar el objeto. niería del dominio son: bajo coste, mayor calidad y
menor tiempo de comercialización.
Identificar los objetos por nombre y usar técnicas de
gestión de configuraciónpara controlarlos (Capítulo 9). 3Referencia Web

En www.sei.cmu.edu/str/descriptions/dedo.html
hoy un tutoriol sobre análisis del dominio que merece lo peno.

El proceso de análisis orientado a objetos se adapta a componentes de representación genéricos que apare-
conceptos y principios básicos de análisis discutidos en cen en todos los modelos de análisis O 0 5 .Los compo-
el Capítulo 11.Aunque la terminología, notación y acti- nentes estáticos son estructurales por naturaleza, e
vidades difieren respecto de los usados en métodos con- indican características que se mantienen durante toda
vencionales,el A 0 0 (en su núcleo) resuelve los mismos la vida operativa de una aplicación. Los componentes
objetivos subyacentes. Rumbaugh [RUM911 examina dinámicos se centran en el control, y son sensibles al
esto cuando asegura que: tiempo y al tratamiento de sucesos. Estos últimos defi-
nen cómo interactúa un objeto con otros a lo largo del
El análisis... se ocupa de proyectar un modelo preciso, con- tiempo. Pueden identificarse los siguientes componen-
ciso, comprensible y correcto del mundo real. ...El propósito tes [MON92]:
de análisisOrientadoa objetoses modelar el mundo real de for-
ma tal que sea comprensible. Para esto se deben examinar los Vistaestática de clases semánticas. Una taxonomía de
requisitos, analizar las implicacionesque se deriven de ellos y clases típicas se mostró en el Capítulo 20. Se imponen los
reafirmarlos de manera rigurosa. Se deben abstraer primero las requisitos y se extraen (y representan) las clases como
características del mundo real y dejar los pequeños detalles parte del modelo de análisis. Estas clases persisten a tra-
para más tarde. vés de todo el período de vida de la aplicación y se deri-
van basándose en la semántica de los requisitos del cliente.
Para desarrollar un «modelo preciso, conciso, com-
prensible y correcto del mundo real», un ingeniero del ¿Cuáles son los componentes
software debe seleccionar una notación que se sopor- clave de un modelo de AOO?
te a un conjunto de componentes genéricos de AOO.
Monarchi y Puhr [MON92] definen un conjunto de

Los autores [MON92] aportan también un análisis de veintitrésméto-
dos de A 0 0 e indican cómo representan éstos dichas componentes.

366

httpw://lwibwre.reial-suonliuvecrisointaarirai.ob.lnogestpot.com
.

CAPITULO 21 ANALISIS ORIENTADO A OBJETOS

a$$ portamientos que se adaptan al escenarioutilizado (casos www.elsolucionario.net
de uso) del sistema. Estos comportamientos se imple-
CLAVE mentan a través de la definición de una secuencia de
operaciones que los ejecutan.
Los componentes estáticos no cambian mientras
Vista dinámica de la comunicación. Los objetos
la aplicación se está eiecutando. las componentes deben comunicarse unos con otros y hacerlo basándose
dinámicos están influenciadospor el tiempo y los sucesos. en una serie de mensajes que provoquen transiciones de
un estado a otro del sistema.
Vista estática de los atributos. Toda clase debe des-
cribirse explícitamente. Los atributos asociados con la Vistadinámica del control y manejo del tiempo. Debe
clase aportan una descripción de la clase, así como una describirse la naturaleza y duración de los sucesos que
indicación inicial de las operaciones relevantes a esta provocan transiciones de estados.
clase.
De Champeaux y sus colegas [CHA93] definen una
Vista estática de las relaciones. Los objetos están vista ligeramente diferente de las representaciones del
«conectados»unos a otros de varias formas. El modelo AOO. Las componentes estáticas y dinámicas se
de análisis debe representar las relaciones de manera tal identifican para el objeto internamente y para las
que puedan identificarse las operaciones (que afecten a representaciones entre objetos. Una vista dinámica e
estas conexiones) y que pueda desarrollarse un buen interna del objeto puede caracterizarse como la historia
diseño de intercambio de mensajes. de vida del objeto, esto es, los estados que alcanza el
objeto a lo largo del tiempo, al realizarse una serie de
Vista estática de los comportamientos. Las relacio- operaciones sobre sus atributos.
nes indicadas anteriormente definen un conjunto de com-

21.4 PRbC-O . .- < . ..,i . , .:. . ..

I.

El proceso de A 0 0 no comienza con una preocupación proporcionar una base para la validación de las
por los objetos. Más bien comienza con una compren-
sión de la manera en la que se usará el sistema: por las pruebas.
personas, si el sistema es de interacción con el hombre;
por otras máquinas, si el sistema está envuelto en un Durante el A 0 0 los casos de uso sirven como base
control de procesos; o por otros programas; si el siste- para los primeros elementos del modelo de análisis.
ma coordina y controla otras aplicaciones. Una vez que
se ha definido el escenario, comienza el modelado del Utilizando UML se puede crear una representación
software. visual de los casos de uso llamada diagrama de casos
de uso. Como otros elementos del análisis, los casos de
Las secciones que siguen definen una serie de técni- uso pueden representarse a diferentes niveles de abs-
cas que pueden usarse para recopilar requisitos básicos tracción. Los diagramas de casos de uso contienen casos
del usuario y después definen un modelo de análisis para de uso y actores, siendo estos últimos las entidades que
un sistema orientado a objetos. interactúan con el sistema. Pueden ser humanos u otras
máquinas o sistemas que tengan definidas interfacescon
nuestro sistema.

21.4.1. Casos de uso 3Referencia Web
Como examinamos en el Capítulo 11, los casos de uso
modelan el sistema desde el punto de vista del usuario. En www.univ-paris 1.fr/CRINFO/dmrg/MEE/misopO14
Creados durante la obtención de requisitos, los casos de existe un tutorial que aborda en profundidad los casos de uso.
uso deben cumplir los siguientes objetivos:
El sistema de seguridad HogarSeguro, discutido en
definir los requisitos funcionalesy operativosdel sis- capítulos anteriores,puede usarse para ilustrar cómo pue-
tema (producto), diseñandoun escenario de uso acor- den desarrollarse casos de uso. Recordando los requisi-
dado por el usuario final, y el equipo de desarrollo; tos básicos de HogarSeguro, podemos definir tres
proporcionar una descripción clara y sin ambigüe- actores: el propietario (el usuario), los sensores (dis-
dades de cómo el usuario final interactúa con el sis- positivos adjuntos al sistema) y el subsistemade moni-
tema y viceversa, y torización y respuesta (la estación central que
monitoriza HogarSeguro). Para los propósitos de este
los casos de usa son una excdmte herramientade ejemplo, consideraremos solamente el actor propietario.
licitotión de requisitos, indepenrbentemente del método de
onálisis utilizado. Véme el capítulo 11 para más detalle. La Figura 21.2.a muestra un diagrama de casos de
uso de alto nivel para el propietario. En dicha figura

367

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

se identifican dos casos de uso y se representan con elip- facer estas seis características para poder ser conside- www.elsolucionario.net
ses. Cada caso de uso de alto nivel puede detallarse rado como posible miembro del modelo:
mediante diagramas de casos de uso de nivel inferior. 1. retener información: el objeto potencial será útil
Por ejemplo, la Figura 21.2.b representa un diagrama
de casos de uso para la función interactúa. Se crea un durante el análisis si la información sobre el mismo
conjunto completo de diagramas de casos de uso para debe guardarse para que el sistema funcione
todos los actores. Pero para una detallada discusión sobre 2. Servicios necesarios: el potencial objeto debe tener
los casos de uso usando UML es mejor consultar la un conjunto de operaciones identificables que per-
bibliografía sobre el tema (P.e. [ERI97] o [ALH98J). mitan cambiar los valores de sus atributos.
3. Múltiples atributos: durante el análisis de requisitos
21.4.2. Modelado de clases-responsabilidades- nos centramos más en la información más impor-
colaboraciones tante. Un objeto con un solo atributo puede, en efecto,
ser Útil durante el diseño, pero probablemente será
Una vez que se han desarrollado los escenarios de uso un atributo de otro objeto durante el análisis de acti-
básicos para el sistema, es el momento de identificar las vidades.
clases candidatas e indicar sus responsabilidadesy cola- 4 . Atributos comunes: el conjunto de atributos definido
boraciones. El modelado de clases-responsabilidades- para la clase debe ser aplicable a todas las ocurren-
colaboraciones (CRC) [WIR90]aporta un medio sencillo cias del objeto.
de identificary organizar las clases que resulten relevantes
al sistema o requisitos del producto. Ambler [AMB95] K # gHogarseguro
describe el modelado CRC de la siguiente manera: I

Un modelo CRC es realmente una colección de tarjetas Propietario
índice estándar que representan clases. Las tarjetas están divi-
didas en tres secciones. A lo largo de la cabecera de la tarjeta (a)
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.

'Referencia Web/

En www.univ-parisl .fr/CRINFO/dmrg/MEE97/misop013
puede consultor uno discusión detalloda de lo técnico de las torjetos CRC.

En realidad, el modelo CRC puede hacer uso de tar- contraseña contraseña
jetas índice virtuales o reales. El caso es desarrollar una
representación organizada de las clases. Las responsa- K
bilidades son los atributosy operacionesrelevantespara
la clase. Puesto de forma simple, una responsabilidad Propietario
es «cualquier cosa que conoce o hace la clase»
[AMB95J. Los colaboradores son aquellas clases nece- Act ¡var/
sarias para proveer a una clase con la información nece- desactivar
saria para completar una responsabilidad. En general,
una colaboración implica una solicitud de información sistema
o una solicitud de alguna acción. íb)

Clases FIGURA 21.2. a) Diagrama de casos de uso de alto nivel.
b) Diagrama de casos de uso detallado.
Las pautas básicas para identificar clases y objetos se
presentaron en el Capítulo 20. Resumiendo, los objetos
se manifiestan en una variedad de formas (Sección
20.3.1): entidades externas, cosas, ocurrencias o suce-
sos, roles, unidades organizativas, lugares, o estmctu-
ras. Una técnica para identificarlos en el contexto de un
problema del software es realizar un análisis gramati-
cal con la narrativa de procesamiento para el sistema.
Todos los nombres se transforman en objetos potencia-
les. Sin embargo, no todo objeto potencial podrá
incluirse en el modelo. Un objeto potencial debe satis-

368

www.elsolucionario.net CAPfTULO 21 ANALISIS ORIENTADO A OBJETOS
.

¿Cómo determinar si merece la Responsabilidades www.elsolucionario.net
pena incluir un objeto potencial
en una tarjeta índice CRC? Las pautas básicas para identificar responsabilidades
(atributos y operaciones) también fueron presentadas
5. Operaciones comunes: el objeto potencial debe defi- en el Capítulo 20. Para resumir, los atributos represen-
nir un conjunto de operaciones aplicables, al igual tan características estables de una clase, esto es, infor-
que antes, a todos los objetos de la clase. mación sobre la clase que debe retenerse para llevar a
cabo los objetivos del software especificados por el
6. Requisitos esenciales: las entidadesexternas que apa- cliente. Los atributos pueden a menudo extraerse del
recen en el espacio del problema y producen infor- planteamiento de alcance o discernirse a partir de la
mación esencial para la operación de una solución comprensión de la naturaleza de la clase. Las opera-
para el sistema casi siempre se definen como obje- ciones pueden extraerse desarrollandoun análisis gra-
tos en el modelo de requisitos. matical sobre la narrativa de procesamientodel sistema.
Los verbos se transforman en candidatosa operaciones.
Una clase potencial debe satisfacer las seis caracte- Cada operación elegida para una clase exhibe un com-
rísticas de selección anteriores si va a ser incluida en el portamiento de la clase.
modelo CRC.
%
Firesmith [FiR93] extiende las característicasde cla- CLAVE
sificación sugiriendo, además de las existentes, las
siguientes: las responsabilidades de una clase incluyen tanto a los
atributos como a las operaciones.
Clases dispositivo. Modelan entidades externas tales
como sensores, motores y teclados. Wirfs-Brock y sus colegas [WIR90] sugieren cinco
pautas para especificarresponsabilidades para las clases:
Clases propiedad. Representan alguna propiedad 1. La inteligencia del sistema debe distribuirse de
importante del entorno del problema (por ejemplo: esta-
blecimiento de créditos dentro del contexto de una apli- manera igualitaria.Toda aplicaciónencierra un cierto
cación de préstamos hipotecarios). grado de inteligencia,por ejemplo, lo que sabe el sis-
tema y lo que puede hacer. Esta inteligencia puede
Clases interacción. Modelan interacciones que ocu- distribuirse ente las clases de varias maneras. Las
rren entre otros objetos (por ejemplo: una adquisición o clases «tontas» (aquellas con pocas responsabilida-
una licencia). des) pueden modelarse de manera que actúen como
sirvientesde unas pocas clases «listas» (aquellas con
, ¿Hay alguna manera de clasificar muchas responsabilidades). Aunque este enfoque
hace que el flujo de control dentro de un sistema sea
las clases? ¿Qué características claro, posee algunas desventajas: (1) Concentra toda
nos ayudan a hacerlo? la inteligenciaen pocas clases, haciendo los cambios
más difíciles; (2) Tiende a necesitar más clases y por
Adicionalmente, los objetos y clases pueden clarifi- lo tanto el esfuerzo de desarrollo aumenta.
carse por un conjunto de características:
¿Cómo asignar responsabilidades
Tungihilidad. ¿Representa la clase algo tangible o a una clase?
palpable (por ejemplo, un teclado o sensor), o repre-
senta informaciónmás abstracta (por ejemplo: una salida Por esta razón, la inteligencia del sistema debe
prevista)? distribuirse de manera igualitariaentre las clases de
una aplicación. Como cada objeto conoce y actúa
Inclusividad. ¿Es la clase atómica (es decir, no sobre algunos pocos elementos (generalmente bien
incluye otras clases) o es agregada (incluye al menos definidos y claros), la cohesión del sistema se ve
un objeto anidado)? incrementada. Adicionalmente, los efectos colatera-
les provocados por cambios tienden a amortiguarse
Secuencia. ¿Es la clase concurrente (es decir posee debido a que la inteligencia del sistema se ha des-
su propio hilo de control) o secuencial (es controlada compuesto entre muchos objetos.
por recursos externos)?
Si una clase tiene una listo excesivamentelarga de
Persistencia. La clase es temporal (se crea durante respansabilidades, ial vez debetíaconsiderarsesu división
!a ejecución del programa y es eliminada una vez que en varias clases menores.
éste termina), o permanente (es almacenada en una base
de datos)?

Integridad. ¿Es la clase corrompible (es decir, no pro-
tege sus recursos de influencias externas) o es segura (la
clase refuerza los controles de accesos a-sus recursos)?

Usando estas categorías de clases, pueden ampliar-
se las «tarjetas índice» creadas como parte del modelo
CRC para incluir el tipo de la clase y sus característi-
cas (Fig. 21.3).

369

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

Para determinar si la inteligencia del sistema está sabilidad no debe compartirse, de manera general, www.elsolucionario.net
distribuida equitativamente, las responsabilidades entre varias clases. Si la información está distri-
definidas en cada tarjeta índice del modelo CRC buida, el software se torna más difícil de mantener
deben ser evaluadas para determinar si cada clase y probar.
posee una lista de responsabilidades extraordina-
riamente grande. Esto indica una concentración de 5. Compartir responsabilidades entre clases relacio-
inteligencia. Además, las responsabilidades de cada nadas cuando sea apropiado. Existen muchos casos
clase deben mostrar el mismo nivel de abstracción. en los cuales una gran variedad de objetos exhibe el
Por ejemplo, entre la lista de operaciones de una mismo comportamiento al mismo tiempo. Como un
clase agregada llamada Comprobación de cuenta ejemplo, considere un videojuego que debe mostrar
existen dos responsabilidades: saldo-de-la-cuenta los siguientes objetos: jugador, cuerpo-del-juga-
y verificar-talones-cobrados. La primera operación dor, brazos-del-jugador,cabeza-del-jugador. Cada
(responsabilidad) implica un complejo procedi- uno de estos atributos tiene sus propios atributos (P.e.:
miento matemático y lógico. La segunda es una sim- posición, orientación, color, velocidad), y todos
ple actividad para empleados. Debido a que estas deben actualizarse y visualizarse al mover el usua-
dos actividades no están al mismo nivel de abs- rio el joystick. Las responsabilidades actualizar y
tracción, verificar-talones-cobrados debe situarse visualizar deben, por lo tanto, compartirse por los
dentro de las responsabilidades de la clase Com- objetos señalados. El jugador sabe cuándo algo ha
probación de entradas, la cual está contenida en cambiado y se requiere actualizar; colabora con los
la clase agregada Comprobación de cuenta. otros objetos para alcanzar una nueva posición u
orientación, pero cada objeto controla su propia
visualización.

FIGURA 21.3. Un modelo CRC de tarjeta índice. Colaboradores

2. Cada responsabilidaddebe establecerse lo más gene- Las clases cumplen con sus responsabilidades de una
ral posible. Esta directriz implica que las responsa- de las dos siguientes maneras: (1) una clase puede
bilidades generales (tanto los atributos como las usar sus propias operaciones para manipular sus pro-
operaciones)deben residir en la parte alta de la jerar- pios atributos, cumpliendo por lo tanto con una res-
quía de clases (puesto que son genéricas, se aplica- ponsabilidad particular, o (2) puede colaborar con
rán a todas las subclases). Adicionalmente, debe otras clases.
usarse el polimorfismo (Capítulo 20) para definir las
operaciones que generalmente se aplica a la super- Wirfs-Brock [WIR90] y sus colegas definen las cola-
clase, pero que se implementan de manera diferente boraciones de la siguiente forma:
en cada una de las subclases.
Las colaboraciones representan solicitudes de un cliente a
3 . La informacióny el comportamientoasociado a ella, un servidor en el cumplimiento de una responsabilidad del
debe encontrarse dentro de la misma clase. Esto cliente. Una colaboraciónes la realización de un contrato entre
implementa el principio O 0 de encapsulamiento
(Capítulo 20). Los datos y procesos que manipulan el cliente y el servidor...Decimos que un objeto colabora con
estos datos deben empaquetarse como una unidad
cohesionada. otro, si para ejecutar una responsabilidad necesita enviar cual-
quier mensaje al otro objeto. Una colaboración simplefluye en
4. La información sobre un elemento debe estar loca- una dirección, representando una solicitud del cliente al servi-
lizada dentro de una clase, no distribuida a través dor. Desde el punto de vista del cliente, cada una de sus cola-
de varias clases. Una clase simple debe asumir la boraciones está asociada con una responsabilidad particular
responsabilidad de almacenamiento y manipulación implementada por el servidor.
de un tipo específico de información. Esta respon-
Un objeto servidor colabora con un objetos cliente
en un esfuerzo por llevar o cabo una determinada
responsabilidad. la colaboración implica el paso de mensajes.

Las colaboraciones identifican relaciones entre cla-
ses. 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.

370

www.elsolucionario.net CAPfTULO 21 ANALISIS ORIENTADO A OBJETOS
.

Como un ejemplo, considere la aplicación Hogar- ¿Qué enfoque efectivo www.elsolucionario.net
Seguro6. Como una parte del procedimiento de activa- existe para revisar un
ción (vea el caso de uso para activación en la sección modelo CRC?
11.2.4), el objeto panel de control debe determinar si
existen sensores abiertos. Se define una responsabili- 1. A todos los participantes de la revisión (del modelo
dad llamada determinar-estado-del-sensor.Si hay sen- CRC) se les da un subconjunto de las tarjetas índice
sores abiertos, el panel de control debe poner el atributo del modelo CRC. Las tarjetas que colaboran deben
estado al valor «no preparado». La información del sen- estar separadas (esto es, ningún revisor debe poseer
sor puede obtenerse del objeto sensor. Por lo tanto, 13 dos tarjetas que colaboren).
responsabilidad determinar-estado-del-sensor puede
ejecutarse solamente si el panel de control trabaja en 2. Todos los escenarios (y sus correspondientes diagra-
colaboración con el sensor. mas de casos de uso) deben organizarse en categorías.

Para ayudar en la identificación de colaboradores, el 3. El director de la revisión lee el caso de uso con aten-
analista puede examinar tres relaciones genéricas dife- ción. Cuando el director llega a un objeto identifi-
rentes entre clases [WIR90]: (1) la relación es-parte-de, cado, se traspasa la señal a la persona que posee la
(2) la relación tiene-conocimiento-sobre, y ( 3 ) la rela- clase tarjeta índice correspondiente. Por ejemplo, el
ción depende-de. A través de la creación de un diagra- caso de uso mencionado en la Sección 20.4.1 con-
ma de relación entre clases (Sección 2 1.4.4), el analista tiene la siguiente narración:
desarrolla las conexiones necesarias para identificarestas
relaciones. Cada una de las tres relaciones genéricas se El propietario de la casa observa el panel de control de
considera brevemente en los párrafos siguientes. Hogarseguropara determinarsi el sistemaestá listo para entra-
da de datos. Si el sistema no está listo,el propietario debe cerrar,
Todas las clases que forman parte de una clase agre- físicamente, las ventanas y puertas para que aparezca el indi-
gada están conectadas a ésta a través de una relación es- cador de «listo». [Un indicador no listo implica que un sensor
parte-de. Considere las clases definidas para el juego de está abierto, esto es que una puerta o ventana está abierta.]
vídeo mencionado anteriormente, la clase cuerpo-del-
jugador es-parte-de, al igual que cuerpo-del-jugador, Cuando el director de la revisión llega al «panel de
brazos-del-jugador y cabeza-del-jugador. control» en la narrativa del caso de uso, se pasa la
señal a la persona que posee la tarjeta panel de con-
Cuando una clase debe obtener información sobre trol. La frase «implica que un sensor está abierto»
otra, se establece la relación tiene-conocimiento-sobre. requiere que la tarjeta índice contenga una respon-
La responsabilidad determinar-estado-del-sensores un sabilidad que validará esta implicación (la respon-
ejemplo de la relación tiene-conocimiento-sobre. La sabilidad determinar-estado-del-sensor realiza esta
relación depende-de implica que dos clases poseen una acción). Al lado de la responsabilidad en la tarjeta
dependencia no realizabl? a través de tiene-conoci- índice está el colaborador sensor. La señal se pasa
miento-sobre o es-parte-de. Por ejemplo, la cabeza-del- entonces al objeto sensor.
jugador debe estar siempre conectada al cuerpo-
del-jugador (a menos que el videojuego en particular 4. Cuando se pasa la señal, se le pide al que posee la
sea muy violento), aunque cada objeto puede existir sin tarjeta de la clase que describa las responsabilidades
conocimientodirecto sobre el otro. Un atributo del obje- mencionadas en la tarjeta. El grupo determina si una
to cabeza-del-jugador llamado posición-central se (o más) de las responsabilidades satisface el requi-
obtiene de la posición-central del objeto cuerpo-del- sito del caso de uso.
jugador. Esta información se obtiene a través de un ter-
cer objeto, jugador, el cual la obtiene del 5. Si las responsabilidades y colaboraciones mencio-
cuerpo-del-jugador. Por lo tanto, la cabeza-del-juga- nadas en las tarjetas índice no pueden acomodarse
dor depende-de cuerpo-del-jugador. al caso de uso, se hacen modificaciones a las tarje-
tas. Esto puede incluir la definición de nuevas cla-
En todos los casos, el nombre de la clase colaborado- ses (y sus correspondientes tarjetas índice CRC) o la
ra se registra en la tarjeta índice del modelo CRC al lado especificación de responsabilidades y colaboracio-
de la responsabilidad que ha generado dicha colabora- nes nuevas o revisadas en tarjetas existentes.
ción. Por lo tanto, la tarjeta índice contiene una lista de
responsabilidadesy de colaboracionescorrespondientes Este modus operandi continúa hasta terminar el caso
que posibilitan se realicen las responsabilidades su rea- de uso. Cuando terminan todos los casos de uso, conti-
lización (Fig. 21.3). núa el análisis OO.

Cuando se ha desarrolladoun modelo CRC por com- 21.4.3. Definición de estructuras y jerarquías
pleto, los representantes del cliente y de las organiza-
ciones de ingeniería del software pueden recorrer el Una vez que se han identificadolas clases y objetos usan-
modelo haciendo uso del siguiente enfoque. do el modelo CRC, el analista comienza a centrarse en
la estructura del modelo de clases y las jerarquías resul-

Vea una explicación de las clases de Hogarseguro en la Sección

20.3.

371

whtwtp:w//l.iebrlseroialu-ucnioivnearsritioar.inae.btlogspot.com

INGENIERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO .

tantes que surgen al emerger clases y subclases. Usan- menta uno o más contratos [WIR90] con sus colabo-
do la notación UML podemos crear gran variedad de radores externos. Un contrato es una lista específica
diagramas. Debe crearse una estructura de generuliza- de solicitudes que los colaboradores pueden hacer a
ción-especialización para las clases identificadas. un subsistema'.

Para ilustrarlo considere el objeto sensor definido u Tl.ElAtributosSensor
para HogarSeguro y mostrado en la Figura 21.4. Aquí,
la generalización, sensor, se refina en un conjunto de Operaciones
especializaciones: sensor de entrada, sensor de humo
y sensor de movimiento. Los atributos y operaciones de entrada de humo
identificados en el sensor son heredados por las espe-
cializaciones de la clase. Hemos creado una jerarquía FIGURA 21.4.a Diagrama de clases que ilustra la relación www.elsolucionario.net
de clases simple. de generalización-especialización.

En otros casos, un objeto representado según el Panel
modelo inicial puede estar compuesto realmente de un de control
número de partes las cuales pueden definirse a su vez
como objetos. Estos objetos agregados pueden repre- 1 1/ , /T\i 1 1Pantalla 1I
sentarse como una estructura componente-agregado Teclado
[ERI97] y se definen usando la notación representada ,\
en la Figura 21.5. El rombo implica una relación de
ensamblaje. Debe notarse que las líneas de conexión Luz
pueden aumentarse con símbolos adicionales (no mos-
trados) para representar cardinalidad, que se adaptan de FIGURA 21.5.a Diagrama de clases que ilustra la relación
la notación del modelo entidad-relación descrito en el de agregación.
Capítulo 12.
Los subsistemas pueden representarse dentro del
Las representaciones estructurales proveen al ana- contexto del modelo CRC creando una tarjeta índice
lista de los medios para particionar el modelo CRC y del subsistema. La tarjeta índice del subsistema indi-
para representar esta partición gráficamente. La expan- ca el nombre del subsistema, los contratos que debe
sión de cada clase aporta los detalles necesarios para cumplir y las clases u otros subsistemas que soportan
revisión y para el subsiguiente diseño. el contrato.

21.4.4. Definición de subsistemas Los paquetes son idénticos a los subsistemas en
intención y contenido, pero se representan gráfica-
Un modelo de análisis para una aplicación compleja pue- mente en UML. Por ejemplo, suponga que el panel de
de tener cientos de clases y docenas de estructuras. Por control de HogarSeguro es considerablemente más
esta razón, es necesario definir una representación con- complejo que el representado por la Figura 21.5, con-
cisa que sea un resumen de los modelos CRC y estruc- teniendo múltiples monitores, una sofisticada distri-
tural descritos anteriormente. bución de teclas y otras características. Éste pudiera
modelarse como una estructura todo-partes mostrada
a$$ en la Figura 21.6. Si el modelo de requisitos contu-
viera docenas de estas estructuras (HogarSeguro no
CLAVE las tendrá), sería difícil absorber la representación
completa de una vez. Definiendo una referencia de
Un subsistema (paquetede UMl) incluye una jerarquía
de clases más detalada.

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 refe-
rencia o puntero a los detalles en el modelo de análi-
sis. Si se observa desde el exterior, un subsistema
puede tratarse como una caja negra que contiene un
conjunto de responsabilidades y que posee sus pro-
pios colaboradores (externos). Un subsistema imple-

'Recuerde que las clases interactúan usando una filocofia clienteher-

vidor. En este caso el subsistema es el servidor y los colaboradores
externos los clientes.

372

www.elsolucionario.net CAPfTULO 21 ANALISIS ORIENTADO A OBJETOS
.

temas, como se muestra en la figura, pudiera referen- sensor (Figs. 21.5 y 21.6); para el sistema, suceso sen-
ciarse toda la estructura a través de un simple icono sor y alarma audible se crearán también estructuras si
(la carpeta de ficheros). Las referencias de paquetes estos objetos necesitan objetos ensamblados.
se crean generalmente para cualquier estructura que
posea múltiples objetos. Las flechas discontinuas mostradas en la parte supe-
rior de la Figura 21.7 representan relaciones de depen-
Al nivel más abstracto, el modelo de A 0 0 conten- dencia entre los paquetes que se muestran. Sensor
drá solamente referencias de paquetes tales como las depende del estado del paquete suceso sensor. Las fle-
que se ilustran al inicio de la Figura 21.7. Cada una de chas continuas representan composición. En el ejem-
las referencias se expandirá a una estructura. Se ilus- plo, el paquete sistema está compuesto por los paquetes
tran las estructuras para los objetos panel de control y panel de control, sensor y alarma audible.

El enfoque del modelado CRC usada en secciones ante- cPanel d e control Panel de control
riores ha establecido los primeros elementos de las rela-
ciones de clases y objetos. El primer paso en el Referencia www.elsolucionario.net
establecimientode las relaciones es comprender las res- subsistema
ponsabilidadesde cada clase. La tarjeta índice del mode- (paquete)
lo CRC contiene una lista de responsabilidades. El
siguiente paso es definir aquellas clases colaboradoras 114R1 \ \
que ayudan en la realización de cada responsabilidad.
Esto establece la «conexión» entre las clases. r l a d o defunción Pantalla

Entre dos clases cualesquiera que estén conectadas FIGURA 21.6. Referencia a paquete (subsistema).
existe una relación*. Debido a esto los colaboradores
siempre están relacionados de alguna manera. El tipo de El modelo objeto-relación (como el modelo entidad-
relación más común es la binaria (existe una relación relación) puede obtenerse en tres pasos o etapas:
entre dos clases). Cuando se analiza dentro del contexto 1 Usando las tarjetas índice CRC,puede dibujarse una
de un sistema 00,una relación binaria posee una direc-
ción específica’ que se define a partir de qué clase desem- red de objetos colaboradores. La Figura 21.8 repre-
peña el papel del cliente y cuál actúa como servidor. senta las conexiones de clase para los objetos de
Hogarseguro. Primero se dibujan los objetos conec-
Rumbaugh y sus colegas [RUM91] sugieren que las tados por líneas sin etiquetas (no se muestran en la
relaciones pueden derivarse a partir del examen de los figura) que indican la existencia de alguna relación
verbos o frases verbales en el establecimiento del alcan- entre los objetos conectados. Una alternativa es mos-
ce o casos de uso para el sistema. Usando un análisis trar los nombres de los roles de cada clase en la rela-
gramatical, el analista aísla verbos que indican locali- ción en lugar del nombre de la relación. Esto se
zaciones físicas o emplazamientos (cerca de,parte de, describe en el Capítulo 22.
contenido en), comunicaciones (transmite a, obtenido 2. Revisando el modelo CRC de tarjetas índices,se eva-
de),propiedad (incorporadopor, se compone de) y cum- lúan responsabilidadesy colaboradoresy cada línea
plimiento de una condición (dirige, coordina, contro- de conexión sin etiquetar recibe un nombre. Para evi-
la).Estos aportan una indicación de la relación. tar ambigüedades, una punta de flecha indica la
«dirección» de la relación (Fig. 21.8).
La notación del lenguaje unificado de modelado para 3 . Una vez que se han establecido y nombrado las rela-
el modelo objeto-relación utiliza una simbología adap- ciones,se evalúa cada extremopara determinar la car-
tada de las técnicas del modelo entidad-relaciónexami-
nadas en el Capítulo 12. En esencia, los objetos se
conectancon otros objetos utilizando relaciones con nom-
bres. Se especifica la cardinalidad de la conexión (ver
capítulo 12) y se establece toda una red de relaciones.

¿Cómo se obtiene un modelo
objeto-relación?

Otros términos para relación son asociación [RUM9 11 y conexión E s importante notar que esta es una salida de la naturaleza bidi-
reccional de las relaciones usadas en el modelado de datos (Capí-
[COA91]. tulo 12).

373

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

dinalidad (Fig. 21.8). Existen cuatro opciones: O a 1, Un panel de control controla uno o más sensores
1 a 1, O a muchos, ó 1 a muchos. Por ejemplo, el sis- y cada sensor es controlado por un panel de control
tema HogurSeguro contiene un único panel de control
(la cardinalidad 1 lo indica). Al menos un sensor debe 11.1
estar presente para que el panel de control lo active. Alarma audible
Sin embargo, varios sensores pueden estar presentes

(la relación 1..*lo indica). Un sensor puede reconocer

1o más sucesosde sensor (P.e.: se detectahumo u ocu-
rre una caída, pues el símbolo 1..* lo indica).

I Un sistema está formado por cero Ó más alarmas audibles
y una alarma audible está asociada con un único sistema
Evento de sensor

Alarma audible ~ FIGURA 21.8. Relaciones entre objetos. www.elsolucionario.net
Panel de control
Los pasos anteriormente mostrados continúan hasta
~~ que se produzca un modelo objeto-relación completo.

FIGURA 21.7. Modelo de análisis con referencias a paquetes. En el desarrollo de un modelo objeto-relación,el ana-
lista 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 impor-
tantes de mensajes (Capítulo 20). En nuestra descrip-
ción de la Figura 21.7, hicimos referencia a las flechas
que conectan símbolos de paquetes. También son vías
de mensajes. Cada flecha implica el intercambio de men-
sajes entre subsistemas en el modelo.

El modelo CRC y el de objeto-relaciónrepresentan ele- 5. Revisar el modelo objeto-comportamiento para veri-
mentos estáticos del modelo de análisis OO. Ahora es el ficar exactitud y consistencia.
momento para hacer una transición al comportamiento
dinámico del sistema o producto OO. Para ejecutar este Cada uno de estos pasos se discute en las secciones
paso debemos representar el comportamiento del siste- siguientes.
ma como una función de sucesos específicos y tiempo.
21.6.1. Identificaciónde sucesos con casos de uso
¿Cuáles son los posos
Como vimos en la Sección 21.4.1, el caso de uso
o seguir poro construir un representa una secuencia de actividades que incluyen
modelo objetos-tomportomiento? a actores y al sistema. En general, un suceso ocurre
cada vez que un sistema 00 y un actor (recuerde que
El modelo objeto-comportamiento indica cómo res- un actor puede ser una persona, un dispositivo o inclu-
ponderá un sistema 00 a sucesos externos o estímulos. so un sistema externo) intercambian información.
Para crear el modelo, el analista debe ejecutar los Recordando la explicación dada en el Capítulo 12, es
siguientes pasos: importante recordar que un suceso es Booleano. Esto
1. Evaluar todos los casos de uso (Sección 21.4.1) para es, un suceso no es la información que se intercam-
bia, es el hecho de que la información ha sido inter-
comprender totalmente la secuencia de interacción cambiada.
dentro del sistema.
2. Identificar sucesos que dirigen la secuencia de inter- Un caso de uso se examina por puntos de intercam-
acción y comprendercómo estos sucesos se relacionan bio de información. Para ilustrarlo, reconsidere el caso
con objetos específicos. de uso descrito en la Sección 11.2.4:
3. Crear una traza de sucesos [RUM91] para cada caso
de uso. 1. El propietario observa el panel de control de Hopariiepuro
4. Construir un diagrama de transición de estados para (Figura 11.2) para determinar si el sistema está listo para
el sistema. 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

374

www.elsolucionario.net CAPfTlJl.0 21 ANALISIS ORIENTADO A GBIETOS
.

no preparado implica que el sensor está abierto, por ejem- agregadojugador (en la aplicación del videojuego exa- www.elsolucionario.net
plo, que una puerta o ventana está abierta.] minado anteriormente) incluirá posición y orientación
actual del jugador (atributos del objeto) así como otras
2. El urouietario usa el teclado para teclear una contraseña de características de jugador que son relevantes al juego
cuatro dígitos. La contraseña se compara con la contraseña (P.e.: un atributoque indique permanecen deseos magi-
válida almacenada en el sistema. Si la contraseña es inco- cos).El estado activo de un objeto indica el estado actual
rrecta, el panel de control avisará una vez y se restaurará cuando éste entra en una transformación continua o pro-
por sí mismo para recibir datos adicionales. Si la contrase- ceso. El objeto jugador poseerá los siguientes estados
ña es correcta, el panel de control espera por las acciones activos: en movimiento, en descanso, lesionado,en recu-
siguientes. peración, atrapado, perdido entre otros. Para forzar la
transición de un objeto de un estado activo a otro debe
3. El urouietario selecciona y teclea uermanecer o continuar ocurrirun suceso (a veces, llamado disparador).Un com-
para activar el sistema.Permanecer activa solamente los sen- ponente de un modelo objeto-comportamiento es una
sores del uehetro (los sensores internos detectores de movi- representaciónsimple de los estados activos de cada obje-
miento están desactivados). Continuar activa todos los to y los sucesos (disparadores)que producen los cambios
sensores. entre estos estados activos. La Figura 21.9 ilustra una
representación simple de los estados activos para el obje-
4. Cuando ocurre la activación, el propietario puede observar to panel de control en el sistema HogarSeguro.
una luz ro-ia de alarma.
Cuondose empiezon o identificar estodos, lo otención
Las partes de texto subrayadasanteriormenteindican
sucesos. Deberá identificarseun actor para cada suceso: se centro en los modos de Comportamiento observobles
la información que se intercambia debe anotarse. y debe- desde el exterior. Más torde, se pueden refinor estos
rán indicarse otras condiciones o restricciones. estados en comportomientosno evidentes cuando
se observo el sistema desde el exterior.
Como ejemplo de un suceso típico, considere la fra-
se subrayada del caso de uso propietario usa el teclado Cada flecha en la Figura 21.9 representa una transi-
para teclear una contraseña de cuatro dígitos. En el con- ción de un estado activo del objeto a otro. Las etique-
texto del modelo de análisis O 0 el actor propietario tas mostradas en cada flecha representan los sucesos
transmite un suceso al objeto panel de control. que disparan la transición. Aunque el modelo de esta-
do activo aporta una visión interna muy útil de la «his-
El suceso puede llamarse contraseña introducida. toria de vida» de un objeto, es posible especificar
La información transferida son los cuatro dígitos que información adicional para aportar más profundidad en
forman la contraseña, pero ésta no es una parte esencial la comprensión del comportamiento de un objeto. Adi-
del modelo de comportamiento. Es importantenotar que cionalmente a especificarel suceso que provoca la ocu-
algunos sucesos tienen un impacto explícito en el flujo rrencia de la transición, el análisis puede también
de control del caso de uso, mientras que otros no impac- especificar una guarda y una acción [CHAR93]. Una
tan directamente en este flujo de control. Por ejemplo. guarda es una condición Booleana, que debe satisfa-
el suceso contraseña introducida no cambia explícita- cerse para posibilitar la ocurrencia de una transición.
mente el flujo de control del caso de uso, pero los resul- Por ejemplo, la condición de guarda para la transición
tados del suceso comparar contraseña (derivada de la desde el estado «en descanso» al de «comparando» en
interacción contraseña se compara con la contraseña la Figura 20.9 puede determinarse a través del examen
válida almacenada en el sistema) tendrá un impacto del caso de uso:
explícito en la información y flujo de control del soft-
ware HogarSeguro. if (entrada de contraseña = 4 dígitos)
then ejecutar transición al estado comparando;
Una vez que todos los sucesos han sido identifica-
dos, se asocian a los objetos incluidos.Los actores (enti-
dades externas) y objetos pueden responsabilizarse de
la generación de sucesos (P.e.: propietario genera el
suceso contraseña introducida) o reconociendo suce-
sos que han ocurrido en otra parte (P.e.: el panel de con-
trol reconoce el resultado binario del suceso comparar
contraseña).

21.6.2. Representaciones de estados En general, la guarda de una transición depende
usualmente del valor de uno o más atributos de un obje-
En el contexto de sistemas O 0 deben considerarse dos to. En otras palabras, la condición de guarda depende
caracterizaciones de estados: (1) el estado de cada obje- del estado pasivo del objeto.
to cuando el sistema ejecuta su función, y (2) el estado
del sistema observado desde el exterior cuando éste eje- Una acción ocurre concurrentementecon la transición
cuta su función. o como una consecuenciade ella y generalmenteimplica
una o más operaciones(responsabilidades) del objeto. Por
El estado de un objeto adquiere en ambos casos carac- ejemplo, la acción conectada con el suceso contrasería
terísticas pasivas y activas [CHAR93]. Un estado pasi- introducida (Fig. 21.9) es una operación que accede a un
vo es simplementeel estado actual de todos los atributos objeto contraseñay realiza una comparacióndígito a dígi-
de un objeto. Por ejemplo, el estado pasivo del objeto to para validar la contraseña introducida.

375

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

Comparar contraseña La Figura 21.1O ilustra una traza parcial de sucesospara
[contraseña incorrecta] el sistema Hogarseguro. Cada una de las flechas repre-
senta un suceso (derivadode un casode uso) e indica cómo
FIGURA 21.9. Representación de la transición de estados. el suceso sintoniza su comportamientoentre los objetos
de HogarSeguro. El primer suceso, sistema listo, se deri-
El segundo tipo de representación de comportamiento va del entorno exterior y sintoniza el comportamiento al
para el A 0 0 considera una representación de estados propietario.El propietarioteclea una contraseña.El suce-
para el producto general o sistema. Esta representación so inicia aviso y aviso sonoro indican cómo se canaliza el
abarca un modelo simple de traza de sucesos [RUM91] comportamiento si la contraseña no es válida. Una con-
que indica cómo los sucesos causan las transiciones de traseña válida provoca un retomo al propietario. Los suce-
objeto a objeto y un diagrama de transición de estados sos restantes y sus trazas siguen el comportamiento como
que ilustra el comportamiento de cada objeto durante el cuando se activa o desactiva el sistema.
procesamiento.
UML utiliza diagramas de estado, de secuencia, de
Una vez que han sido identificados los sucesos para colaboración y de actividades para representar el com-
un caso de uso, el analista crea una representación portamiento dinámico de los objetos y las clases iden-
acerca de cómo los sucesos provocan el flujo desde tificadas como parte del modelo del análisis.
un objeto a otro. Esta representación, llamada traza
de sucesos o de sucesos, es una versión abreviada del -Sistema- Introducir 7 www.elsolucionario.net
caso de uso que representa objetos clave y los suce- contraseña
sos que provocan el comportamiento de pasar de obje- listo 1
to a objeto. Iniciar sonido
Y
CLAVE
'
Una transición de un estado a otro requiere un suceso que
la produzca. los sucesos son booleanos por naturaleza ya 1 ' 'Preparado para
menudo ocurren cuando un objeto se comunica con otro.
&ivación/desactivación

'iActivarldesactivar '
sensores

¡- Sensores
activados/desactivados

' Petición de luz roja 1

' Luz roja encendida 0

0 Preparado para

7 nueva acción

FIGURA 21.10. Traza de sucesos parcial para el sistema
Hogarseguro.

Los métodos de A 0 0 permiten a un ingeniero del soft- los requisitos especificados por el cliente tal y como
ware modelar un problema representando las caracte- éstos afectan a la aplicación a construir.
rísticas tanto dinámicas como estáticas de las clases y
sus relacionescomo componentesprincipales del mode- El proceso de A 0 0 comienza con la definición de
lado. Como los métodos precedentes, el lenguaje unifi- casos de uso (escenarios que describen cómo se va a
cado de modelado UML construye un modelo de análisis utilizar el sistema). La técnica de modelado de clases-
con las siguientes características: (1) representación de responsabilidades-colaboraciones (CRC) se aplica para
las clases y jerarquías de clases, (2) creación de mode- documentar las clases y sus atributos y operaciones.
los objeto-relación, y ( 3 )obtención de modelos objeto- También proporciona una vista inicial de las colabora-
comportamiento. ciones que ocurren entre los objetos. El siguientepaso
en el A 0 0 es la clasificación de objetos y la creación
El análisis de sistemas orientados a objetos se reali- de una jerarquía de clases. Los sistemas (paquetes) se
za a muchos niveles diferentes de abstracción. En los pueden utilizar para encapsular objetos relacionados.
niveles de empresa o de negocio las técnicas asociadas El modelo objeto-relación proporciona información
con el análisis se pueden conjugar con el enfoque de sobre las conexiones entre las clases, mientras que el
ingeniería del proceso de negocio. A estas técnicas a modelo objeto-comportamiento representa el compor-
menudo se las llama de análisis del dominio. En el nivel tamiento de los objetos individualmente y el global de
de implementación el modelo de objetos se centra en todo el sistema.

376

http:w//lwibwre.reial-suonliuvecrisoitnaarirai.ob.longestpot.com
.

CAPfTULO 21 ANALISIS ORIENTADO A OBJETOS

[ALH98] Alhir, S.S., UML in a Nutshell, O’Reilly & Asso- [FIC92] Fichman, R.G., y Kemerer, C.F., Object-Oriented www.elsolucionario.net
ciates, Inc. 1998. and Conventional Analysis and Design Methodologies,
Computer, vol. 25, n.O 10, Octubre 1992, pp. 22-39.
[AMB95]Ambler, S., «Using Use-Cases», Software Deve-
lopment, Julio 1995, pp. 53-61 [FIN961Fingar, P., The Blueprintfor Business Objects,Cam-
bridge University Press, 1996.
[ARA891Arango, G., y Prieto-Diaz, R., «Domain Analysis:
Concepts and Research Directionm, Domain Analysis: [FIR93] Firesmith, D.G., Object Oriented Requeriments
Acquisition of Reusable Information for S o f i a r e Cons- Analysis and Logical Design, Wiley, 1993.
truction (G. Arango y Prieto-Diaz, eds.), IEEE Computer
Society Press, 1989. [JAC92]Jacobson, I., Object-Oriented S o f i a r e Engineering,
Addison-Wesley, 1992.
[BER93] Berard, E.V., Essays on Object-Oriented Software
Engineering, Addison-Wesley, 1993. [JAC99] Jacobson, I., Booch, G., y Rumbaugh, J., Unified
S o f i a r e Development Process, Addison-Wesley, 1999.
[BEN99] Beneth, S., S. McRobb y R. Farmer, Object-Orien-
ted System Analysis and Design Usign UNL, McGraw- [MAT94] Mattison, R., The Object-Oriented Enterprise,
Hill, 1999. McGraw Hill, 1994.

[B0094] Booch, G., Object-Oriented Analysis and Design, [MON92] Monarchi, D.E., y Puhr, G.I., «A Research Typo-
2.aed., Benjamin Cummings, 1994. logy for Object-Oriented Analysis and Design», CACM,
vol. 35, n.O 9, Septiembre 1992, pp. 35-47.
[B0099] Booch, G., Jacobson, I., y Rumbaugh, J., The Unified
Modeling Language User Guide, Addison-Wesley, 1999. [RUM91] Rumbaugh, J., et al., Object Oriented Modelling
and Design, Prentice-Hall, 1991.
[CAR98] Carmichael,A., Developing Business Objects, SIGS
Books, 1998. [RUM99] Rumbaugh, J., Jacobson, I., y Booch, G., The Uni-
fied Modelling Language Reference Manual, Addison-
[CHA93] de Champeaux, D., D. Lea, y P. Faure, Ohject- Wesley, 1999.
Oriented System Development, Addison-Wesley, 1993.
[SUL94] Sullo, G.C., Object Engineering, Wiley, 1994.
[COA911 Coad, P., y E. Yourdon, Object-Oriented Analysis,
2.- ed., PrenticeHall, 1991 [TAY95] Taylor, D.A., Business Engineering with Object
Technology, Wiley, 1995.
[EEL98] Eeles, P,. y Simms, O., Building Business Objects,
Wiley, 1998. [WIR90]Wirfs-Brock, R., Wilkerson, B., y Weiner, L., Desig-
ning Object Oriented Software, Prentice-Hall, 1990.
[ERI98]Eriksson,H.E., y Penker,M., UMLToolkit,Wiley, 1998.

21.1. Hágase con uno o más libros sobre UML y compárelo 21.5. Escriba un caso de uso para el sistemaHogarSeguro. Los
con el análisis estructurado(Capítulo 12)utilizando las dimen- casos de.uso deben tratar el escenario requerido para establecer
siones de modelado propuestas por Fichman y Kemerer una zona de seguridad. Una zona de seguridadlleva asociadoun
[FIC92] en la Sección 21.1.1. conjuntode sensores quepueden ser accedidos,activadosy desac-
tivados no individualmente sino en conjunto. Debe ser posible
21.2. Desarrolle una clase-presentación sobre un diagrama definir hasta diez zonas de seguridad. Sea creativo,pero intente
estático o dinámico de UML. Presente el diagrama en el con- mantenersedentrode lo definidopara el panel de controldel sis-
texto de un ejemplo sencillo, pero intente mostrar el suficien- tema tal y como fue definido previamente en este libro.
te nivel de detalle como para demostrar los aspectos más
importantes del tipo de diagrama elegido. 21.6. Desarrolle un conjunto de casos de uso para el sistema
SSRB del Problema 12.13.
21.3. Conduzca un análisis del dominio para una de las siguien-
tes áreas: Tendrá que hacer varias suposiciones sobre la forma de
interacción del usuario con el sistema.
a) Un sistema para almacenar los expedientes de los alumnos
de una universidad. 21.7. Desarrolle un conjunto de casos de uso para alguna de
las siguientes aplicaciones:
b) Una aplicación de comercio electrónico (P.e. ropa, libros,
equipos electrónicos, etc.) a) Software para un asistente personal electrónico de propó-
sito general.
c ) Un servicio al cliente para un banco.
b) Software para un videojuego de su elección.
d) El desarrollo de un videojuego.
e) Un área de aplicación propuesta por su instructor. c) Software para el sistema de climatización de un auto-
móvil.
21.4. Describa con sus propias palabras la diferencia entre las
vistas estática y dinámica de un sistema. d) Software para un sistema de navegación de un automóvil.

e) Un sistema propuesto por su instructor.

377

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

Lleve a cabo una pequeña investigación(unas pocas horas) en 21.13. Desarrolle un modelo objeto-comportamiento para el
el dominio de la aplicación y conduzca una reunión TFEA producto o sistema elegido en el problema 21.7. Asegúrese de
(Capítulo 11)con sus compañerospara desarrollar unos requi- listar todos los sucesos,proporcionar la traza de sucesos, desa-
sitos básicos (su instructor le ayudará a coordinarlo). rrollar un diagrama de flujo de sucesos y definir diagramas de
estado para cada clase.
21.8. Desarrolle un conjunto completo de tarjetas CRC del
producto o sistema elegido en el problema anterior. 21.14. Describa con sus propias palabras la forma de deter-
minar los colaboradores de una clase.
21.9. Dirija una revisión de las tarjetas CRC con sus colegas.
¿Cuántas clases, responsabilidades y colaboraciones adicio- 21.15. ¿Qué estrategia propondría para definir subsistemasen
nales ha añadido a consecuencia de la reunión? colecciones de clases?

21.10. Desarrolle una jerarquía de clases para el producto o 21.16. ¿Qué papel desempeña la cardinalidad en el desarrollo
sistema elegido en el Problema 21.7. de un modelo objeto-relación?

21.11. Desarrolle un conjunto de subsistemas (paquetes) para 21.17. ¿Cuál es la diferencia entre los estados pasivo y activo
el producto o sistema elegido en el Problema 21.7. de un objeto?

21.12. Desarrolle un modelo objeto-relaciónpara el producto
o sistema elegido en el Problema 21.7.

Los casos de uso forman la base del análisis orientado a obje- Douglas, B., Real-Time UML: Developing Eflcient Objects www.elsolucionario.net
tos, sin importar el método de A 0 0 elegido. Los libros de for Embedded Systems, Addison-Wesley, 1999.
Rosemberg y Scott (Use case driven Object modelling with
UML: a practica1approach, Addison-Wesley, 1999), Schnei- Fowler, M., y Kendall Scott, UMLDistilled, 2." ed., Addison-
der, Vinters y Jacobson (Applying Use Cases: A Practica1Gui- Wesley, 2000.
de, Addison-Wesley, 1999), y Texel y Williams (Use Cases
CombinedWithBoochlOMTIUML: Process and Products,Pren- Larman, C., Applying UMLand Patterns: un Introduction to
tice-Hall, 1997) proporciona una guía para la creación y uso Object Oriented Analysis, Prentice-Hall, 1997.
de esta importante herramienta de obtención de requisitos y
mecanismo de representación. Odell, J.J., y Fowler, M., Advanced Object Oriented Analy-
sis and Design Using UML, SIGS Books, 1998.
Casi todos los libros publicados recientemente sobre aná-
lisis y diseño orientado a objetos ponderan UML. Todos los Ostereich, B., Developing Software with UML: Object Orien-
que están considerando en serio aplicar UML en su trabajo, ted Analysis and Design in Practice,Addison-Wesley, 1999.
deberían comprar [B0099], [JAC99] y [RUM99]. Además
de estos, los siguientes libros también son representativos de Page-Jones, M., Fundamentals of Object-Oriented Design in
las docenas de ellos escritos sobre la tecnología de UML: UML, Addison-Wesley, 1999.
Stevens, P., y Pooley, R., Software Engineering with
Douglas, B., y Booch, G., Doing Hard Time:Developing Real-
Time Systems with UML, Objects, Frameworks and Pat- Objects and Components, Addison-Wesley, 1999.
terns, Addison-Wesley, 1999. En Intemet hay gran cantidad de fuentesde informaciónsobre

análisis orientado a objetos y temas relacionados. Una lista actua-
lizada sobre las referencias web relevantes de cara al análisis
orientado a objetos la encontraráen http://www.pressman5.com

378

CAPÍTULO www.elsolucionario.net
.
22
DISEÑO ORIENTADO A OBJETOS

EL diseño orientado a objetos transforma el modelo de análisis creado usando análisis www.elsolucionario.net
orientado a objetos (Capítulo 21), en un modelo de diseño que sirve como anteproyecto
para la construcción de software. El trabajo de diseñador de software puede ser intimi-
dante. Gamma y sus colegas [GAM95] proveen un panorama razonablemente exacto del DO0
cuando declaran que:

El diseño de software orientado a objetos es difícil, y el diseño de software reusable orientado a obje-
tos es aun más difícil. Se deben identificar los objetos pertinentes, clasificarlos dentro de las clases en la
granularidad correcta, definir interfaces de clases y jerarquías de herencia y establecer relaciones clave entre
ellos. El diseño debe ser específico al problema que se tiene entre manos, pero suficientemente general para
adaptarse a problemas y requerimientos futuros. Además se deberá evitar el rediseño, o por lo menos mini-
mizarlo. Los diseñadores experimentados en O 0 dicen que un diseño reusable y flexible es difícil, si no
imposible de obtener «bien», la primera vez. Antes de que un diseño sea terminado, usualmente tratan de
reutilizarlo varias veces, modificándolo cada vez.

A diferencia de los métodos de diseño de software convencionales, el DO0 proporciona un
diseño que alcanza diferentes niveles de modularidad. La mayoría de los componentes de un sis-
tema, están organizados en subsistemas, un «módulo» a nivel del sistema. Los datos y las ope-
raciones que manipulan los datos se encapsulanen objetos-una forma modular que es el bloque
de construcción de un sistema 00-. Además, el DO0 debe describir la organización específi-
ca de los datos de los atributos y el detalle procedural de cada operación. Estos representan datos
y piezas algorítmicas de un sistema O 0 y son los que contribuyen a la modularidad global.

¿Quées? El diseno de software Orientado el principio, pero muchas otras pueden nentes: la interfazde usuario, la gestión
a objetos requiere la definición de una ser reutilizadas, si se reconocen los de datos y los mecanismos d e adminis-
arquitectura de software multicapa, la patrones de diseño apropiados. El DO0 traciónde tareas. Ei diseñodeobjetosse
especificaciónde subsistemas que rea- establece urianteproyedo de diseño,que centra en losdetalles internos de cada
permite al ingeniero de softwaredefinir clase, definiciónde atributos. operacio-
l lizan funciones necesarias y proveen la arquitectura OO. en forma que maxi- nes y detalles de los mensqes.
soportede infraestructura, una descrip- mice la reutilización; de esta manera, se
ción de objetos (clases),que son losblo- mejora la velocidad del desarrollo y la ¿cuál esel pppdrrtoobkaide?Eimcde-
calidad del producto terminado.
1 ques de construccióndel sistema, y una lo de diseño O0abarca arquitectura de
1 descripciónde los mecanismosde comu- 6Cuúiessen ios pasos? El DO0 sedivide software, descripción d e la interfaz de
en dos grandes actividades: diseño del usuario, componentes de gestión de
nicación,que permitenque los datos Bu- sistemay diseñode objetos.El diseñode datos. mecanismos d e administraciónde
yan entre las capas, subsistemas y sistema crea la arquitectura del produc- tareasydescxipcionesdetaliadasdeada
objetos. El Diseño Orientado a Objetos to defuiiendo una serie de ucapasm, que una de las clases d a sen el sistema.
(nao),cumple todos estos requisitos. cumplen funciones específicas d e l siste-
'~ ma e identificalas claces.quesonencap- ¿Cómo pueüo eiltcpseguvode que Lo
&Quiénlo hace? El DOO lo realiza un suladaspor los subsistemasqueresiden he hecho correctamente?En cada
ingeniero de software. en cada capa.
diseño orientado a objetos son revisa-
'8 ¿Por qué es importante? Un sistema Además,el diseño de sistemas incor- dos por claridad, conecúón,integridad
orientado a objetosutiliza las definicio- pora la especificación de tres compo- y consistencia con los requisitos del
cliente y entre ellos.
1 nes de las clases derivadas del modelo
de anáiisii.Algunasde estas definicio-
nes tendrán que ser construidas desde

La naturaleza Única del diseño orientado a objetos, reside en su capacidad para construir cua-
tro conceptos importantes de diseño de software: abstracción, ocultamiento (ocultación) de
información, independencia funcional y modularidad (Capítulo 13).Todos los métodos de dise-
ño procuran software que exhiba estas características fundamentales, pero sólo el DO0 provee
un mecanismo que permite al diseñador alcanzar las cuatro, sin complejidad ni compromiso.

El diseño orientado a objetos, la programación orientada a objetos, y las pruebas orientadas
a objetos son actividades de construcción para sistemas OO. En este capítulo se considera el
primer paso en la construcción.

379

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

En el Capítulo 13 se introdujo el concepto de una pirá- forma los cimientos sobre los que la pirámide se sostie- www.elsolucionario.net
mide de diseño para el software convencional. Cuatro ne. La capa fundamental se centra en el diseño de los obje-
capas de diseño --datos, arquitectura, interfaz y nivel tos del dominio (llamadospatronesde disefio).Los objetos
de componentes-fueron definidas y discutidas. Para del dominiojuegan un papel clave, en la construcciónde
sistemas orientados a objetos, podemos también definir la infraestructura del sistema O 0 aportando soporte para
una pirámide, pero las capas son un poco diferentes. las actividades de interfaz hombrelmáquina, administra-
Refiriéndose a la Figura 22.1, las cuatro capas de la pirá- ción (gestión)de tareas y gestión (administración)de datos.
mide de diseño O 0 son: Los objetos del dominio se pueden usar, además, para
desarrollarel diseño de la aplicación en sí misma.
La capa subsistema. Contiene una representación
de cada uno de los subsistemas, para permitir al soft- 22.1.1. Enfoque convencional vs. O0
ware conseguir sus requisitos definidos por el cliente e
implementar la infraestructura que soporte los requeri- Los enfoques convencionalespara el diseño de software
mientos del cliente. aplican distintas notaciones y conjunto de heurísticas,
para trazar el modelo de análisis en un modelo de dise-
La capa de clases y objetos. Contiene la jerarquía ño. Recordando la Figura 13.1,cada elemento del mode-
de clases, que permiten al sistema ser creado usando lo convencional de análisis se corresponde con uno o
generalizaciones y cada vez especializacionesmás acer- más capas del modelo de diseño. Al igual que el dise-
tadas. Esta capa también contiene representaciones. ño convencional de software, el DO0 aplica el diseño
de datos cuando los atributos son representados, el di-
La capa de mensajes. Contiene detalles de diseño, seño de interfaz cuando se desarrolla un modelo de
que permite a cada objeto comunicarse con sus colabo- mensajería, y diseño a nivel de componentes (procedi-
radores. Esta capa establece interfaces externas e inter- mental), para operaciones de diseño. Es importante notar
nas para el sistema. que la arquitectura de un diseño O 0 tiene más que ver
con la colaboración entre objetos que con el control de
La capa de responsabilidades. Contiene estructu- flujo entre componentes del sistema.
ras de datos y diseños algorítmicos, para todos los atri-
butos y operaciones de cada objeto. A pesar de que existen similitudes entre los diseños
convencionales y 00,se ha optado por renombrar las
capas de la pirámide de diseño, para reflejar con mayor
precisión la naturaleza de un diseño OO. La Figura 22.2
ilustra la relación entre el modelo de análisis O 0 (Capí-
tulo 21) y el modelo de diseño que se derivará de ahí'.

FIGURA 22.1. La pirámide del Diseño OO.

La pirámide de diseño se centia exclusivamente en el El modelo de diseíio
diseño de un producto o sistema específico. Observe, sin
embargo, que existe otra capa de diseño, y que esta capa FIGURA 22.2. Transformación de un modelo de análisis O0

a un modelo de diseño OO.

Es importante hacer notar que la derivación no es siempre
evidente. Para profundizar véase [DAV95].

380

www.elsolucionario.net CAPfTULO 22 DISENO ORIENTADO A OBJETOS
.

El diseño de subsistemas se deriva considerando los continuidad: la habilidad para hacer pequeños cam- www.elsolucionario.net
requerimientos globales del cliente (representados por bios en un programa y que se revelen haciendo los
los casos de uso) y los sucesos y estados que son exter- cambios pertinentes en uno o muy pocos módulos.
namente observables (el modelo de comportamiento de protección: una característica arquitectónica, que
objetos). El diseño de clases y objetos es trazado de la reduce la propagación de efectos colaterales, si ocu-
descripción de atributos, operaciones y colaboraciones rre un error en un módulo dado.
contenidasen el modelo CRC. El diseño de mensajes es
manejado por el modelo objeto-relación, y el diseño de Una referencia que responde a lo pregunta iqué hace
responsabilidades es derivado del uso de atributos, ope- que un diseño orientado o objetos sea bueno?, puede
raciones y colaboraciones descrito en el modelo CRC. encontrarse en: www.kinetica.com/ootips/ood-
printipies.htmi
Fichman y Kemerer [FIC92] sugieren diez compo-
nentes de diseño modelado, que pueden usarse para com- De estos criterios, Meyer [MEY90], sugiere cinco
parar varios métodos convencionales y orientados a principios básicos de diseño, que pueden ser deducidos
objetos: para arquitecturas modulares: (1) unidades lingüísticas
modulares, (2) pocas interfaces, ( 3 ) pequeñas interfa-
1. representación de la jerarquía de módulos. ces (acoplamiento débil), (4) interfaces explícitas y ( 5 )
ocultación de información.
2. especificación de las definiciones de datos.
3. especificación de la lógica procedimental. ¿Qué principios básicos
nos guían en el diseño
4. indicación de secuencias de proceso final-a-final de arquitecturasmodulares?
(end-to-end)
Los módulos se definen como unidades lingüísticas
5. representación de estados y transiciones de los modulares, cuando «corresponden a unidades sintácti-
objetos. cas en el lenguaje usado» [MEY90]. Es decir, el len-
guaje de programación que se usará debe ser capaz de
6. definición de clases y jerarquías. definir directamente la modularidad. Por ejemplo, si el
diseñador crea una subrutina, cualquiera de los lengua-
7. asignación de operaciones a las clases. jes de programación antiguos (FORTRAN, C, Pascal),
debe poder implementarlos como una unidad sintácti-
8. definición detallada de operaciones. ca. Pero si un paquete que contiene estructuras de datos
y procedimientos, y los identifica como una sola uni-
9. especificación de conexiones de mensajes. dad definida, en un lenguaje como Ada (u otro lengua-
je orientado a objetos), será necesario representar
10. identificación de servicios exclusivos. directamente este tipo de componente en la sintaxis del
lenguaje.
;¿Qué criterio se puede usar
Para lograr el bajo acoplamiento (un concepto de
para comparar los métodos diseño introducido en el Capítulo 13), el número de
convencionalesy los métodos interfaces entre módulos debe minimizarse («pocas
de DOO? interfacew), y la cantidad de información que se mue-
ve a través de la interfaz también debe ser minimizada
Ya que existen muchos enfoques de diseño conven- («pequeñas interfacem). Siempre que los componentes
cionales y orientadosa objetos, es difícil desarrollar una se comunican, deben hacerlo de manera obvia y direc-
comparación generalizada entre los dos métodos. Sin ta («interfaces explícitas»). Por ejemplo, si el compo-
embargo, se puede asegurar que las componentes de nente X y el componente Y se comunican mediante el
modelado 5 al 10 no están soportadas usando diseño área de datos global (a lo que se llama acoplamiento
estructurado (Capítulo 14)o sus derivados. común en el Capítulo 13), violan el principio de inter-
faces explícitas porque la comunicación entre compo-
22.1.2. Aspectos del diseño nentes no es obvia a un observador externo. Finalmente,
se logra el principio de ocultamiento de información,
Bertrand Meyer [MEY90] sugiere cinco criterios para cuando toda información acerca de un componente se
juzgar la capacidad de métodos de diseño para conse- oculta al acceso externo, a menos que esa información
guir modularidad, y los relaciona al diseño orientado a sea específicamente definida como pública.
objetos:

descomponibilidad: la facilidad con que un método
de diseño ayuda al diseñador a descomponer un pro-
blema grande en problemas más pequeños, hacién-
dolos más fácil de resolver.
componibilidad el grado con el que un método de
diseño asegura que los componentes del programa
(módulos), una vez diseñados y construidos, pueden
ser reutilizados para crear otros sistemas.
comprensibilidad la facilidad con la que el compo-
nente de un programa puede ser entendido, sin hacer
referencia a otra información o módulos.

38 1

hwttwp:w//l.iberlesroial-uucniiovenrasritiaor.ian.ebtlogspot.com

INGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

Los criterios y principios de diseño presentados en tos enfatiza el esquema detallado de un objeto indivi- www.elsolucionario.net
esta sección pueden ser aplicados a cualquier método dual. Se seleccionan las operaciones del modelo de
de diseño (así como al diseño estructurado). Como se análisis, y los algoritmos se definen para cada opera-
verá, el método de diseño orientado a objetos logra cada ción. Se representan las estructuras de datos apropia-
uno de los criterios más eficientemente que otros enfo- das para atributos y algoritmos. Las clases y atributos
ques, y resulta en arquitecturasmodulares, que cumplen de clase son diseñados de manera que se optimice el
efectivamente cada uno de los criterios. acceso a los datos, y se mejore la eficiencia computa-
cional. Se crea un modelo de mensajería, para imple-
22.1.3. El Panorama de DO0 mentar relaciones de objetos (asociaciones).

Como se vio en el Capitulo 21, una gran variedad de El método de Jacobson. El diseño para ISOO
métodos de análisis y diseño orientados a objetos fue (Ingeniería del software orientada a objetos) [JAC92]
propuesta y utilizada durante los ochenta y los noven- es una versión simplificada del método propietario
ta. Estos métodos establecieron los fundamentos para Objectory, también desarrollado por Jacobson. El
la notación moderna de DOO, heurísticas de diseño y modelo de diseño enfatiza la planificación para el
modelos. A continuación, haremos una breve revisión modelo de análisis ISOO. En principio, el modelo
global de los primeros métodos de DOO: idealizado de análisis se adapta para acoplarse al
ambiente del mundo real. Después los objetos de
El método de Booch. Como se vio en el Capítulo diseño primarios, llamados bloques’, son creados y
21, el método Booch [B0094] abarca un «proceso de catalogados como bloques de interfaz, bloques de enti-
micro desarrollo» y un <<procesode macro desarrollo». dades y bloques de control. La comunicación entre
En el contexto del diseño, el macro desarrollo engloba bloques durante la ejecución se define y los bloques
una actividad de planificación arquitectónica,que agrupa se organizan en subsistemas.
objetos similares en particiones arquitectónicas separa-
das, capas de objetos por nivel de abstracción, identi- El método de Coad y Yourdon. Éste método para
fica situaciones relevantes, crea un prototipo de diseño D O 0 [COA91], se desarrolló estudiando «cómo es que
y valida el prototipo aplicándolo a situaciones de uso. los diseñadores orientados a objetos efectivos» hacen
El micro desarrollo define un conjunto de «reglas» que su trabajo. La aproximación de diseño dirige no sólo la
regulan el uso de operaciones y atributos y las políticas aplicación, sino también la infraestructura de la aplica-
del dominio específico para la administración de la ción, y se enfoca en la representación de cuatro com-
memoria, manejo de errores y otras funciones; desa- ponentes mayores de sistemas: la componente de
rrolla situaciones que describen la semántica de las dominio del problema, la componente de interacción
reglas y políticas; crea un prototipo para cada política; humana, la componente de administración de tareas y
instrumenta y refina el prototipo; y revisa cada política la de administración de datos.
para así «transmitir su visión arquitectónica» [B0094].
El método de Wirfs-Brock. Wirfs-Brock, Wilker-
El método de Rumbaugh. La técnica de modelado son y Weiner [WIR90] definen un conjunto de tareas
de objetos (TMO) [RUM91] engloba una actividad de técnicas, en la cual el análisis conduce sin duda al diseño.
diseño que alienta al diseño a ser conducido a dos dife- Los protocolos3 para cada clase se construyen refinando
rentes niveles de abstracción. El diserío de sistema se contratos entre objetos. Cada operación (responsabili-
centra en el esquema de los componentes que se nece- dad) y protocolo (diseño de interfaz) se diseña hasta un
sitan para construir un sistema o producto completo. nivel de detalle que guiará la implementación. Se desa-
El modelo de análisis se divide en subsistemas, los rrollan las especificaciones para cada clase (definirres-
cuales se asignan a procesadores y tareas. Se define ponsabilidades privadas y detalles de operaciones) y
una estrategia para implementar la administración de cada subsistema (identificar las clases encapsuladas y
datos, y se identifican los recursos y mecanismos de la interacción entre subsistemas).
control requeridos para accesarlos. El diseño de obje-
Aunque no es tan robusto como UMI, el método Wih-
Brock tiene uno elegancia sencilla, que lo convierte
en un enfoque olternativo e interesonte u/ DOO.

A pesar de que la terminología y etapas de proceso
para cada uno de estos métodos de D O 0 difieren, los
procesos de D O 0 global son bastante consistentes.

* Un bloque e s la abstracción de diseño, que permite la representa- Un proiocolo es una descripción formal de los mensajes, a los que
la clase responde.
ción de un objeto agregado.

382

www.elsolucionario.net
.

CAPÍTULO 22 DISENO ORIENTADO A OBJETOS

Para llevar a cabo un diseño orientado a objetos, un Estas proporcionaron una visión interna al uso de las www.elsolucionario.net
ingeniero de software debe ejecutar las siguientes eta- situaciones para el sistema (facilitando guías para el
pas generales: modelado de comportamiento), y establecieron funda-
mentos para la implementación y vistas del modelo
1. Describir cada subsistema y asignar a procesadores ambiental, identificando y describiendo elementos
y tareas. estructurales estáticos del.sistema.

2. Elegir una estrategia para implementar la adminis- UML se organiza en dos actividades mayores:
tración de datos, soporte de interfaz y administración diseño del sistema y diseño de objetos. El principal
de tareas. objetivo de UML, diseño de sistema, es representar
la arquitectura de software. Bennett, Mc Robb y Far-
3. Diseñar un mecanismo de control, para el sistema mer [BEN99], exponen este aspecto de la siguiente
apropiado. manera:

4. Diseñar objetos creando una representación proce- En términos de desarrollo orientado a objetos, la arqui-
dura1para cada operación,y estructuras de datos para tectura conceptual está relacionada con la estructura del
los atributos de clase. modelo estático de clase y las conexiones entre las com-
ponentes del modelo. El modelo arquitectura describe la
5. Diseñar mensajes, usando la colaboraciónentre obje- manera como el sistema se divide en subsistemas o módu-
tos y relaciones. los, y como se comunican exportando e importando datos.
La arquitectura de código, define como es que el código
6. Crear el modelo de mensajería. del programa se encuentra organizado en archivos y direc-
7. Revisar el modelo de diseño y renovarlo cada vez torios y agrupado en librerías. La arquitectura de ejecución
se centra en los aspectos dinámicos del sistema y la comu-
que se requiera. nicación entre componentes, mientras las tareas y opera-
ciones se ejecutan.
si&
La definición de «subsistemas», nombrada por Ben-
CLAVE nett et al., es una preocupación principal durante el dise-
ño de sistema de UML.
Un conjunto de etapas genéricas se aplica durante
el 000, sin importar el método de diseño que se escoja. si&

Es importante hacer notar que las etapas de diseño CLAVE
discutidas en esta sección son iterativas. Eso significa
que deben ser ejecutadas incrementalmente, junto con El diseño de sistema se centra en arquitectura
las actividades de AOO, hasta que se produzca el dise- de software y definición de subsistemas.
ño completo. El diseño de objetos describe obietos, hasta

22.1.4. Un enfoque unificado para el DO0 un nivel en el cual puedan ser implementados,
en un lenguaje de programación.
En el Capítulo 21, se mencionó como Grady Booch,
James Rumbaugh e Ivar Jacobson, combinaron las El diseño de objetos se centra en la descripción de
mejores cualidades de sus métodos personales de aná- objetos y sus interacciones con los otros. Una especifi-
lisis y diseño orientado a objetos, en un método uni- cación detallada de las estructuras de datos de los atri-
ficado. El resultado, llamado el Lenguaje de Modelado butos y diseño procedural de todas las operaciones, se
Unificado, se ha vuelto ampliamente usado en la crea durante el diseño de objetos. La visibilidad5 para
industria4. todos los atributos de clase se define, y las interfaces
entre objetos se elaboran para definir los detalles de un
3Referencia Web modelo completo de mensajes.

Un tutorial y listado extenso de recursos de UMl incluyendo El diseño de sistemas y objetos en UML se extien-
herramientas, referenciasy ejemplos, de para considerar el diseño de interfaces, adminis-
se pueden encontrar en: mini.net/cetus/oo_umI.html tración de datos con el sistema que se va a construir
y administración de tareas para los subsistemas que
Durante el modelo de análisis (Capítulo 21), se repre- se han especificado. La interfaz de usuario en UML
sentan las vistas del modelo de usuario y estructural. utiliza los mismos conceptos y principios examina-
dos en el Capítulo 15. La visión del modelo de usua-

Booch, Rumbaugh y Jacobson han escrito tres libros muy impor- Visibilidad indica si el atributo es público (disponible a través de
tantes sobre UML. El lector interesado debe consultar [BOO99], todas las instanciasde la clase),privado (disponible sólopara la clase
que lo especifica) o protegido (un atributo que puede ser usado por
[RUM99]y UAC991 la clase que lo especifica y por sus subclases).

383

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

rio maneja el proceso del diseño de la interfaz de 1 detareas 1
usuario, proporcionando una situación que se elabo-
ra iterativamente, para volverse un conjunto de cla- Diseño
ses de interfaz6.La administración de datos establece de la interfaz
un conjunto de clases y colaboraciones, que permi-
ten al sistema (producto) manejar datos persistentes humana
(por ejemplo, archivos y bases de datos). El diseño
de la administración de tareas establece la infraes- FIGURA 22.3.Flujo de Proceso para DOO.
tructura que organiza subsistemas en tareas, y admi-
nistra la concurrencia de tareas. El flujo de procesos
para el diseño se ilustra en la Figura 22.3’.

A lo largo del proceso de diseño UML, la visión del
modelo de usuario y de estructura se elabora dentro del
diseño de la representación delimitada anteriormente.
Esta actividad de elaboración se analiza en las seccio-
nes siguientes.

El diseño de sistema desarrolla el detalle arquitectóni- particiona el modelo de análisis,para definir colecciones www.elsolucionario.net
co requerido para construir un sistema o producto. El congruentes de clases,relaciones y comportamiento. Estos
proceso de diseño del sistema abarca las siguientes acti- elementos de diseño se definen como subsistema.
vidades:
las conceptosde cohesión y acaplomienta (Copítula 131
Partición del modelo de análisis en subsistemas. pueden oplicarse o nivel de subsistemas. Esfuércese
Identificar la concurrencia dictada por el problema. par alconzor uno buena independencia funcional,
Asignar subsistemas a procesadores y tareas. cuando diseñe subsistemas
Desarrollar un diseño para la interfaz de usuario.
Elegir una estrategia básica para implementar la En general, todos los elementos de un subsistema
administración (gestión) de datos. comparten alguna propiedad en común. Y se integran
Identificar recursos globales y los mecanismos de para completar la misma función; deben residir dentro
control requeridos para su acceso. del mismo producto de hardware, o deben administrar
la misma clase de recursos. Los subsistemas se caracte-
¿Cuáles son las etapas rizanpor sus responsabilidades; eso significaque un sub-
del proceso de diseño sistema puede identificarsepor los servicios que provee
de sistemas? [RUM91]. Cuando se usa en el contexto de un diseño de
sistema 00, un servicio es una colección de operacio-
Diseñar un mecanismo de control apropiado para el nes que llevan a cabo una función específica (por ejem-
sistema, incluyendo administración de tareas. plo, administrar archivos de procesador de textos,
Considerar cómo deben manejarse las condiciones producir un rendering tridimensional,traducir una señal
de frontera. de vídeo analógica en una imagen digital comprimida).
Revisar y considerar mxhx.#s.
En las secciones siguientes, el diseño de actividades , ¿Qué criterios nos guían
relacionadas con cada una de estas etapas se conside- en el diseno de subsistemas?
ran con mayor detalle.
Cuando se definen (y diseñan) los subsistemas, se
22.2.1. Particionar el modelo d e análisis deben seguir los siguientes criterios de diseño:
Uno de los principios fundamentales del análisis (Capí-
tulo 11)es hacer particiones.En el diseño de sistemasO 0 El subsistema debe tener una interfaz bien definida,
a través de la cual se reduzcan todas las comunica-
ciones con el resto del sistema.

Hoy e n día la mayoría de las clases de interfaz son parte de una Recuerde que el A 0 0 es una actividad iterativa. Es totalmente posi-
librería de componentes de software reutilizables. Esto facilita el ble que el modelo de análisis sea revisado como consecuencia del
diseño e implementación de IGUs (Interfaz gráfica de usuario). trabajo de diseño.

384

www.elsolucionario.net
.

CAPÍTULO 22 DISERO ORIENTADO A OBJETOS

Con la excepción de un pequeño número de «clases 6. Definir el modelo de mensajería para la comunica- www.elsolucionario.net
ción entre capas.
de comunicación», las clases incluidas dentro del
subsistemadeben colaborar sólo con otras clases den- 7. Revisar el diseño de capas, para asegurar que el aco-
tro del subsistema. plamiento entre capas se minimiza (un protocolo
El número de subsistemas debe ser bajo. cliente/servidor puede ayudar a realizar esta tarea)
Un subsistema puede ser particionado internamente,
8. Iterar para refinar el diseño de capas.
para ayudar a reducir la complejidad.
Cuando dos subsistemas se comunican entre sí, pue- 22.2.2. Asignación de concurrenciay subsistemas
den establecer un enlace clientelservidor o un enlace
punto-a-punto (peer-to-peer)[RUM911. En un enlace El aspecto dinámico del modelo objeto-comportamien-
cliente/servidor,cada uno de los subsistemasasume uno to provee una indicación de concurrencia entre clases (o
de los papeles implicados, el de el cliente o el del ser- subsistemas). Si las clases (o subsistemas) no se activan
vidor. El servicio fluye del servidor al cliente en una al mismo tiempo, no hay necesidad para el procesamiento
sola dirección. En un enlace punto-a-punto, los servi- concurrente. Esto significa que las clases (o subsistemas)
cios pueden fluir en cualquier dirección. pueden ser implementadas en el mismo procesador de
Cuando un sistema es particionado en subsistemas, hardware. Por otro lado, si las clases (o subsistemas)
se lleva a cabo otra actividad de diseño, llamada estra- deben actuar en sucesos asincrónicamente y al mismo
tificación por capas. Cada capa [BUS961de un sistema tiempo, se verán como concurrentes. Cuando los sub-
00, contiene uno o más subsistemas y representa un sistemas son concurrentes, existen dos opciones de alo-
nivel diferentede abstracciónde la funcionalidadreque- jamiento: (1) alojar cada subsistema en procesadores
rida para completar las funciones del sistema. En la independientes ó (2) alojar los subsistemas en el mismo
mayoría de los casos, los niveles de abstracción se deter- procesador y proporcionar soportede concurrencia, sobre
minan por el grado en que el procesamiento asociado las características del sistema operativo.
con el subsistema es visible al usuario final.
Por ejemplo, una arquitectura de cuatro capas debe En la mayoríade los casas, una implementación
incluir: (1) una capa de presentación (el subsistema aso- de multiproceso incrementola complejidady el riesgo
ciado con la interfaz de usuario), (2) una capa de apli- técnica. Siempre que sea posible, escojo lo arquiteciuro
cación (el subsistema que lleva a cabo procesos asociados de procesador mós simple que pueda realizar el habaja.
con la aplicación), (3) una capa de formato de datos (los
subsistemas que preparan los datos para ser procesados), Las tareas concurrentes se definen [RUM91] exa-
y (4) una capa de base de datos (el subsistema asociado minando el diagrama de estado para cada objeto. Si el
con la administración de datos). Cada capa se encuen- flujo de sucesos y transiciones indica que solo un obje-
tra más profundamente dentro del sistema, representan- to está activo en el tiempo, un hilo de control se ha esta-
do un procesamiento más específico al ambiente. blecido. El hilo de control continúa, aun cuando un
objeto envía un mensaje a otro objeto, mientras que el
¿Cómo se crea un diseño primer objeto espera por la respuesta. Sin embargo, si
por capas? el primer objeto continúa procesando después de enviar
un mensaje, el hilo de control se divide.
Buschmann y sus colegas [BUS961 sugieren el
siguienteenfoque de diseño para estratificación por capas: Las tareas en un sistema O 0 se diseñan generando
1. Establecer los criterios de estratificación por capas. hilos de control aislados. Por ejemplo, mientras que el
sistema de seguridad Hogarseguro monitoriza sus sen-
Esto significa decidir cómo se agruparán los subsis- sores, puede también marcar a la estación central de
temas en una arquitectura de capas. monitorización para verificar la conexión. Ya que los
2. Determinar el número de capas. Muchas de ellas objetos involucrados en ambos comportamientos están
complican innecesariamente; muy pocas debilitan la activos al mismo tiempo, cada uno representa un hilo
independencia funcional. de control y cada uno puede ser definido como una tarea
3. Nombrar las capas y asignar subsistemas (con sus distinta. Si la monitorización y marcado ocurrieran
clases encapsuladas) a una capa. Asegurarse de que secuencialmente, podría implementarse una sola tarea.
la comunicación entre subsistemas (clases) en una
capa*, y otros subsistemas (clases) en otra capa, Para determinar cuál de las opciones de asignación
siguen la filosofía de diseño de la arquitectura. de procesadores es apropiada, el diseñador debe consi-
4. Diseñar interfaces para cada capa. derar los requisitos de desempeño, costos y el encabe-
5. Refinar los subsistemas, para establecer la estructura zado impuesto por la comunicación entre procesadores.
de clases para cada capa.

En una arquitectura cerrada, los mensajes procedentes de una
capa se deberían haber enviado a la capa adyacente inferior. En
una arquitectura abierta, los mensajes deben enviarse a cual-
quiera de las capas inferiores.

385

www.elsolucionario.net

.

INGENIERiA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

22.2.3. Componentede administraciónde tareas interfaz por sí misma representa un subsistema de impor- www.elsolucionario.net
Coad y Yourdon [COA911sugieren la estrategia siguien- tancia crítica para la mayoría de las aplicaciones moder-
te, para el diseño de objetos que manipulan tareas con- nas. El modelo de análisis O 0 (Capítulo 21), contiene
currentes: los escenarios de uso (llamados casos de uso), y una
descripción de los roles quejuegan los usuarios (lla-
se determinan las características de la tarea. mados actores) cuando interactúan con el sistema. Este
se define un coordinador de tarea y objetos asocia- modelo sirve como entrada al proceso de diseño de inter-
dos. faz de usuario.
se integra el coordinador y otras tareas.
Las características de la tarea se determinan, com- l a mayoría de las clases necesariaspara crear
prendiendo cómo es que se inicia la tarea. Las tareas una interfaz moderna ya exirten y estón disponibles
controladas por sucesos y manejadas por reloj son
las más comunes. Ambas se activan por una inte- para el diseñador. El diseño de interfaz obedece
rrupción, pero la primera recibe una interrupción de al enfoque definida en el Capítulo 15.
alguna fuente externa (por ejemplo, otro procesador,
un Sensor), mientras que la última es controlada por Una vez que el actor y su situación de uso se defi-
el reloj. nen se identifica una jerarquía de comando. La jerar-
quía de órdenes define la mayoría de las categorías del
Además de la manera en que una tarea es inicia- menú de sistema (la barra de menú o la paleta de herra-
da, también se deben determinar la prioridad y cri- mientas), y todas las subfunciones, que estarán dispo-
ticidad de la tarea. Las tareas de alta prioridad deben nibles en el contexto de una categoría importante de
tener acceso inmediato a los recursos del sistema. menú de sistema (las ventanas de menú). La jerarquía
Las tareas de alta criticidad deben continuar ope- de órdenes se refina repetidamente, hasta que cada caso
rando aun cuando la disponibilidad de un recurso es de uso pueda ser implementado navegando por la jerar-
reducida o el sistema operativo se encuentra en esta- quía de funciones.
do degradado.
Debido a que existe una amplia variedad de entor-
Una vez que las características de la tarea se han nos de desarrollo de interfaces de usuario, el diseño de
determinado, se definen los atributos y operaciones los elementos de una IGU (Interfaz Gráfica de Usuario)
del objeto requerido, para alcanzar coordinación y no es necesario. Ya existen clases reutilizables (con atri-
comunicación con otras tareas. La plantilla básica de butos y operaciones apropiadas) para ventanas, iconos,
una tarea (para un objeto tarea), toma la forma de operaciones de ratón y una amplia gama de otro tipo de
[COA91]: funciones de interacción. La persona que implementa
estas clases (el desarrollador), sólo necesita instanciar
Nombre de l a tarea - el nombre del objeto objetos, con las características apropiadas para el domi-
Descripción - un relato que describe el propósito nio del problema.
del objeto.
Prioridad - prioridad de l a tarea (por ejemplo, a l t a , 22.2.5. Componente de la administración
media, b a j a ) . de datos
Servicios - l i s t a de operaciones que son responsa-
b i l i d a d del objeto. La administración o gestión de datos engloba dos áre-
Coordinados por - l a manera como se invoca el com- as distintas de interés: ( 1 ) la administración (gestión)
portamiento del objeto. de datos críticos para la propia aplicación, y (2) la crea-
Comunicados vía - datos de entrada y salida rele- ción de infraestructura para el almacenamiento y recu-
vantes a l a tarea. peración de los objetos. En general, la administración
de datos se diseña en forma de capas. La idea es aislar
La descripción de esta plantilla puede ser traducida los requisitos de bajo nivel que manipulan las estructu-
en el modelo de diseño estándar (incorporando la repre- ras de dafos, de los requisitos de alto nivel para mane-
sentación de atributos y operaciones), para los objetos jar los atributos del sistema.
tarea.
En el contexto del sistema, un sistema de manipula-
22.2.4. Componente de interfaz de usuario ción de bases de datos, normalmente se usa como alma-
cén de datos común para todos los subsistemas. Los
Aunque la componente de interfaz de usuario se imple- objetos requeridos para manipular la base de datos son
menta dentro del contexto del dominio del problema, la miembros de clases reutilizables que se identifican
mediante el análisis del dominio (Capítulo 21), o que
se proporcionan directamente por el fabricante de la
base de datos. Una discusión detallada del diseño de

386

httpw://lwibwre.reial-suonliuvecrisointaarirai.ob.lnogestpot.com
.

CAPfTULO 22 DISENO ORIENTADO A OBIETOS

bases de datos para sistemas O 0 está fuera del ámbito debe diseñar un mecanismo de control para ello. Rum- www.elsolucionario.net
de este libro’. baugh y sus colegas [RUM91] sugieren que cada recur-
so deba ser poseído por un «objeto guardián». El objeto
El diseño de la componente de administración de guardián es el portero del recurso, controlando el acce-
datos incluye el diseño de los atributos y operaciones so y moderando peticiones contradictorias para él.
requeridas para administrar objetos. Los atributos sig-
nificativos se añaden a cada objeto en el dominio del 22.2.7. Comunicaciones entre subsistemas
problema, y proporcionan información que responde a
la pregunta «¿Cómo me almaceno?». Coad y Yourdon Una vez que cada subsistema ha sido especificado, es
[COA911 aconsejan la creación de una clase objeto- necesario definir las colaboraciones que existen entre
servidor, «con los servicios de (a) indicar al objeto que subsistemas. El modelo que se usa para la colaboración
se almacene a sí mismo, y (b) recuperar objetos alma- objeto-objeto puede ser extendido en conjunto para los
cenados para su uso por otros componentes de diseño». subsistemas. La Figura 22.4 ilustra un modelo de cola-
boración. Como se vio anteriormente en este capítulo,
Como un ejemplo de la gestión de los datos para el la comunicación puede ocurrir estableciendo un enlace
objeto Sensor, examinado como parte del sistema de cliente/servidoro punto-a-punto.Refiriéndose a la Figu-
seguridad HogarSeguro, el diseño puede especificar un ra, se debe especificar la interacción que existe entre
archivo llamado «Sensor».Cada registro debería corres- subsistemas. Recuérdese que un contrato proporciona
ponder a una instancia denominada Sensor, y habría de la indicación de los modos como un subsistema puede
contener los valores de cada atributo de Sensor para una interactuar con otro.
instancia dada. Las operaciones dentro de la clase objeto-
servidor deberían permitir a un objeto específico ser ¿Qué etapas de diseño
almacenado y recuperado, cuando sea requerido por el se requieren para especificar
sistema. Para objetos más complejos, sería necesario un «tontrato» de un subsistema?
especificar una base de datos relacional, o una base de
datos orientada a objetos para ejecutar la misma función. Las siguientesetapas de diseño pueden aplicarsepara
especificar un contrato para un subsistema [WIR90]:
Subsistema Solicitud
cliente 1. Listar cada petición que puede ser realizada por los
colaboradores del subsistema. Organizar las peti-
Solicitud ciones por subsistema y definirlas dentro de uno o
Solicitud más contratos apropiados.Asegurarse de anotar con-
tratos que se hereden de superclases.
FIGURA 22.4. Modelo de colaboración entre subsistemas.
2 Para cada contrato,anotar las operaciones (lashere-
dadas y las privadas,) que se requieren para imple-
mentar las responsabilidades que implica el contrato.
Asegurarse de asociar las operaciones con las clases
específicas, que residen en el subsistema.

3 Considerar un contrato a la vez, crear una tabla con
la forma de la .Figura 22.5. Para cada contrato, la
tabla debe incluir las siguientes columnas:

Tipo: el tipo de contrato (por ejemplo, cliente/
servidor o punto-a-punto).

22.2.6. Componente de gestión de recursos Contrato Tipo Colaboradores Clase(s) Operación(es) Formato
del mensaje
Están disponibles una variedad de recursos diferentes
para un sistema o producto 00;y, muchas veces, los *
subsistemascompiten por estos recursos al mismo tiem-
po. Los recursos globales del sistema pueden ser enti- FIGURA 22.5. Tabla de colaboraciones del subsistema.
dades externas (por ejemplo, una unidad de disco,
procesador o línea de comunicaciones) o abstracciones
(por ejemplo, una base de datos, un objeto). Sin impor-
tar la naturaleza del recurso, el ingeniero de software

9 Los lectores interesados deben consultar [BR091], [TAY92] y
[U0941

387

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRAC TIC O .

Colaboradores:los nombres de los subsiste- grafo de colaboración es similar, en forma, al dia-
mas que son parte del contrato. grama de flujo de sucesos examinado en el Capí-
tulo 2 1 . Cada subsistema se representa, junto con
Clase: los nombres de las clases (contenidas en sus interacciones con otros subsistemas. Los con-
el subsistema), que proporcionan servicios deno- tratos que se invocan durante interacción, se deta-
tados por el contrato. llan como se muestra en la Figura. Los detalles
de la interacción se determinan observando el con-
Operaciones:nombres de las operaciones (den- trato en la tabla de colaboración del subsistema
tro de la clase), que implementan los servicios. (Fig. 22.5).

Formato del mensaje: el formato del mensaje Coda contratoentre subsistema se manifiesto por uno o
requerido para implementar la interacción entre mós mensajes que se transportanentre los objetos dentro
colaboradores. de los subsistemos.

Esboce una descripción apropiada del mensaje,
para cada interacción entre los subsistemas.

4. Si los modos de interacción entre los subsistemas
son complejos, debe crear un diagrama subsis-
tema-colaboración como el de la Figura 22.6. El

* www.elsolucionario.net

22.3 P R L OBlETQS

Retomando la metáfora que se introdujo al inicio del objeto, y detalles de procedimientos, que describen las
libro, el diseño de sistemas O 0 se puede visualizar como operaciones.
el plano del suelo de una casa. El plano del suelo espe-
cifica el propósito de cada habitación y sus caracterís- Asegúrese de que lo orquitecturose ha definido
ticas arquitectónicas, que conectan las habitaciones unas antes de comenzor eldiseño de objetos. No deje
con otras y con el ambiente exterior.Ahora es el momen- que lo arquitecturapredomine.
to de proporcionar los detalles que se requieren, para
construir cada habitación. En el contexto del DOO, el La descripción del protocolo no es nada más que un
diseño de objetos se centra en las «habitaciones». conjunto de mensajes y un comentario correspondien-
te para cada mensaje. Por ejemplo, una porción del pro-
Bennet y sus colegas [BEN99] examinan el diseño tocolo de descripción para el objeto sensor de
de objetos de la siguiente manera: movimiento (descrito anteriormente), podría ser:

El diseño de objetos tiene que ver con el diseño detallado MENSAJE(sensor.movimiento) -> leer: DEVUELVE sen-
de los objetos y sus interacciones. Se completa dentro de la sor.ID, sensor.estado;
arquitecturaglobal, definidadurante el diseño del sistemay de
acuerdo con las reglas y protocolos de diseño aceptados. El Esto describe el mensaje requerido para leer el Sen-
diseño del objeto está relacionado en particular con la especi- sor. Igualmente,
ficación de los tipos de atributos, cómo funcionan las opera-
ciones y cómo los objetos se enlazan con otros objetos. MENSAJE (sensor.movirniento) --> asigna: ENVIA sen-
sor.ID, sensor.estado;
Es en esta fase cuando los principios y conceptos
básicos asociados con el diseño a nivel de componen- Asigna (establece) o inicializa el estado del Sensor.
tes (Capítulo 16)entran en juego. Se definen las estruc-
turas de datos locales (para atributos), y se diseñan los p a r a el panel Subsistema
algoritmos (para operaciones). sensor

22.3.1. Descripciónde objetos tSolicitud de 1 de estado para la zona
de estado de prueba 1
Una descripción del diseño de un objeto (instancia de especificación
clase o subclase) puede tomar una o dos formas del tipo de Solicitud de notificación
[GOL83]: (1) Una descripción de protocolo que esta- chequeo periódica del chequeo
blece la interfaz de un objeto, definiendo cada mensaje periódico
que el objeto puede recibir y las operaciones que el obje- de estado 1 1de actualización de la
to lleva a cabo cuando recibe un mensaje, o (2) Una des- de la alarma configuración de alarma
cripción de implementación que muestra detalles de del sistema
implementación para cada operación implicada por un
mensaje pasado a un objeto. Los detalles de imple- FIGURA 22.6. Gráfico abreviado del subsistema colaborado
mentación incluyen información acerca de la parte pri- de Hogarseguro.
vada del objeto; esto significa, detalles internos acerca
de la estructura de datos, que describen los atributos del

388

www.elsolucionario.net CAPfTULO 22 DISENO ORIENTADO A OBJETOS
.

Para un sistema grande con muchos mensajes, gene- presentadosen el Coptvlo 13. www.elsolucionario.net
ralmente es posible crear categorías de mensajes. Por
ejemplo, categorías de mensajes para el objeto Sistema Se crea un algoritmo para implementar la especifi-
de Hogarseguro deberían incluir mensajes de configu- cación para cada operación. En muchas ocasiones, el
ración del sistema, mensajes de monitorización (super- algoritmo es una simple secuenciacomputacionalo pro-
visión), mensajes de sucesos, etc. cedural, que puede ser implementada como un módulo
de software autocontenido. Sin embargo, si la especifi-
Una descripción de la implementación de un objeto, cación de la operación es compleja, será necesario
proporciona los detalles internos («ocultos»), que se modularizar la operación. Las técnicas convencionales
requieren para la implementación, pero no son necesa- de diseño de componentes se pueden usar para resolver
rios para ser invocados. Esto significa que el diseñador esta tarea.
del objeto debe proporcionar una descripción de imple-
mentación, y debe por tanto crear los detalles internos Las estructuras de datos se diseñan al mismo tiem-
del objeto. Sin embargo, otro diseñador o desarrollador po que los algoritmos. Ya que las operaciones manipu-
que utilice el objeto u otras instanciasdel objeto, requie- lan los atributos de una clase, el diseño de estructuras
re solo la descripción del protocolo, pero no la descrip- de datos, que reflejan mejor los atributos, tendrán un
ción de la implementación. fuerte sentido en el diseño algorítmico de las operacio-
nes correspondientes.
Una descripción de la implementación se compone de
la siguienteinformación: (1)una especificación del nom- ¿Existe alguna manera
bre del objeto y referencia a la clase; (2) una especifica- de clasificar las operacio'nes
ción de las estructuras de datos privadas, con indicación (métodos)?
de los datos y sus respectivos tipos; ( 3 ) una descripción
de procedimientos de cada operación o, alternativamen- Aunque existen muchos tipos diferentes de opera-
te, indicadores a dichas descripciones de procedimien- ciones, normalmente se pueden dividir en tres grandes
tos. La descripción de implementación debe contener categorías: (1) operaciones que manipulan los datos de
información suficiente,para el manejo adecuado de todos alguna manera (por ejemplo, agregando, eliminando,
los mensajes descritos en la descripción de protocolo. reformateando, seleccionando),(2) operaciones que eje-
cutan cálculos, y ( 3 )operacionesque monitorizan (super-
Para alcanzar los beneficios del ocultamiento visan) al objeto para la ocurrencia de un suceso controlado.
de información (Capítulo 131, cualquiera que intente
usar un objeto solo necesita la descripción Por ejemplo, la descripción del proceso HogarSe-
del protocolo. La descripción de la implementación guro contiene los fragmentos de la oración: «al sensor
se asigna un número y tipo» y «una contraseña (pass-
contiene detalles, que deberían ((ocultarse)) word) maestra programada para habilitar y deshabilitar
de aquellos que no tienen necesidad de conocer. el sistema». Estas dos frases indican varias cosas:

Cox [COX85]caracteriza la diferenciaentre la infor- Que una operación de asignación es importante para
mación contenida en la descripción de protocolo y la el objeto Sensor.
contenida en la descripción de implementación, en tér- Que una operación programar se aplicará al objeto
minos de «usuarios» y «proveedores» de servicios. Un Sistema.
«usuario» del servicio provisto por un objeto debe ser Que las operaciones habilitar y deshabilitar se apli-
familiar con el protocolo de invocación del servicio;eso can a Sistema (finalmente se debe definir el estado
significa especificar lo que se desea. El proveedor del de sistema usando la notación adecuada en un dic-
servicio (el propio objeto), debe ocuparse del modo en cionario de datos) como:
que el servicio se suministrará al usuario; esqsignifica
con detalles de implementación. estado del sistema = [habilitado /
deshabilitadol
22.3.2. Diseño de algoritmos y estructuras
de datos Una operaciónse define en gron parte de la misma
manera en que se refina una función en el diseño
Una variedad de representacionescontenidas en el mode- convencional. Escriba uno descripción del proceso,
lo de análisis y el diseño de sistema, proveen una espe- haga un análisisgramaticoly aísle nuevas operaciones
cificación para todas las operaciones y atributos. Los
algoritmos y estructuras de datos se diseñan utilizando a un nivel de abstracción más bojo.
un enfoque, que difiere un poco de los enfoquesdel dise-
ño de datos y del diseño a nivel de componentes exa-
minadas para la ingeniería del software convencional.

389

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

La operaciónprogramar se asigna durante el AOO, ciones: instalar,definir,construir y cargar. Cada una de
pero específicamente durante el diseño del objeto se refi- estas nuevas operaciones se vuelve parte del objeto Sis-
nará un número de operaciones más específicas, que se tema, que tiene conocimiento de las estructuras de datos
requieren para configurar el sistema. Por ejemplo, des- internas, que implementan los atributos de los objetos,
pués de discusionescon el ingeniero del producto, el ana- y que se invoca enviando mensajes con el formato:
lista, y posiblemente con el departamento de marketing
(mercadotecnia), el diseñador debe elaborar la descrip- MENSAJE (sistema) -> instalar: ENVÍAteléfono.n h e r o ;
ción del proceso original, y escribirlo siguiente parapro-
gramar (subrayan operaciones potenciales -verbos-): que implica que se proporciona al sistema un número
de teléfono de emergencia, y un mensaje instalar se
Programar habilita al usuario de HogarSeguro para confi- envia al sistema.
gurar el sistemauna vez que ha sido instalado.El usuariopue-
Los verbos denotan acciones u ocurrencias. En el
de (1) instalar números de teléfonos; (2) definir tiempos de contexto de la formalización del diseño del objeto, se
consideran no sólo verbos, sino frases verbales des-
demora para alarmas; (3) construir una tabla de sensores que criptivas y predicados (por ejemplo, «es igual a»), como
operaciones potenciales. El análisis gramatical se apli-
contenga cada ID de sensor, su tipo y asignación; y (4) ca recursivamente, hasta que cada operación ha sido
refinada a su nivel más detallado.
una contraseña (password)maestra.

Por consiguiente, el diseñador ha refinado la opera-
ción simple programar, y se reemplaza con las opera-

Los mejores diseñadores en cualquier campo tienen los archivos del usuario, y proporciona facilidades www.elsolucionario.net
una habilidad extraña para reconocer patrones que para crear, renombrar y eliminar tales archiT T.
caracterizan un problema y los patrones correspon- Solo existirá una instancia de ese administrac
dientes, que pueden combinarse para crear una solu- archivos.
ción. Gamma y sus colegas [GAM95] examinan esto
cuando afirman que: En un sistema de control de tráfico aéreo, solo exis-
tirá una instancia del controlador, que mantiene regis-
Se encontraránpatrones repetidos de clases y objetos de tros de los planes de vuelo y sus posiciones.
comunicación,en muchos sistemasorientadosa objetos.Estos
patrones resuelvenproblemas específicosde diseño,y vuelven En una aplicación bancaria, solo existirá un contro-
al diseño orientado a objetos más flexible, elegante y extre- lador, que mantiene el registro de los cajeros auto-
madamente reutilizable.Ayudan a los diseñadores a reutilizar máticos utilizados por el banco.
diseños exitosos basando nuevos diseños en experiencia pre-
via. Un diseñadorbastante famihizado con ese tipo de patro- ¿Qué es un patrón de diseño
nes puede aplicarlos inmediatamente a problemas de diseño, y por qué se necesitan esos
sin tener que redescubrirlos. patrones?

Durante el proceso de DOO, un ingeniero del soft- La Figura 22.7 muestra la estructura general de este
ware debeobservar cada oportunidad en la que puedan patrón, la palabra «static» describe una variable uti-
reutilizar patrones de diseño existentes (cuando cum- lizada para toda la clase. En esta Figura solo se mues-
plen las necesidades del diseño), en vez de crear otros tran dos operaciones en la clase Singleton, pero se
nuevos. pueden mostrar algunas más dependiendo del con-
texto. A continuación se muestra un esqueleto en Java
22.4.1. ¿Qué es un patrón de diseño? para el patrón:

Antes de examinar los patrones con detalle vale la pena public class Singleton {
observar un ejemplo sencillo de un patrón, que se pre-
senta una y otra vez. Muchas aplicaciones tienen el private static ObjetoSimple instanciaünica = null;
requisito de que solo una instancia de un solo objeto
debe ser instanciada.Algunos ejemplos de aplicaciones public static ObjetoSimple instanciaunica ( )
y objetos de instancias simples son:
i
En un sistema operativo habrá solo un objeto admi- i f (instanciaünica == null )
nistrador de archivos, que mantiene el registro de
instanciaünica = new ObjetoSimple ( );

r et urn i n stanciaüni ea;

i

//Código para constructores, será privado.

//Código para métodos que implementen la escritu-
r a de

//operaciones dentro de Singleton, que pueden
incluir

390

www.elsolucionario.net CAPfTULO 22 DISEÑO ORIENTADO A OBJETOS
.

//operacionl y operacion2. El rol de Memento es el de vigilar el estado o alma-
cenamiento de recuperación del estado de un sistema,
//Código p a r a métodos que implementen operaciones cuando se requiera. La Figura 22.8 muestra el dia-
de retorno grama de clase para el patrón. Existen tres elementos
de este patrón. El primero es Clasecreadora, el cual
//en el objeto Singleton, debe i n c l u i r operación1 es una clase que describe objetos cuyo estado debe
//operaci ón2 ser almacenado. Existen dos métodos asociados con
1 esta clase: fijarValorMemento y ConstruirMemento.
El primero inicializa su estado, toma un argumento el
cual es un objeto definido por la clase Memento y
reestablece su estado con el uso del argumento. El
segundo crea un objeto de la clase ClaseMemento la
cual contiene su estado actual. En efecto, fijarMe-
mento actúa como un recurso de restauración, mien-
tras que construirMemento lo hace como un recurso
de almacenamiento.

FIGURA 22.7. La estructura general del patrón Singleton. www.elsolucionario.net

El patrón Singleton se implementa por medio de FIGURA 22.8. El patrón Memenro.
una variable de instancia estática, descrita por el atri-
buto de clase ObjetoSimple. La cual es inicializada La clase ClaseMemento define objetos que man-
con null para la instanciación. tendrán el estado de un objeto de la clase ClaseCrea-
dora. Contiene dos métodos ObtenerEstadoMemento
El acceso al objeto Singleton se realiza mediante y fijarEstadoMemento. La primera devuelve el esta-
el método instancialrnica. Este comprueba primero do que se almacena, mientras que la segunda fija el
si ObjetoSimple es igual a null. En caso afirmativo, estado a un valor pasado como argumento. El tercer
significa entonces que no se ha creado un objeto de elemento del patrón Memento es la clase cliente Care-
tipo Singleton, y que el método llamará a un cons- taker, ésta no se muestra en la Figura 22.8. Repre-
tructor privado adecuado para establecer al objeto Sin- senta una clase que implementa objetos que contienen
gleton; en el código anterior esto se realiza cuando el un objeto de la clase ClaseMemento. Tiene un con-
argumento del constructor es cero. El constructor uti- junto muy limitado de funciones ya que todo lo que
lizado se declarará como privado, ya que no se desea realiza es almacenar un Memento, no altera ni exa-
que ningún usuario pueda crear objetos de tipo Sin- mina los contenidos de un memento.
gleton, excepto si es por medio de instancialrnica, la
cual se ejecutará, de una vez y por todas, en el momen- 22.4.3. Un ejemplo final de un patrón
to de la creación. La clase también contendrá méto-
dos, que ejecutarán operaciones en un objeto de tipo Frecuentemente, existe la necesidad de desarrollar
Singleton. un código que lleve a cabo el procesamiento de
datos accedidos secuencialmente. Este acceso
De este modo, si el patrón Singleton se utilizara en secuencia1 tendrá usualmente la misma forma, y por
un sistema de control de tráfico aéreo, y solo se nece-
sitara un controlador de aeronaves, entonces el nom-
bre de la clase anterior debena ser ControladorAéreo,
y debería tener métodos tales como obtenerlontro-
ludorAéreo, que devuelve la Única instancia de un con-
trolador de tráfico aéreo.

22.4.2. Otro ejemplo de un patrón

Se ha visto ya un ejemplo de un patrón: Singleton. El
objetivo de esta sección es describir un patrón más
complicado, conocido como Memento.

""c%V E

El patrón de Memento se usa
para la recuperación de sistemas.

391

whttwp:w//l.iebrlesroialu-ucnioivnerasritiaor.ina.ebtlogspot.com

I N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE PRÁCTICO .

esto es adecuado para un patrón. El objetivo de esta ciados con las clases FiltroFuenteConcreto, que www.elsolucionario.net
sección es describir tal patrón; ello es debido a realizarán algún tipo de procesamiento con los
Grand [GRA99]. Algunos ejemplos de procesa- datos.
miento secuencial son:
22.4.4. Descripción de un patrón de diseño.
Un programa de informes debe procesar un archivo Las disciplinas maduras de ingeniería hacen un vas-
de datos de empleados, leyendo cada registro y dese- to uso de patrones de diseño. La ingeniería del soft-
chando todos aquellos registros de empleados que ware solo se encuentra en su infancia, con el uso de
ganen por encima de una cierta cantidad. patrones. De cualquier manera, se está procediendo
rápidamente hacia el comienzo de una taxonomía.
Un programa editor puede ser consultado por su usua- En general, la descripción de un patrón como parte
rio, para listar las líneas de texto de un archivo que de una taxonomía debe proporcionar [GAM95]:
coincidan con un cierto patrón.
Nombre del patrón. Por ejemplo Filtro.
Un programa de análisis de la Web debe leer el
código fuente de un documento HTML, para descu- Intención del patrón. Por ejemplo, un patrón debe
brir cuantas referencias a otros sitios contiene el docu- tener la intención de facilitar el mantenimiento,
mento. pues puede acomodar un número de diferentes tipos
de objeto.
¿Qué hace el Filtro?
Los problemas de diseño que motivan el patrón.
Estas son formas diferentes de procesamiento; de Por ejemplo, un patrón debe desarrollarse, para que
cualquier manera, están unidos por el hecho de que un número de transformaciones diferentes de datos
el procesamiento de datos es de manera secuencial. puedan ser aplicadas a un objeto, muchas de las
Este procesamiento debe hacerse con base en pala- cuales son desconocidas, cuando el patrón es desa-
bra por palabra, o con base en registro por registro; rrollado originalmente.
a pesar de ello, también se aplica al procesamiento
secuencial, y de aquí que sea una buena oportunidad ¿Cómo se describe un patrón
de capturarse en un patrón. Este patrón, conocido de diseño?
como Filtro, se muestra en la Figura 22.9. Consta de
varias clases: La solución que resuelve estos problemas.

FiltroFuente. Esta es la clase que actúa como Las clases que se requieren para implementar la
superclase para otras clases concretas, que imple- solución. Por ejemplo, las cuatro clases descritas
mentan el procesamiento requerido. La clase no en la Figura 22.9.
lleva a cabo la recuperación de los datos que se
procesarán, pero delega eso al objeto Fuente, cuya Las responsabilidades y colaboraciones entre las
clase será descrita en la tercera viñeta siguiente. clases de solución. Por ejemplo, una clase debe ser
El objeto Fuente se pasa por medio del constuc- responsable de la construcción de un objeto, cuyo
tor a la clase. La clase contiene un método llamado comportamiento varía al tiempo de ejecución.
obtenerDatos, que recupera los datos que se pro-
cesarán. Lineamientos que conduzcan a una implementa-
ción efectiva. Generalmente, existirá un número
FiltroFuenteConcreto. Esta es una subclase de la de formas diferentes de programar un patrón; por
clase FiltroFuente. Redefine el método obtenerDa- ejemplo, el procesamiento de errores debe ser tra-
tos, para realizgr algunas operaciones extras en los tado de diferentes formas.
datos que han sido leídos, por ejemplo si el patrón
se utiliza para contar las cadenas de caracteres que Ejemplos de código fuente.
coinciden con cierto patrón, el código para realizar
este recuento se coloca aquí. Normalmente este Referencias a otros patrones de diseño, o patrones
método utiliza el método correspondiente obtener- que puedan usarse en conjunto con el patrón des-
Datos, dentro de la super-clase. crito.

Fuente. Esta clase se asocia con los objetos, que lle- 22.4.5. El futuro de los patrones
van a cabo el proceso de recuperar los datos que se
procesarán. Esto se logra por medio de un método En la actualidad, se ha desarrollado y catalogado un
llamado obtenerDatos. número relativamente pequeño de patrones. De cual-
quier manera, los últimos cinco años han sido testi-
Fuenteconcreta Esta clase es una subclase de gos de una tremenda explosión, en términos de
Fuente e implementa el método obtenerDatos. Su interés industrial. Los patrones, junto con los com-
función es proporcionar datos a los objetos aso- ponentes, ofrecen la esperanza de que la ingeniería
de software, eventualmente, se parezca a otras dis-

392

www.elsolucionario.net CAPfTULO 22 DISENO ORIENTADO A OBJETOS
.

ciplinas de ingeniería, con clases volviéndose el aná- I IFiltroFuente y FiltroFuenteConcreto
logo en software de componentes electrónicos, y los wro no se muestran
patrones volviéndose el análogo en software de abstracto)) ObtenerDatosO
pequeños circuitos hechos de componentes. Antes
de que esto suceda, existe aún una ingente cantidad f
de trabajo que llevar a cabo al identificar patrones y
catalogarlos; también, se producirá esta situación, &Fuente
cuando el número de patrones existentes se vuelva
tan grande, que se necesite una forma de indexado FIGURA 22.9. El patrón Filtro.
automática o semiautomática.

fq%

CLAVE

En la actualidad existe un buen grupo de pahones;
sin embargo, en los próximos años debería haber
una verdadera expansión en su uso.

El objetivo de esta sección es describir,con un grado de todos (os atributos www.elsolucionario.net
mayor detalle, el conjunto de notaciones que componen
el lenguaje UML. Anteriormente, en el Capítulo 21, se
describen su origen y componentesprincipales; de hecho,
muchos de los diagramas presentados en el Capítulo 21
y en este capítulo han sido expresados en UML. Se ha
tomado la decisión de utilizar esta notación, porque se ha
vuelto predominante muy rápidamente en aquellascom-
pañías que utilizan ideas de ingeniería para desarrollar
software orientado a objetos. El primer componente que
se intenta describir es el modelo de clases.

fq$

CLAVE

UMLse está convirtiendo en un estándar de fado
para el análisis y diseño orientado a obietos.

22.5.1. El modelo de clases FIGURA 22.10. Un ejemplo de una clase descrita en UML.

Un modelo de clases es una descripción de las clases en También en la Figura 22.10 se muestra una ver-
un sistema y sus relaciones. No describe el comporta- sión gráfica de los comentarios utilizados en el len-
miento dinámico del sistema, por ejemplo el compor- guaje de programación. El cuadro, con una esquina
tamiento de objetos individuales. El primer elemento superior derecha doblada, llama la atención del lec-
de un diagrama de clases es una descripción de clases tor a algún aspecto de un diagrama. En el caso de la
individuales. La Figura 22.10 muestra como se descri- Figura 22.10, se llama la atención del lector, al
be una clase. La clase describe al cliente de un banco. hecho de que muchos de los atributos y operaciones
asociados con la clase Cliente no se muestran; por
Esta figura es muy simple, ya que solo contiene una ejemplo, la colección de cuentas que posee el clien-
clase. Consta del nombre de 1á clase (Cliente),el nom- te no se muestran en la sección de atributos de la
bre de algunos de sus atributos, por ejemplo el atribu- clase.
to dirección, que contiene la dirección del cliente, y la
lista de operaciones; por ejemplo, la operación obte- La Figura 22.10 es muy simple, en la práctica los
nerNombre recupera el nombre de un cliente. Cada cua- diagramas de clases en UML mostrarán la relación
dro que representa una clase contiene, por consiguiente, entre clases. Existe un gran número de tipos diferen-
una sección que contiene el nombre de la clase, una sec- tes de relaciones, que pueden ser expresadas. La pri-
ción que enumera los atributos de los objetos definidos mera cosa que tratemos será la generalización.
por la clase, y una sección que describe las operaciones
asociadas con tales objetos.

393

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

22.5.2. Generalización 22.5.3. Agregación y composición

Esta relación es la que se mantiene entre una clase X y La sección anterior describió una relación, que puede
ser representada en un diagrama de clases UML: gene-
otra clase Y, cuando la clase Y es el ejemplo más espe- ralización; las otras relaciones importantes son la agre-
cífico de la clase X. Por ejemplo, una relación de gene- gación y la composición. Existen dos relaciones que
ralización existe entre una clase Cuenta, la cual establecen que una clase genera objetos, que son parte
representa una cuenta bancaria general, y una cuenta de un objeto definido por otra clase. Por ejemplo, un
corriente, que es un ejemplo específico de una cuenta. sistema para un fabricante tendrá la necesidad de man-
La Figura 22.11 muestra como se representaría esta rela- tener los datos acerca de los elementos que se están
ción en un diagrama de clases UML. fabricando, y de aquellos que se están haciendo. Por
ejemplo, un ordenador se fabricm’a a partir de una exten-
Cuentacorriente Depósito sa serie de componentes incluyendo su armazón, un dis- www.elsolucionario.net
co duro, un conjunto de tarjetas de memoria, etc. El
ordenador se construye, a partir de una serie de com-
ponentes y en un sistema orientado a objetos utilizado
para dar soporte al proceso de fabricación, existirá una
relación de agregación entre la clase utilizada para des-
cribir el producto fabricado y cada uno de sus compo-
nentes. La Figura 22.12 muestra como se representa esta
relación, en un diagrama de clases UML.

Aquí una clase Cuenta tiene una relación de genera- ¿Qué es agregación?
lización con las clases más específicas,como son Cuen-
tacorriente y Depósito. Esta relación se representa por Aquí la línea con un rombo hueco en un extremo
medio de una flecha, que apunta de la clase más espe- indica que la clase describe objetos que agregan otros
cífica hacia la clase más general. Una vez más, obser- objetos, la clase con el rombo unido a ella describe obje-
ve que, para propósitos ilustrativos, no se muestra tos, que contiene objetos definidos por la otra clase. En
ninguna operación o atributo. UML las relaciones normalmente se mezclan. Por ejem-
plo, la Figura 22.12 habrá un número de componentes,
que posean una relación de generalización con la clase
Componente.

FIGURA 22.12. Agregación en UML. T’Cliente

ColecciónCuentas

ProductoManufacturado FIGURA 22.14. Un diagrama UML de clases mostrando
composición.
~
Esto se muestra en la Figura 22.13, donde Compo-
1 nente se asocia con un número de clases más específi-
cas, que describen los componentes con los que un
I ComDonente C producto fabricado puede ser ensamblado.

¿Qué es composición?

FIGURA 22.13. Un diagrama UML de clases mostrando Existe una forma especial de agregación, conocida
generalización y agregación. como composición. Ésta se usa cuando se tiene una
situación en la que un objeto contiene un número de
otros objetos, y cuando el objeto contenedor se elimi-

394

www.elsolucionario.net CAPITULO 22 DISENO ORIENTADO A O B J E T O S
.

na todas las instancias de los objetos que están conte- mo de la línea determina que un administrador dirige a www.elsolucionario.net
nidos desaparecen. Por ejemplo, una clase Cliente que un conjunto de empleados.
representa clientes en un banco tendrá una relación de
composición con las cuentas que el cliente posee; por- La asociación entre clases puede nombrarse para
que si el cliente se elimina, por ejemplo, se mueve a otro documentar explícitamente la relación. Por ejemplo, la
banco, todas sus cuentas son eliminadas; esta forma de Figura 22.17 documenta el hecho de que un adminis-
relación se indica de manera muy similar a la agrega- trador dirige a un grupo (colección) de empleados.
ción, pero en esta ocasión el rombo está relleno en lugar
de hueco. Esto se muestra en la Figura 22.14. MAdministrador

22.5.4. Asociaciones I1
La agregación y la composición son ejemplos específi-
cos de una relación entre dos clases. Una relación ocu- 1 11 1..*
rre entre dos clases cuando existe alguna conexión entre Empleado
ellas, en UML esto se conoce como asociación. Algu-
nos ejemplos de esto se describen a continuación: FIGURA 22.16. Multiplicidad en un diagrama de clases
en UML.
Una clase Administrador se relaciona con la clase
Empleado en virtud de que un administrador dirige Una alternativa para documentar la asociación es
a un número de empleados. documentar los papeles (roles) que cada clase juega en
Una clase Vuelo se asocia con la clase Avión en vir- una asociación. Un ejemplo de esta situación se mues-
tud de que un avión emprende un vuelo particular. tra en la Figura 22.18. Aquí, la clase Universidad jue-
Una clase Computadora se relaciona con una clase ga el rol de hospedar una serie de estudiantes que, a su
Mensaje en virtud del hecho de que una colección vez, juegan el rol de ser estudiantes miembros de la uni-
de mensajes está esperando el proceso de una com- versidad. Normalmente, cuando se documentan las aso-
putadora. ciaciones, se elige el tipo de documentación que se
Una clase InformeBancariose relaciona con la clase utilizará: si la documentación de asociación o la docu-
Transacción en virtud de que el informe contiene mentación de roles de clases que participan en la aso-
detalles de cada transacción. ciación. El realizar ambos, aunque perfectamente válido,
De estas relaciones, sólo la última es de agregación. se considera como un exceso.
Todas las otras son asociaciones claras. Tales asocia-
ciones se escriben en UML como una línea recta. Por pizzGZ-1
ejemplo, la Figura 22.15 muestra la primera asociación
de las anteriores. Empleado
Las asociaciones entre clases se documentan en tér-
minos de la multiplicidad de la asociación y del nom- FIGURA 22.17. Documentando una Asociación.
bre de la asociación. A continuación se observará la
multiplicidad, examinando el ejemplo de la Figura 22.5.5. Casos de uso
22.15. En este ejemplo un simple administrador dirige Anteriormente, en el Capítulo 21, se examinaron los
a uno o más empleados, y un solo empleado será diri- casos de uso. En UML, un caso de uso se documenta
gido por un solo administrador.Esta asociación se mues- de manera muy simple, en términos de actores y de un
tra en laFigura 22.16. caso de uso. Un actor es cualquier agente que interac-
túa con el sistema que se construye, por ejemplo el pilo-
wAdministrador to de un avión, un prestatario de libros de una librería
o el jefe de los empleados en una compañía. Un caso de
FIGURA 22.15. Un ejemplo de una relación simple en UML. uso documenta alguna acción que el actor ejecuta; por
ejemplo, el préstamo de un libro, el cambio de direc-
Aquí el 1 que se encuentra al final de la línea de aso- ción de un avión o la adición de un miembro a un equi-
ciación indica que un empleado solo es dirigido por un po de programación. Un caso de uso simple se muestra
en la Figura 22.19. Se muestra el usuario de una biblio-
administrador;y el 1..* que se encuentraen el otro extre- teca que pide prestado un libro.

395

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

Universidad La existencia de un gran número de casos de uso sig- www.elsolucionario.net
nifica que habrá algunos casos de uso que serán utili-
11 '~ zados por otros casos de uso. Cuando esto sucede, el
diagrama de casos de uso UML va a incluir una etiqueta
Hospedar conocida como un estereotipo <<uses», sobre la fle-
cha que conduce al caso de uso. Se muestra un ejemplo
Estudiante Miembro ,,,* en la Figura 22.21, la cual muestra algunos casos de uso,
involucrados con un sistema para la administración de
Estudiante productos en un almacén (Warehouse).Por ejemplo, el
administrador del almacén puede hacer una petición a
FIGURA 22.18. Documentando roles. nivel de existencias de un producto en particular.Al lle-
var a cabo estas funciones, el administrador del alma-
El actor en este caso es el prestatario, que utiliza la cén genera un número de casos de uso, cada uno de los
biblioteca, y el círculo ovalado muestra el caso de uso cuales hacen uso de otro caso de uso, que valida el nom-
con el mismo nombre debajo. Los casos de uso repre- bre del producto al que se hace referencia en el caso de
sentan una visión, a un alto nivel funcional, de un sis- uso para revisar; por ejemplo, que el administradorhaya
tema en UML. En general, un sistema grande debe escrito un nombre de producto válido.
contener centenares, si no millares de casos de uso. Un
fragmento de un grupo de casos de uso relacionadoscon Aquí, el hecho de que un caso de uso se emplee por
el mismo actor se muestra en la Figura 22.20. otros casos, se indica por medio de una flecha con pun-
ta hueca.

/\ ((uses))
Administrador -b
del almacén. __c_

Prestatario Pedir prestado un libro :\ Consultar nivel H Validar

FIGURA 22.19. Un caso de uso sencillo. de uso asociados 1

con unadministrad(

Muestra algunas de las acciones que un administra- de orden
dor de proyecto debe llevar a cabo, cuando interactúa
con un sistema de administración de proyectos. FIGURA 22.21. Un ejemplo de casos de uso utilizando otro
caso de uso.

\Administrador Emitir informe de estado 22.5.6. Colaboraciones

Terminar proyecto Durante la ejecución de un sistema orientado a obje-
tos, los objetos interactuarán con cada uno de los otros.
Iniciar Proyecto Por ejemplo, en un sistema bancario, un objeto Cuen-
ta puede enviar un mensaje a un objeto transacción
FIGURA 22.20. Un conjunto de casos de uso. para crear una transacción que ha ocurrido en una cuen-
ta, por ejemplo una cuenta de cargo. Este tipo de infor-
mación es importante para el diseñador de un sistema
orientado a objetos, durante el proceso de la identifi-
cación y validación de clases. Por esta razón, UML
tiene dos notaciones equivalentes para definir las inte-
racciones. En este libro nos centraremos sólo en uno:
el diagrama de secuencias; el otro diagrama se cono-
ce como diagrama de colaboración, y es equivalente
al diagrama de secuencia; de hecho, son tan similares
que las herramientas CASE pueden normalmente cre-
ar un diagrama, a partir de una instancia o de la otra.
La Figura 22.22 muestra un ejemplo simple de un dia-
grama de secuencias.

396

httpw://lwibwre.reial-suonliuvecrisointaarirai.ob.lnogestpot.com
. CAPfTULO 22 DISENO ORIENTADO A OBJETOS

En este diagrama existen tres objetos, los cuales Aquí un actor, representado por un objeto anónimo
se involucran en una interacción. El primero es el definido por la clase InformeBalance, envía un men-
objeto administrador descrito por la clase Emplea- saje al objeto cuenta, que consulta la cuenta.
do. Esto envía un mensaje actualizarlnforme a un
objeto llamado informeventus, el cual envía un men- Este objeto comprueba si es una cuenta válida, y lue-
saje crearTransacción a un objeto transacción- go envía un mensaje generarZnformeBaZance a un obje-
Ventas. to informeBalance, que contiene los datos requeridos
por el cliente del banco.

viejocliente: A 22.5.7. Diagramas de estado
ClienteBanco
actualizar Inform-e ; Otro componente importante de UML es el diagrama
de estado. Este muestra los diferentes estados en que un
u :; crearTransacción objeto se encuentra, y cómo se dan las transiciones de
cada estado a otros estados. Tal diagrama contiene los
::cambiar Detalles F siguientes componentes:

Estados: se muestran dentro de cuadros, con esqui- www.elsolucionario.net
nas redondeadas.

Transiciones entre estados mediante flechas.

FIGURA 22.22. Un diagrama de secuencia sencillo. ¿Qué es un diagrama

En el diagrama de secuencia existen tres objetos de estados?
involucrados, uno de ellos (administrador)tiene su
clase específica (Empleado), los otros no. Los con- Sucesos que provocan las transiciones entre estados.
tenidos en los cuadros de un diagrama de secuen- Marca de inicio, que muestra el estado inicial, en el
cia pueden contener solo el nombre del objeto, el que un objeto se encuentra cuando se crea.
nombre de un objeto junto con su clase separado Marca de parada (fin),que indica que un objeto ha
por dos puntos, o solo el nombre de una clase pre- alcanzado el final de su existencia (vida).
cedida de dos puntos; en este último caso, el obje-
to es anónimo. /" 7

La Figura 22.22 también muestra el rol de un actor /Cerrarcuenta
dentro de una colaboración: aquí el actor ClienteBan-
co y Viejocliente, interactúa con el administrador del Transacción Cuenta vacía
objeto Empleado, enviando un mensaje cambiarDe-
talles.

La Figura 22.23 muestra otro ejemplo de un diagra-
ma de secuencias.

9 [ T I linBfoailmancee-)

,/ \

:ClienteBanco

; ,consultacuenta

FIGURA 22.24. Ejemplo de un diagrama de estados.

Un ejemplo de diagrama de estados se muestra en la

Figura 22.24.

Aquí se muestra el ciclo de vida de una cuenta ban-

F----lJ1 generarlnformeBalance caria. Cuando la cuenta se crea, se visualiza como una
cuenta vacía. Hasta que una transacción se lleve a cabo
(los fondos depositadoso retirados de la cuenta se visua-

lizan como una cuenta activa). El diagrama de estado

también muestra que, cuando una cuenta se cierra, se

FIGURA 22.23. Otro ejemplo de diagrama de secuencia. destruye.

397

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

El objetivo de esta sección es mostrar el uso de diagra- 6. El sitio web deberá interactuar con un sistema de www.elsolucionario.net
mas UML, descrito en la Sección 22.25, aplicado a un control de inventario, que también requiere desarro-
sistema real. Este sistema es un sistema de comercio llo. Este sistema de control de inventarios debe mane-
electrónico (e-commerce). jar el proceso de recepción de libros de los inventarios
de las editoriales, retiro de libros cuando se ordenan
22.6.1. Libros-en-línea por parte de un cliente, y reordenación de existencia
de un libro, cuando se encuentra por vaciarse, para
Libros-en-línea es una compañía creada reciente- encarar un problema de suministros, en un tiempo
mente, que es subsidiaria de otra gran compañía mul- de siete días.
tinacional de comercio, conocida como Pollday
Publishing. Los directores de Pollday Publishing se 7. El control de inventarios por parte del administrador
decidieron a llevar a cabo un gran crecimiento en ven- será fijado en un tiempo de siete semanas. Él o ella
tas por internet entre sus clientes, y decidieron pre- tendrán la responsabilidad de mantener las ventas, y
parar a Libros-en-Línea para ello. El concepto que la disponibilidad de existencias y, cuando las exis-
Pollday tiene es el de un sitio Web de comercio elec- tencias de un libro se encuentren bajas, hacer un
trónico, que tenga catálogos detallados de cada libro nuevo pedido. Para realizar esto, este sistema de con-
que manejan, junto con recursos con los que el usua- trol de inventarios debe proporcionar informes de
rio del sitio Web puede ordenar libros, utilizando una ventas y existencias de inventario con regularidad.
forma incluida en una página Web. A continuación,
se muestran algunos extractos, tomados del conjun- 8. Un Administrador de Marketting intervendrá cada
to de requisitos iniciales, detallados por el equipo téc- ocho semanas. El Jefe de Marketting tendrá la fun-
nico de Libros-en-línea: ción de determinar los precios a los que los libros
serán vendidos. Se dará la situación de que un libro
1. Libros-en-línea desea desarrollar la capacidad de puede tener un número diferente de precios durante
ventas en línea por medio de la Web. EL sitio web su tiempo de vida; por ejemplo, se debe decidir si se
que implementa esta capacidad debe permitir al ofrece con un mayor descuento durante las primeras
cliente examinar los detalles del libro, ordenarlo y semanas, y luego ajustar el precio a los precios reco-
registrar su dirección de correo electrónicopara reci- mendados por las editoriales.
bir ofertas especiales con detalles, publicaciones nue-
vas y revisiones. La compañía que desarrolló el software para Libros-
en-línea, primero identificó un número de clases candi-
2. Cuando un cliente accede al sitio Web, cada uno de datas, que a continuación se detallan:
los recursos antes descritos se despliegan.
RegistroCliente. Detalles de alguien que compra
3. Si el cliente registra su dirección de correo electró-
nico, se le preguntarán su informaciónpersonal. Esto libros, o que se registró para recibir correos electró-
incluye su nombre, una dirección de correo electró- nicos con información.
nico, una dirección postal. Un miembro del equipo Libro. El artículo principal, qué Libros-en-línea
conocido como el administrador de contratos será el
responsable de enviar información de oferta, etc., a vende.
los clientes. Orden. Una orden que un cliente realiza, para uno

4. El cliente podrá comprar libros del catálogo en o más libros. Esta orden debe ser para una simple
línea, examinando las páginas con detalles de los copia de un libro, o para copias de un número de
libros y seleccionando el libro, que comprará libros o incluso múltiples copias de muchos libros.
mediante algún mecanismo como el de presionar Una orden contendrá un número de líneas de orden
un botón. El sistema deberá mantener un carrito de (véase a continuación),y una especificación de envío.
compras virtual, en el que los detalles de cada libro LíneaDeOrden. Esta es una simple línea de orden.
se almacenan. Conforme el carrito se va llenando
de libros, se muestra al cliente el precio acumulado Por ejemplo la orden de la copia de un libro. Una
de todas sus compras. orden consistirá en una o más líneas de orden. Una
línea de orden contendrá información acerca de
5. Cuando el cliente ha terminado de comprar en el sitio qué libro se ordena y la cantidad ordenada (usual-
Web, se le pedirá información acerca de qué forma mente 1).
de envío se utilizará. Por omisión se mostrará la Carrito. Es un contenedor que existe durante la
opción de envío por correo estándar, y un servicio
de envío expreso garantizado para entregar dentro exploración del sitio Web, por parte de un cliente que
de 24 horas. realiza una orden. Los contenidos del carrito serán
líneas de orden. Cuando un cliente complete una
orden, las líneas de orden del carrito y la informa-
ción de envío proporcionada por el usuario serán ane-
xadas a una orden.

398

www.elsolucionario.net CAPfTULO 22 DISENO ORIENTADO A OBJETOS
.

OrdenEspera. Esta es una parte de la orden, la cual Estas fueron, entonces, las clases identificadasprinci- www.elsolucionario.net
no puede cumplirse por las existencias del almacén. palmente.También se identificaronun número de actores:
Si el cliente está conforme, esperando por un libro
que no está en existencia, entonces se realiza una Cliente. Este es el actor principal: la persona que
orden de espera. Esta orden de espera se satisface, lleva a cabo las acciones, que resultan en los mayo-
cuando las existencias del libro se restauran por res cambios de estado del sistema.
Libros-en-línea. Administrador de marketting. Es un actor importante
que ajusta muchos de los parámetros del sistema,
Almacén. Esta es una colección de libros que se tales como el precio de los libros.
encuentran en existencia. Una orden de libro o de Administrador del control de inventarios. Alguien
colección de libros se manda al almacén y de ahí que controla los inventarios en un almacén y toma
se retiran los libros de sus cajas del almacén, se decisiones acerca de las órdenes.
empaquetan y se despachan al cliente. En ese
momento, se ajustan los detalles de las existen- Existen un gran número de casos de uso asociados
cias. con estas acciones, muchas de ellas asociados con el
actor cliente, se muestran en la Figura 22.25.
RegistroExistencias. Estos son los datos que des-
criben los detalles de las existencias de un libro; La selección de casos de uso asociadoscon el Cliente,y
por ejemplo, cuántos hay en existencia, el nivel las mostradasen la Figura 22.25 incluyen casosde uso para:
actual cuando se ha hecho una requisición a las edi-
toriales, y la localización de los libros dentro del Registro. Aquí el cliente proporciona su nombre y
almacén. su clave. Una vez registrada, pueden examinar el
catálogo de libros.
NotaEmpaque. Esta es una nota enviada con una Ordenar.Aquí el cliente ordena una o más copias de
colección de libros al cliente. La nota de empaque un libro.
contiene información acerca de cuántos libros se Realizar. El cliente completa la orden y ordena al sis-
enviaron y la tarifa de envío aplicada. También puede tema iniciar el proceso en que la orden se despacha.
contener detalles de algunos libros, que no pudieron Buscar un libro. El cliente busca, en el catálogo en
ser enviados porque no se encontraban en las exis- línea, un libro específico.
tencias. Eliminar tarjeta de crédito.Aquí el cliente puede eli-
minar una o más de las tarjetas de crédito registra-
Tarjetacrédito. Un cliente pagará por sus libros das y asociadas con él.
mediante una tarjeta de crédito. El sistema permite Registrar tarjeta de crédito. Aquí el cliente registra
al cliente pre-registrar su o sus tarjetas, para que una o más de sus tarjetas de crédito al sistema.
no tenga que reescribirlas cada vez que haga una Una porción de uno de estos diagramas de clase para
orden. el sistema, se muestra en la Figura 22.26. Un número
de roles asociados con el diagrama se ha omitido; regu-
Registro larmente se incluyen. Algunas de las relaciones entre
clase, también se omitieron.
Q-’/-/--/--- El diagrama muestra muchas de estas clases antes
A\ Comprobar pedido descritas. Las únicas clases que se omitieron son:
Ordensatisfecha y OrdenEspera. Estas dos clases son
especializacionesde la clase Orden, que representa una
orden de libros para un cliente.

DeQrden

Borrar tarjeta
de crédito

Registrar FIGURA 22.26. Una sección de un diagrama de clases
tarjeta de crédito para el caso de estudio.

FIGURA 22.25. Algunos casos de uso para el actor Cliente.

399

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

Cuando se hace un pedido, algunos de los artículos entre tarjetas de crédito y órdenes, en virtud de que una www.elsolucionario.net
pedidos pudieron no haberse servido, porque los libros tarjeta de crédito particular se utiliza para pagar una
no estaban en existencia. Cuando esto ocurre, la orden orden. De cualquier manera, se muestra suficientedeta-
se divide en dos: todos los libros que pueden propor- lle para proporcionar una indicación de qué tan com-
cionarse en un objeto Ordensatisfecha, y aquellos que plicado se ve un diagrama de clases UML.
no pudieron encontrarse, se registran en un objeto Orden-
Espera. Las relaciones en el diagrama de clases se deta- Un ejemplo de diagrama de secuencias asociado con
llan a continuación. el caso en estudio se muestra en la Figura 22.27.

Un almacén se asocia con un número de registros de Aquí el cliente ordena un libro. Esto resulta en el
existencias, los cuales detallan los libros almacena- registro de existencias para el libro consultado,y se ajus-
dos en el almacén. Un simple almacén se asocia con ta si el libro está en existencia. Si el libro está en exis-
uno o más registros de existencia. tencia, un objeto de tipo línea de orden se crea, el cual
se anexa a una orden, la cual se construye conforme el
Un registro de existencia se asocia con un solo libro, cliente navega por el sitio web de Libros-en-línea. El
y un libro se asocia con un solo registro de existencia. diagrama final (Fig. 22.28) muestra un diagrama de esta-
do para el objeto Orden.
Una orden puede consistir en un número de líneas
de orden, y una línea de orden será asociada con una Un cliente primero realiza la orden, y el estado del
sola orden. objeto Orden se vuelve orden parcial; entonces se da al
cliente la opción de añadir más libros o de eliminar libros
Un cliente registrará su número de tarjeta de crédito de su orden. En cualquier momento de la construcción
al sistema, un número de tarjeta de crédito se asocia de la orden, el cliente puede cancelar la orden, esto con-
con un solo cliente. duce a la terminación. Cuando el cliente indica que se
ha llegado al fin de la orden, entonces la orden se vuel-
Un cliente se asocia con un número de órdenes satis- ve una orden de libros completa. En este punto, el clien-
fechas, las cuales se realizan sobre un período de te tiene dos opciones: cancelar al orden o especificarel
tiempo. Cada orden satisfecha se asocia con un solo tipo de envío que se usará para la orden. Si se seleccio-
cliente. na el tipo de envío, entonces la orden se convierte en
una orden completa. En esta etapa, el cliente tiene otras
Un cliente se asocia con un número de órdenes en dos opciones: confirmar la orden, en este caso la orden
espera, que actualmente no pueden ser satisfechas. se envía para ser procesada, o cancelar la orden. Ambas
Cada orden en espera se asocia con un solo cliente. opciones conducen al punto de salida del diagrama de
estados.
La Fig-ura 22.26 muestra solo al-gunas de las rela-
cienes involucradas, por ejemplo, existe una relación

TOS

La etapa final de desarrollo, dentro del ciclo de vida Un ejemplo del código esqueleto de una clase se mues-
orientada a objetos, es la programación. No es la tra a continuación.
intención de este libro llegar a más detalle acerca de
este proceso; la programación es analizada como clacc Cliente {
importante pero como actividad subsidiaria al análi- private String NombreCliente;
sis y diseño; pero se proporciona una pequeña intro- private String DireccionCliente;
ducción en el lenguaje de programación Java. La // se definen más atributos aquí
sección otras lecturas y fuentes de información al public String obtenerNombreCliente/)
final del capítulo detalla un gran número de buenos i
libros sobre el tema. //código para obtenerNombreCliente
1
El proceso de programación involucra la conversión public void modificarDireccionCliente( String
de un diseño orientado a objetos en un código de pro- direccionj
grama. Efectivamente,esto significa que las clases defi- i
nidas en el diseño deben ser convertidas en clases //código para modificarDireccionCliente
expresadas en un lenguaje de programación orientado 1
a objetos como Java, C++ o SmallTalk. Esta sección se
concentra en Java, que se está volviendo rápidamente //código para las operaciones restantes
el lenguaje de programación de facto, para desarrollar 1
los modernos sistemas distribuidos.
La primera línea de código define que el nombre de
Una clase en Java se introduce por medio de la pala- la clase será Cliente. Inmediatamente a continuación,
bra clave class, dentro del código para la clase; el pro- las descripciones de atributos de clase. En el código
gramador define los atributos y operaciones para la clase. anterior, solo se muestran dos atributos: el nombre del

400

www.elsolucionario.net CAPÍTULO 22 DISENO ORIENTADO A O B J E T O S
.

cliente y su dirección; ambos se expresan como cade- La palabra clave String especificaque esta operación
devolverá una cadena, y la palabra clavepublic descri-
nas de caracteres. Normalmente, en un sistema real exis- be el hecho de que cualquier código de cualquier otra
clase puede hacer uso de esta operación: public es el
ten muchos más atributos asociados con la clase. La opuesto de la palabra claveprivate, detalladaen el párra-
fo anterior.
descripción del atributo incluye su tipo (String)y su
El código para esta operación se encierra con llaves
visibilidad. En el ejemplo anterior, a los dos atributos
(1 }) de operación.
mostrados se les asigna la visibilidad de privados. Esto
La operación modificarDirecciónC1iente difiere en
significa que pueden ser accedidos por cualquier códi- dos cosas de la operación obtenerNombreCliente. En
primer lugar, le antecede la palabra void; esto indica que
go dentro de la clase pero no por alguno fuera de ella; no hay resultado que regresar de la operación: la ope-
ración solo lleva a cabo acciones que modifican los atri-
por ejemplo, el código que pertenece a otra clase. Esto butos de la clase. En segundo, la operación asociada con
el argumento dirección, que es una cadena que repre-
significa que las variables de instancia se encapsulan senta la nueva dirección de un cliente, que reemplaza-
rá a la anterior.
dentro de la clase. Existen otros modificadores de visi-
Esto, entonces, es la forma básica de una clase en
bilidad en Java: Se encontrará con otro después, cuan- Java; es muy similar en muchas formas a la estructura
de clases expresadapara los lenguajes orientadosa obje-
do se describan las operaciones de una clase. tos, con excepción de SmallTalk. A continuación, se
muestra el código completo de una clase muy simple.
CRegistroStoci [ G q/ \-AceptaciónOrden ; La clase representa un contador, que es un dispositivo
que sirve para registrar el número de veces que una pági-
:Cliente na web ha sido accedida por visitantes de un sitio Web.

0OrdenLibro class Contador í
(:DLeinOerdae-)n private int veces; www.elsolucionario.net

m1 AñadirAOrden 3 public Contador ( int valorInicio )
U
i
UAjustarNivelStock veces = valorInicio;

-; 1
public void ajustaContadorI int valor )
FIGURA 22.27. U n diagrama de secuencia para el caso de
estudio. i
veces = valor;
También se han mostrado dos operaciones dentro de
la clase Cliente. La primera es la operación obtener- 1
Nombrecliente, que devuelve el nombre del cliente des- public int obtenercuenta( )
crito por la clase.
í
BorrarOrdenílibro) O return veces;

// i
Orden(libr0) public void incrementacuenta( I

Cancelar Seleccionar i
Orden Transporte
vecestt ;
Cancelarorden
FIGURA 22.28. Un diagrama de estados. i
i

La clase denominada Contador tiene un atributo
veces, que registra el número de veces consultado por
usuarios. La siguiente operación tiene el mismo nom-
bre de la clase, y se conoce como constructor. Este es
un fragmento de código ejecutable, que se ejecuta cuan-
do el objeto se crea, recibe un argumento entero que es
el valor inicial del contador. Cuando el usuario de la
clase desea crear un objeto contador, el código es el
siguiente:

Contador cont = new Contador( O );

La palabra clave new llama al constructor para crear
un objeto contador que tiene un solo atributo veces ini-
cializado a cero.

401

whtwtp:w//l.iebrlseroialu-ucnioivnearsritioar.inae.btlogspot.com

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

La operación obtenercuenta regresa el valor actual del Recuérdese que, en la herencia, las operaciones en www.elsolucionario.net
contador, la operación ujustuContudor ajusta el atributo la superclase (en nuestro clase Contador) se heredan por
veces a un valor dado por su argumento, y la operación la superclase (en nuestro caso TiempoContudor), a
incrementuCuentuincrementael atributoveces en uno (la menos que se sobrecarguen.

operación ++ es la operación de incremento en uno). La primera operación ajustacontador, sobrecarga al
método correspondiente en la superclase. Primero ini-
La sintaxis de Java para enviar mensajes al objeto es cializa el atributo veces dentro de la superclase, hacien-
la siguiente: do una llamada a su constructor (la palabra clave súper
se utiliza para ello), y luego se construye un nuevo obje-
0bjeto.nombreOperaciÓn( argumentos ) to Time. Este objeto se define en cualquier otro lugar, y
no se debe mostrar el código. La operación ajustacon-
Por ejemplo para incrementar un objeto Contador tudor también sobrecarga la operación correspondiente
cont el código sería: dentro de Contador. El código dentro de la clase prime-
ro inicializael atributo de la superclase,para que sea igual
cont.incrementaCuenta( ); a valor. Luego envía un mensaje setNow al atributo horu-
Acceso, para ajustar su valor a la hora actual, el código
La clase anterior es muy simple; de cualquier modo, para la operación setNow forma parte de la clase Time y
sirve para ilustrar las características estructurales prin- no se muestra. El método ohtenHoru es simple: todo lo
cipales de cómo se define una clase. Existen otras com- que hace es regresar el valor de horuAcceso. La opera-
plicaciones, como el hecho de que pueden definirse varios ción incrementuCuentu sobrecarga la operación corres-
niveles de visibilidad; de cualquier modo, esto queda pondiente en la clase Contador. Primero incrementa el
fuera del alcance de un libro de ingeniería del software. valor de veces, llamando a la operación incrementacuenta
dentro de la superclase, luego ajústale valor de horuAc-
Existen dos maneras de combinar clases: la primera ceso, enviando un mensaje setNow al objeto. El método
es la herencia y la segundaes la agregación. Los lenguajes obtenCuentu, heredado de la clase Contador, no necesi-
de programación orientada a objetos contienen recursos ta ser sobrecargada, ya que todo lo que hace es regresar
que permiten a ambas ser implementadasfácilmente. el valor del atributo veces, dentro de la superclase.

En Java, la palabra clave extends se utiliza para deri- Esto es, como un lenguaje de programación orienta-
var una clase de una ya existente por medio de la heren- do a objetos implementala herencia. La implementación
cia. Por ejemplo, asúmase que se necesita derivar una de la agregación es más simple: todo lo que involucra
clase nueva, que se parece mucho a la clase Contador, es la inclusión de las partes agregadas como atributos de
pero que además registra la hora a la que la cuenta se clase. Por ejemplo, la clase siguiente Computadora,
incrementó. El esqueleto de la nueva clase, que hereda representa a una computadora; forma parte de un siste-
la clase Contador, se muestra a continuación: ma para planificar la fabricación de computadoras. Una
computadora es agregada desde un monitor, un teclado,
class TiempoContador extends Contador{ una unidad de proceso y así sucesivamente.Esto se mues-
// Algunos atributos nuevos tra en la clase como una serie de atributos.
// Algunas operaciones nuevas.
1 class Computer {

La palabra clave extends especifica el hecho de que private Monitor mon;
la clase TiempoContudor se hereda de la clase Conta-
dor. El código para la clase se muestra a continuación: private KeyBoard kb;

class TiempoContador extends Contador{ private Processor proc;

Time horaAcceso; // demás atributos
//definición de las operaciones asociadas con
public TiempoContador( int valorInicio ) la computadora.

i 1
super ( valorInicio ) ;
horaAcceso = new Time horaAcceso( ) ; Como un ejemplo final de código en Java, se ha
reproducido mucho del código para un cliente, del
l pequeño caso de estudio mostrado en la Sección 22.6.
Un cliente es alguien que comprará libros usando inter-
public void ajustaContadori int valor ) net. El código para muchos de los métodos se encuen-
tra a continuación:
i
super.ajustaContador( int valor ); class Cliente

horaAcceso.setNow( ); i
Ctring nombre, direcciÓn, tipoTarjetaCredito,
1 clave, infoseguridad;
public Time obtenHora( )
HistorialCompras Hc;
i
return horaAcceso; OrdenesActuales ordenesi?;

i Preferencias pref;

public void incrernentacuenta ( )

i
super.incrementacuentaí ) ;
horaAcceso.setNow( );

1
1

402

www.elsolucionario.net CAPiTULO 22 DISENO ORIENTADO A OBJETOS
.

Public ObtenPrefClientei ) t www.elsolucionario.net
return Hc;
i
return pref; 1
public void inicOrdenesA( )
i i
public Ctring obtenerNombre( )
//utiliza el método setClear de Ordenes-
i Actuales para
return nombre; //inicializar las ordenes actuales
ordenesA.setClear( );
i
i
public Ctring obtenDireccion[ 1
public void agregaorden( Orden ord )
i
t
return direccion; //Utiliza el método addCurrentOrders de
OrdenesActuales
i ordenesA.addCurrentOrders( ord );
public Ctring ObtenTipoTajetaCredito( )
1
i public void borraorden( Orden ord )
return tipoTarjetaCredito; t

i //Utiliza el método removeCurrentOrder de
OrdenesActuales
public Ctring obtenclave( ) 0rdenesA.removeCurrentOrderI ord );
i
1 public int numOrdenesActualesI )
return clave; i
//Utiliza el método no de la clase Orde-
i nesActuales
public Ctring obtenInfoCeguridadi ) return OrdenesA.no( );
i
t public OrdenesActuales obtenOrdenesActuales( )
return infoseguridad;
i
1 return OrdenesA;

public void ponNombrej Ctring nom ) i

i i
nombre = nom;
Muchos de los métodos son muy simples: todo lo que
i hacen es o ajustar u obtener los valores de los atributos
public void ponDireccion ( Ctring dir ) que se encuentran en la clase Cliente. Estos atributos son:

i nombre. Nombre del cliente.
direccion = dir; dirección. Dirección del cliente.
tipoTarjetaCrédito. Una cadena que describe el tipo
1 de tarjeta de crédito usada por el cliente.
public void ponTipoTarjetaCredito( Ctring ttc ) clave. La cadena usada por el cliente, para acceder
al sitio de venta de libros.
i infuSeguridad. Esta es una cadena que se utiliza por
tipoTarjetaCredito = ttc; el cliente, para identificarsecon el equipo de servicio
del sitio, en caso de que se olvide su clave. Por ejem-
i plo, puede contenerel lugar de nacimiento del cliente.
public ponclave( Ctring clv ) Hc. Es el historial de los libros que el cliente ha com-
prado.
i ordenesA. Contiene los detalles de cada orden, que
clave = clv; se lleva a cabo en ese momento; por ejemplo, una
orden que no puede ser satisfecha completamente.
1 pref. Contiene una lista de preferencias de compra
para el cliente. Por ejemplo,el hecho de que el cliente
public void ponInfoCeguridad( Ctring isg ) normalmente compra novelas de terror.

t Existe un grupo de métodos, que pueden llamar a
infoCeguridad = isg; métodos definidos en otras clases; por ejemplo, el méto-
do burraorden, que elimina una orden de los detalles
i de cliente, y utiliza el método removeCurrentOrder de
public void ponpreferencias( Ctring prf i la clase OrdenesActuales.
i

pref = prf;

1

public void iniciaiiistlompras( )

i
//inicializa el historial de compras con
el método setClear

Hc.setClear( ); '
1

public void agregaTransCompra(TransCompra tc )

i
//utiliza el método add definido en Histo-
rialcompras para

//agregar un libro a la transacción de
compras al objeto
//eliente
Hc.add( tc );

i
public HistCompras obtenHistComprasj )

4D3

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

El diseño orientado a objetos traduce el modelo de Durante el diseño del sistema, la arquitecturadel sis- www.elsolucionario.net
A 0 0 del mundo real, a un modelo de implementación tema orientado a objetos se desarrolla.Además del desa-
específica, que puede realizarse en software. El pro- rrollo de sistemas,de sus interaccionesy de su colocación
ceso de DO0 puede describirse como una pirámide dentro de las capas arquitectónicas,el diseño de sistemas
compuesta por cuatro capas. La capa fundamental se considera la componente de interacción con el usuario,
centra en el diseño de subsistemas, que implementan una componente de administraciónde tareas y una com-
funciones principales de sistema. La capa de clases ponente de manejo de datos. Estas componentesde sub-
especifica la arquitectura de objetos global, y la jerar- sistemas proporcionan la infraestructura de diseño, que
quía de clases requerida para implementar un sistema. permite a la aplicación operar efectivamente.El proceso
La capa de mensajes indica cómo debe ser realizada de diseño de objetos se centra en la descripción de estruc-
la colaboración entre objetos, y la capa de responsa- turas de datos, que usan los atributos de clase, los algo-
bilidades identifica las operaciones y atributos que ritmos que usan las operaciones y los mensajes que
caracterizan cada clase. permiten colaboracionesentre objetos relacionados.

Al igual que el AOO, existen diferentes métodos de Los patrones de diseño permiten al diseñador crear
DOO. UML es un intento de proporcionar una aproxi- la arquitectura de diseño integrando componentes reu-
mación simple al DOO, que se aplica en los dominios sables. La programación O 0 extiendeel modelo de dise-
de aplicaciones. UML y otros métodos, aproximan el ño a un dominio de ejecución. Un lenguaje de
proceso de diseño mediante dos niveles de abstracción programación O 0 se usa para traducir las clases, atri-
-diseño de subsistemas (arquitectura) y diseño de obje- butos, operaciones y mensajes, de manera que puedan
tos individuales-. ejecutarse por la máquina.

[BEN99] Bennett, S., S. McRobb y R. Farmer, Object [GAM95] Gamma, E., et al., Design Patterns, Addison-
Oriented System Analysis and Design Using UML, Wesley, 1995.
McGraw Hill, 1999.
[GOL831 Goldberg, A,, y D. Robson, Smalltalk-80: The
[BIH92] Bihari, T., y P. Gopinath, «Object-Oriented Real- Languuge and Its Implementation, Addison-Wesley,
Time Systems: Concepts and Examples», Computer, vol. 1983.
25, n." 12, Diciembre 1992, pp. 25-32.
[JAC92] Jacobson, I., Object-Oriented Software Enginee-
[B0094] Booch, G., Object-OrientedAnalysis and Design, ring, Addison-Wesley, 1992.
2.4ed., Benjamin Cummings, 1994.
[JAC99] Jacobson, I., G. Booch y J. Rumbaugh, Unifed
[ B 0 0 9 9 ] Booch, G., 1.Jacobson y J. Rumbaugh, The Uni- Software Development Process, Addison-Wesley, 1999.
fied Modelling Language User Guide, Addison-Wesley,
1999. [MEY90] Meyer, B., Object-Oriented Software Construc-
tion, 2.+ed., Prentice-Hall, 1988.
[BR091] Brown, A.W., Object-Oriented Databases,
McGraw-Hill, 1991. [PRE95] Pree, W., Design Patterns f o r Object-Oriented
Software Development, Addison-Wesley, 1995.
[BUS961 Buschmann, E, et al., A System of Patterns: Pat-
tern Oriented System Architecture, Wiley, 1996. [RUM911 Rumbaugh, J., et al., Object-Oriented Modelling
and Design, Prentice-Hall, 1991.
[COA911 Coad, P., y E. Yourdon, Object-Oriented Design,
Prentice-Hall, 1991. [RUM99] Rumbaugh, J., 1. Jacobson y G. Booch, The Uni-
fied Modelling Language Reference Manual, Addison-
[COXSS] Cox, B., «Software Ics and Objective-C», Unix- Wesley, 1999.
World,primavera de 1985.
[RA094] Rao. B.A., Object-Oriented Databases: Tech-
[DAV95] Davis, A., «Object-Oriented Requirements to nology, Applications and Products, McGraw-Hill,
Object-Oriented Design: An Easy Transition?», J.Sys- 1994.
tems Software, vol. 30, 1995, pp. 151-159.
[TAY92] Taylor, D.A., Object-Oriented Information Sys-
[DOU99] Douglass, B., Real-TimeUML: Developing Effi- tem, Wiley, 1992.
cient Objects for Embedded Systems, Addison-Wesley,
1999. [WIR90] Wirfs-Brock, R., B. Wilkerson y L.Weiner, Des@
ning Object-Oriented Software, Prentice-Hall, 1990.

404

www.elsolucionario.net
.

CAPfTULO 22 DISENO ORIENTADO A OBJETOS

21.1. La pirámide de diseño para el D O 0 difiere, de alguna 21.12. Aplique el enfoque del DO0 examinado anteriormen- www.elsolucionario.net
manera, de la descrita para el diseño del software conven- te en este capítulo, para diseccionar el diseño del sistema
cional (Capítulo 13). Vea las diferencias y semejanzas de Hogarseguro. Defina todos los subsistemasrelevantes, y desa-
ellas dos. rrolle el diseño de objetos para las clases importantes.

21.2. ¿Cómo difieren el D O 0 y el estructurado? ¿Qué aspec- 21.13. Aplique el enfoque del D O 0 examinado en este capí-
tos de estos dos métodos de diseño son los mismos? tulo al sistema SSRB descrito en el problema 12.13.

21.3. Revise los cinco criterios para la modularidad eficaz exa- 21.14. Describa un juego de vídeo y aplique el enfoque del
minados en la Sección 22.1.2. Usando el enfoque de diseño D O 0 examinado en este capítulo, para representar su diseño.
descrito posteriormente en el capítulo, demuestre cómo se
logran estos cinco criterios. 21.15. Usted es responsable del desarrollo de un sistema de
correo electrónico a implementarse sobre una red de PC. El
21.4. Seleccione uno de los métodos de D O 0 presentados en sistema de e-mail permitirá a los usuarios escribir cartas diri-
la Sección 22.1.3, y prepare un tutorial de una hora para su gidas a otro usuario o a una lista de direcciones específica.
clase. Asegúrese de mostrar todas las convenciones gráficas Las cartas pueden ser enviadas, copiadas, almacenadas, etc.
de modelado que sugiere el autor. El sistema de correo electrónico hará uso de las capacidades
de procesamiento de texto existentes para escribir las cartas.
21.5. Seleccione un método de D O 0 no presentado en la Sec- Usando esta descripción como punto de partida, derive un
ción 22.1.3, (por ejemplo, HOOD), y prepare un tutorial de conjunto de requisitos, y aplique las técnicas de DOO, para
una hora para su clase. Asegúrese de mostrar todas las con- crear un diseño de alto nivel, para el sistema de correo elec-
venciones gráficas de modelado que sugiere el autor. trónico.

21.6. Analice cómo los casos de uso pueden servir como una 21.16. Una nación ubicada en una pequeña isla ha decidido
fuente importante de información para el diseño. construir un sistema de control de tráfico aéreo (CTA) para su
único aeropuerto. El sistema se especifica como sigue:
21.7. Investigue un entorno de desarrolloIGU, y muestre cómo
el componente de interacción hombre-máquina se implemen- Todos los aviones que aterrizan en el aeropuerto deben
ta en el mundo real. ¿Qué patrones de diseño se ofrecen y cómo tener un transmisor que transmita el tipo de avión y los
se usan? datos del vuelo en un paquete, con formato de alta densi-
dad, a la estación de CTA de tierra. La estación de CTA de
21.8. La gestión de tareas en sistemas O 0 puede ser muy com- tierra puede interrogar a un avión, para solicitar informa-
pleja. Realice alguna investigación sobre métodos de DOO, ción específica y almacenarla en una base de datos de avio-
para sistemas en tiempo real (por ejemplo, [BIH92] o nes. Se crea un monitor de gráficos por ordenador, a partir
[DOU99]) y determine cómo la gestión de tareas se realiza de la información almacenada, y se la muestra a un con-
dentro de este contexto. trolador de tráfico. El monitor se actualiza cada 10 segun-
dos. Toda la información es analizada, para determinar si
21.9. Examine cómo el componente de manejo de datos se existen «situaciones peligrosas». El controladorde tráfico
implementaen un entorno de desarrollo O 0 típico. aéreo puede interrogar la base de datos, para buscar infor-
mación específica acerca de cualquier avión que se mues-
21.10. Escriba un artículo de dos o tres página sobre bases de tre en pantalla.
datos orientadas a objetos, y analice cómo pueden usarse, para
desarrollarel componente de gestión de datos. Usando el DOO, cree un diseño para el sistema de CTA.
No intente implementarlo.
21.11. ¿Cómo reconoce un diseñador las tareas que deben ser
recurrentes?

Además de las muchas referencias de este capítulo, los libros dos en la sección otras lecturas yfuentes de información del
de Gossain y Graham (Object modelling and Design Strate- Capítulo 21 también se centran en el diseño con un nivel de
gies, SIGS Books, 1998), Meyer (Object-Oriented Design detalle considerable.
Through Heuristics, Addison-Wesley, 1996), y Walden, Jean-
Marc Nerson (Seamless Object-Oriented Software Architec- El uso de patrones de diseño para el desarrollo de soft-
ture:Analisis and Design of Reliable Systems, Prentice-Hall, ware orientado a objetos tiene importantes implicaciones
1995)cubren con bastante detalle el DOO. Fowler (Refacto- para la ingeniería del software basada en componentes, la
ring: irnproving the Design of Existing Code, Addison-Wes- reutilización en general y la calidad global de los sistemas
ley, 1999) dirige el uso de técnicas orientadas a objetos para resultantes. Además de [BUS961 y [GAM95], muchos libros
rediseñar y reconstruir programas antiguos con el fin de mejo- recientes dedican sus páginas al mismo tema, como los
rar su calidad de diseño. siguientes:

Muchos libros de diseño orientado a objetos publicados Ambler, S.W., Process Patterns: Building Large-Scale
recientemente enfatizan UML. El lector seriamente interesa- Systems Using Object Technology, Cambridge University
do en aplicar UML a su trabajo debe adquirir [ B 0 0 9 9 ] , Press, 1999.
[RUM99] y [JAC99]. Además, muchos de los libros referi-
Coplien, J.O., D.C. Schmidt, Pattern Languages of Pro-
gram Design, Addison-Wesley, 1995.

405

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

Fowler, M., Analysis Patterns: Reusable Object Models, Eiffel: Thomas, P., y R. Weedon, Object-Oriented Pro- www.elsolucionario.net
Addison-Wesley, 1996. gramming in Eirel, Addison-Wesley, 1997.

Grand, M., Patterns in Java, vol. 1, John Wiley, 1998. Jezequel, J.M., Ohject-Oriented Software Engineering
Langr, J., Essential Java Style: Patterns for Implementa- With Eiffel, Addison-Wesley, 1996.
tion, Prentice-Hall, 1999.
Larman, C., Applying Un1and Patterns: An Introduction Java: Coad, P., M. Mayfield y J. Kem, Java Design: Buil-
to Object-Oriented Analysis and Design, Prentice-Hall, 1997. ding Better Apps and Applets, 2.i ed., Prentice-Hall, 1998.
Martin, R.C., et al., Pattern Languages of Program Design
3, Addison-Wesley, 1997. Lewis, J., y W. Loftus, Java Software Solutions: Founda-
Rising, L., y J. Coplien (eds.), The Patterns Handbook: tions of Program, Addison-Wesley, 1997.
Techniques,Strategies, andApplications, SIGS Books, 1998.
Pree, W., Design Patterns for Object-Oriented Software Smalltalk: Sharp, A., Smalltalk by Example: The Develo-
Development, Addison-Wesley, 1995. per’s Cuide, McGraw-Hill, 1997.
Preiss, B., Data Structures and Algorithms with Object-
Oriented Design Patterns in Java, John Wiley, 1999. LaLonde, W.R., y J.R. Pugh, Programming in Smalltalk,
Vlissides, J., Pattem Hatching: Design Patterns Applied, Prentice-Hall, 1995.
Addison-Wesley, 1998.
Vlissides, J.M., J.O. Coplien y N. Kerth, Pattern Lag- Los libros que cubren temas de DOO, mediante el uso de
guages of Program Design 2 , Addison-Wesley, 1996. dos o más lenguajes de programación, proporcionan una idea
Cientos de libros de programación orientada a objetos y comparación de las capacidades de los lenguajes. Algunos
(POO) han sido publicados. Una muestra de libros específi- títulos son:
cos en lenguajes de POO:
C++: Cohoon, J.P., C++ Program Design: An Introduc- Drake, C., Ohject-Oriented Programming With C++ and
tion to Programming and Object-Oriented Design,McGraw- Smalltalk, Prentice Hall, 1998.
Hill, 1998.
Barclay, K., y J. Savage, Object-Oriented Design With Joyner, I., Objects Unencapsulated: Java, Eiffel ande++,
C++, Prentice-Hall, 1997. Prentice Hall, 1999.

Zeigler, B.P., Objects and Systems: Principled Design With
Iniplementations in C++ and Java, Springer Verlag, 1997.

Una amplia variedad de fuentes de información sobre dise-
ño orientado a objetos, así como temas relacionados, están
disponibles en internet. Una lista actualizada de referencias
a sitios (páginas) web, que pueden ser relevantes al DOO,
pueden encontrarse en http://www.pressman5.com

406

CAPÍTULO http:w//lwibwre.reial-suonliuvecrisoitnaariari.ob.longestpot.com
.
23
PRUEBAS ORIENTADAS
A OBJETOS

EL objetivo de las pruebas, expresado de forma sencilla, es encontrar el mayor número www.elsolucionario.net
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 O 0 cambian las estrategias y las
tácticas de prueba.

Puede argumentarse que, conforme el A 0 0 y el DO0 maduran, una mayor reutilización de
patrones de diseño mitigarán la necesidad de pruebas intensivas en los sistemas OO. La verdad
es justo lo contrario. Binder [BIN94b] lo analiza, cuando afirma que:

Cada reutilización es un nuevo contexto de uso y es prudente repetir las pruebas. Parece probable que
se necesitarán menos pruebas para obtener una alta fiabilidad en sistemas orientados a objetos.

La prueba de los sistemas O 0 presentan un nuevo conjunto de retos al ingeniero del soft-
ware. La definición de pruebas debe ser ampliada para incluir técnicas que descubran errores
(revisiones técnicas formales), aplicadas para los modelos deA 0 0 y DOO. La integridad, com-
pleción y consistencia de las representaciones O 0 deben ser evaluadas conforme se constru-
yen. Las pruebas de unidad pierden mucho de su significado, y las estrategias de integración
cambian de modo significativo. En resumen, las estrategias y tácticas de prueba deben tomar-
se en cuenta para las características propias del software OO.

¿Qué es? La arquitectura de software la frustración asociada con y pruebas de agrupa-
orientado a objetos se manifiesta en to de baja calidad. Conel prop
una serie de subsistemas organizados encontrar el mayor número amente las clases colabora-
por capas, que encapsuian clases que errores, las pruebas deben conducirse imo, los casos d e uso
colaboran entre sí. Cada uno de estos sistemáticamente. y los casos como parte del modelo
elementos del sistema (subsistemas y ba deben ser designados medi )se usanpara descubrir
clases),realizan funciones que ayudan nicas disciplinadas. ftware a nivel de vali-
a alcanza requerimientos del sistema.
Es necesario probar un sistema OO.en ¿Cuáles son los paros? L a d o obtenido? Se
una variedad de niveles diferentes, en O0 son estratégicamente s tan un conjunto de
un esfuerzopara descubrir errores, que las pruebas de sistemasconvenci
deben ocurrir cuando las clases cola- les. pero tácticamente difer clases, sus colaboraciones y com-
boran con otras entre sí, y los subsis- que los modelos de análisis os;sedefinen los resultados
temas se comunican por medio de las O0 son similares en estruct y se registran los resulta-
capas arquitectónicas. tenido al programa 00,las
comienzan con la revisión o estar seguro de que lo
gQlii6n lo hace? L a s pruebas orienta- modelos. Una vez que se ha crorreckmrente?Cuando
das a objetos se realizan por ingenie- el código, las pruebas O0 c las pruebas, se cambia su
ros de software y especialistas en *en lo pequeño. con las pruebas de
pruebas. clases. Existen pruebas disefíadas ista. ¡intenta crompern el
para probar las operaciones de lascla-
¿Por que es importante? Se debe eje- ses y examinar s i los error de una forma disciplinada y revisar los
cutar el programa antes de que llegue cuando una clase colabora con otras. casosde prueba que secrean con meti-
al cliente, con la intención específica Así como las clases se integran para culosidad.
de descubrir todos los errores, de formar un subsistema basado en hilos,
manera que el cliente no emerimente

407

www.elsolucionario.net

.

INGENlERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

La construcción del software orientado a objetos 3. El comportamiento del sistema o sus clases pueden www.elsolucionario.net
comienza con la creación de los modelos de análisis caracterizarse inadecuadamente, para alojar el atri-
y diseño (Capítulos 21 y 22). Debido a la naturaleza buto irrelevante.
evolutiva del paradigma de ingeniería de software 00,
estos modelos comienzan como representaciones, rela- Si el error no se descubre durante el análisis y se pro-
tivamente informales, de los requisitos del sistema, y paga más allá, los siguientes problemas pueden ocurrir
evolucionan en modelos detallados de clases, cone- (y tendrán que evitarse con una nueva revisión) duran-
xiones y relaciones de clases, el diseño del sistema y te el diseño:
el diseño de objetos (incorporando un modelo de
conectividad de objetos por medio de mensajes). En 1. La localización impropia de la clase a un subsistema
cada etapa, los modelos pueden probarse, en un inten- y/o tareas puede ocurrir durante el diseño del sis-
to de descubrir errores, antes de su propagación a la tema.
siguiente iteración.
2. El trabajo del diseño innecesario tendrá que ser recu-
, perado, para crear el diseño procedimental, para las
operaciones que afecten al atributo innecesario.
Puede argumentarse que la revisión de los mode-
los de análisis y diseño O 0 son especialmente útiles, 3. El modelo de mensajes (mensajería) será incorrecto
ya que las mismas estructuras semánticas (por ejem- (debido a que deben diseñarsemensajes para las ope-
plo, clases, atributos, operaciones, mensajes), apare- raciones innecesarias).
cen en los niveles de análisis, diseño y codificación.
Por consiguiente, un problema en la definición de los Si el error permanece sin detectarse durante el diseño
atributos de las clases que se descubren durante el y pasa a la actividad de codificación, se gastará un
análisis evitará efectos laterales que pueden ocurrir esfuerzo considerable para generar el código que imple-
si el problema no se descubriera hasta el diseño o menta un atributo innecesario, dos operaciones innece-
implementación (o incluso la siguiente iteración del sarias, mensajes que controlan comunicaciones entre
análisis). objetos, y muchos otros aspectos relacionados.Además,
la prueba de la clase absorberá más tiempo del necesa-
Por ejemplo,considérese una clase en la que el núme- rio. Una vez que se encuentra el problema en su totali-
ro de atributos se definen durante la primera iteración dad, debe llevarse a cabo la modificación del sistema,
del AOO. Un atributo externo (extraño), se agrega a la teniendo siempre presentes los posibles efectos colate-
clase (debido al malentendido del dominio de proble- rales producidos por el cambio.
ma). Se especifican dos operaciones para manipular el
atributo. Se realiza una revisión y un experto en el domi- Existe un viejo dicho que dice ((cortar por lo sono)).
nio señala el error. Eliminando el atributo irrelevante Si pierde tiempo revisando los modelos de A00
en esta etapa, los problemas y esfuerzos innecesarios se y 000, después lo gonorá.
evitan durante el análisis:
Durante las etapas finales de su desarrollo, los mode-
1. Pueden haberse generado subclases especiales para los de A 0 0 y de D O 0 proporcionan información subs-
adoptar (alojar) el atributo innecesario o excepcio- tancial acerca de la estructura y comportamiento del
nes a él. El trabajo involucrado en la creación de sub- sistema. Por esta razón, estos modelos deben estar some-
clases no necesarias se ha evitado. tidos a una revisión rigurosa, antes de la generación de
código.
2. Una mala interpretación de la definición de la clase
puede conducir a relaciones de clases incorrectas o Todos los modelos orientados a objetos deben ser
irrelevantes. probados (en este contexto, el término «prueba» se uti-
liza para incorporar revisiones técnicas formales), para
asegurar la exactitud, compleción y consistencia
[MGR94], dentro del contexto de la sintaxis, semánti-
ca y pragmática del modelo [LIN94].

408

www.elsolucionario.net CAPfTULO 23 PRUEBAS ORIENTADAS A OBIETOS
.

Los modelos de análisis y diseño no pueden probarse en gráfica de las conexiones entre clases. Toda esta infor-
el sentido convencional,ya que no pueden ejecutarse. Sin mación se puede obtener del modelo de A 0 0 (Capítu-
embargo, se pueden utilizar las revisiones técnicas for- lo 21).
males (Capítulo 8) para examinar la exactitud y consis-
tencia de ambos modelos de análisis y diseño.

23.2.1. Exactitud de los modelos de A 0 0 y DO0 Modelos de A00 www.elsolucionario.net

La notación y sintaxis que se utiliza para representar los Para evaluar el modelo de clases, se recomiendan los
modelos de análisis y diseño se corresponderá con el siguientes pasos [MGR94]:
método específico de análisis y diseño, elegido para el 1. Revisar el modelo CRC y el modelo objeto-relación.
proyecto. Por consiguiente, la exactitud sintáctica se
juzga en el uso apropiado de la simbología; cada mode- -Realizar un control cruzado, para asegurarse de que
lo se revisa para asegurarse de que se han mantenido todas las colaboraciones implicadas en el modelo de
las convenciones propias del modelado. A 0 0 hayan sido representadas adecuadamente.

Durante el análisis y diseño, la exactitud semántica ¿Qué pasos deben seguirse
debejuzgarse basada en la conformidad del modelo con para revisar el modelo
el dominio del problema en el mundo real. Si el mode- de clases?
lo refleja con exactitud el mundo real (al nivel de deta-
lle apropiado a la etapa de desarrollo en la que se revisa 2. Inspeccionar la descripción de cada tarjeta CRC,
el modelo), entonces es semánticamente correcto. Para para determinar si alguna responsabilidad delegada
determinar si el modelo en realidad refleja el mundo real, es parte de la definición del colaborador. Por ejem-
debe presentarse a expertos en el dominio del problema, plo, considérese una clase definida para un sistema
quienes examinarán las definiciones de las clases y sus de control de punto de venta, llamada venta a cré-
jerarquías, para detectar omisiones o ambigüedades.Las dito. Esta clase tiene una tarjeta CRC, que se ilustra
relaciones entre clases (conexiones de instancia) se eva- en la Figura 23.1.
lúan para determinar si reflejan con exactitud conexio- Para esta colección de clases y colaboraciones, se
nes del mundo real'. pregunta si alguna responsabilidad (por ejemplo, leer
la tarjeta de crédito) se cumple si se delega al cola-
23.2.2. Consistencia de los modelos de A 0 0 borador nombrado (Tarjeta de crédito). Esto signi-
fica que la clase Tarjeta de crédito posee una
y DO0 operación para ser leída. En este caso, la respuesta
es «Sí». El objeto-relación se recorre,. para asegu-
La consistencia de los modelos de A 0 0 y DO0 debe rarse de que todas las conexiones son válidas.
juzgarse «considerando las relaciones entre entidades
dentro del modelo. Un modelo inconsistentetiene repre- Sugerenciasadicionalespara conducir una revisión
sentaciones en una parte, que no se reflejan correcta- del modelo CRC se presentan en el Capíhrlo 21.
mente en otras partes del modelo» [MGR94].
3. Invertir la conexión para asegurarse de que cada cola-
Para evaluar la consistencia, se debe examinar cada borador que solicita un servicio recibe las peticiones
clase y sus conexiones a otras clases. Un modelo clase- de una fuente razonable. Por ejemplo, si la clase Tar-
responsabilidad-colaboración (CRC), y un diagrama jeta de crédito recibe una petición de cantidad de
objeto-relación pueden utilizarse para facilitar esta acti- compra de la clase Venta a crédito, existirá un pro-
vidad. Como se comentó en el Capítulo 21, el modelo blema. Tarjeta de crédito no reconoce la cantidad de
CRC se compone de una tarjeta índice CRC. Cada tar- compra.
jeta CRC muestra el nombre de la clase, sus responsa-
bilidades (operaciones) y sus colaboradores (otras clases
a las que se envían mensajes y de las cuales depende
para el cumplimiento de sus responsabilidades). Las
colaboraciones implican una serie de relaciones (por
ejemplo, conexiones), entre clases del sistema OO. El
modelo objeto-relaciónproporciona una representación

I Los casos de uso poseen un valor incalculable, en el seguimiento
de los modelos de análisis y diseño, frente a los escenarios del mundo
real para el sistema OO.

409

www.elsolucionario.net

INGENlERíA DEL SOFTWARE. U N ENFOQUE PRACTICO .

1 Nombre de la clase: venta a crédito Una vez que se crea el modelo de DO0 (Capítulo 22),
deben llevarse a cabo también las revisiones del diseño
1 Leer tarieta de crédito permanente, protegida del sistema y del diseño de objetos. El diseño del siste-
ma describe el producto arquitectónico global, los sub-
Obtener autorización Tarjeta de crédito sistemas que componen el producto, la manera en que
Autorización de crédito los subsistemas se asignan a los procesadores, la asig-
IEnviar por correo nación de clases a subsistemas y el diseño de la interfaz
cantidad de compra II I de usuario. El diseño de objetos presenta los detalles de

I I Etiqueta de producto I cada clase, y las actividades de mensajería necesarias
para implementar las colaboraciones entre clases.
11 Vendedor

FIGURA 23.1. Un ejemplo de tarjeta índice CRC usada para Modelos de DO0 www.elsolucionario.net
revisión.
El diseño de sistema se revisa examinando el mode-
4. Utilizando las conexiones invertidas, ya examina- lo objeto-comportamientodesarrollado durante el AOO,
das en el paso 3,determinar si otras clases se requie- y la correspondencia necesaria del comportamiento del
ren y si las responsabilidades se han repartido sistema, frente a los subsistemas diseñados para lograr
adecuadamente entre las clases. este comportamiento.

5. Determine si las responsabilidades muy solicita- La concurrencia y asignación de tareas también se
das, deben combinarse en una sola responsabili- revisan dentro del contexto del comportamiento del sis-
dad. Por ejemplo, leer tarjeta de crédito y obtener tema. Los estados de comportamiento del sistema se eva-
autorización ocurren en cada situación. Por consi- lúan para determinar cuáles existen concurrentemente.
guiente, se pueden combinar en la responsabilidad Los escenarios o situaciones de los casos de uso se uti-
validar petición de crédito, que incorpora obtener lizan para validar el diseño de la interfaz de usuario.
el número de tarjeta de crédito, y conseguir la auto-
rización. El modelado de objetos debe probarse frente a la red
objeto-relación, para asegurarse de que todos los obje-
6. Se aplican iterativamente lospasos 1 a 5 para cada tos de diseño contienen los atributos y operaciones nece-
clase, y durante cada evolución del modelo de sarias y para implementar las colaboraciones que se
AOO. definieron para cada tarjeta CRC. Además, la especifi-
cación detallada de las operaciones (por ejemplo, los
algoritmos que implementan a las operaciones), se revi-
san usando técnicas de inspección convencionales.

2 1 ..

La estrategiaclásica para la prueba de software de orde- último, el sistema se comprueba como un todo para ase-
nador, comienza con «probar lo pequeño» y funciona gurarse de que se descubren los errores en requisitos.
hacia fuera haciendo «probar lo grande». Siguiendo la
jerga de la prueba de software (Capítulo 1S), se comien- 23.3.1. Las pruebas de unidad en el contexto
za con las pruebas de unidad, después se progresa hacia
las pruebas de integración y se culmina con las pruebas de la O0
de validación del sistema. En aplicaciones convencio-
nales, las pruebas de unidad se centran en las unidades Cuando se considera el software orientado a objetos,el
de programa compilables más pequeñas -1 subpro- concepto de unidad cambia. La encapsulación conduce
grama (por ejemplo, módulo, subrutina,procedimiento, a la definición de clases y objetos. Esto significa que
componente)-. Una vez que cada una de estas unida- cada clase y cada instancia de una clase (objeto), envuel-
des han sido probadas individualmente, se integran en
una estructura de programa, mientras que se ejecutan
una serie de pruebas de regresión para descubrir errores,
debidos a las interfaces entre los módulos y los efectos
colaterales producidos por añadir nuevas unidades. Por

410

www.elsolucionario.net CAP1TULO 23 P R U E B A S O R I E N T A D A S A O B J E T O S
.

ven atributos (datos) y operaciones (también conoci- ro, las pruebas basadas en hilos, integran el conjunto www.elsolucionario.net
dos como métodos o servicios), que manipulan estos de clases requeridas, para responder una entrada o suce-
datos. En vez de probar un módulo individual, la uni- so al sistema. Cada hilo se integra y prueba individual-
dad más pequeña comprobable es la clase u objeto mente. Las pruebas de regresión se aplican para asegurar
encapsulado.Ya que una clase puede contener un núme- que no ocurran efectos laterales. La segunda aproxi-
ro de operaciones diferentes, y una operación particu- mación de integración, la prueba basada en el uso,
lar debe existir como parte de un número de clases comienza la construcción del sistema probando aque-
diferentes, el significado de la unidad de prueba cam- llas clases (llamadas clases independientes), que utili-
bia drásticamente. zan muy pocas (o ninguna) clases servidoras. Después
de que las clases independientes se prueban, esta secuen-
No se puede probar más de una operación a la vez cia de pruebas por capas de clases dependientes conti-
(la visión convencional de la unidad de prueba), pero sí núa hasta que se construye el sistema completo. A
como parte de una clase. Para ilustrar esto, considére- diferencia de la integración convencional, el uso de dri-
se una jerarquía.de clases, en la cual la operación X se vers y stubs como operaciones de reemplazo, debe evi-
define para la superclase y se hereda por algunas sub- tarse siempre que sea posible.
clases. Cada subclase utiliza la operación X, pero se
aplica en el contexto de los atributos y operaciones pri- c VE
vadas que han sido definidas para la subclase. Ya que el
contexto en el que la operación X se utiliza varía de l a estrategia de integraciónde pruebas O0 se centra
manera sutil, es necesario para probar la operación X
en el contexto de estas subclases.Esto significa que pro- en grupos de clases que colaboran o se comunican
bar la operación X en vacío (la aproximaciónde la prue-
ba de unidades tradicionales) es inefectiva en el contexto de la misma manera.
orientado a objetos.
La prueba de agrupamiento [MGR94] es una fase
8% en las pruebas de integración de software OO. Aquí, un
agrupamiento de clases colaboradoras (determinadas
CLAVE por la revisión de los modelos CRC y objeto-relación),
se prueba diseñando los casos de prueba, que intentan
l a prueba de software O0 es equivalente a1 módulo revelar errores en las colaboraciones.
de pruebas unitariaspara el software convencional.
No es recomendablecomprobar operacionespor separado. 23.3.3. Pruebas de validación en un contexto O 0

La prueba de clases para el software O 0 es el equiva- Al nivel de sistema o de validación, los detalles de
lente de las pruebas de unidad para el software conven- conexiones de clases desaparecen. Así como la vali-
cional*.A diferencia de las pruebas de unidad del software dación convencional, la validación del software O 0
convencional que tienden a centrarse en el detalle algo- se centra en las acciones visibles al usuario y salidas
ntmico de un módulo y de los datos que fluyen a través reconocibles desde el sistema. Para ayudar en la cons-
de la interfaz del módulo, la prueba de clases para el soft- trucción de las pruebas de validación, el probador debe
ware O 0 se conduce mediante las operaciones encapsu- utilizar los casos de uso (Capítulo 20), que son parte
ladas por la clase y el comportamiento de la clase. del modelo de análisis. Los casos de uso proporcionan
un escenario, que tiene una gran similitud de errores
23.3.2. Las pruebas de integración con los revelados en los requisitos de interacción del
en el contexto O 0 usuario.

Ya que el software orientado a objetos no tiene una Aparentemente, todoslos métodas de pruebas
estructura de control jerárquico, las estrategias con- de coja negm r i i ~ ~ eon sel Capftula 17
vencionales de integración descendente (top-down) y son aplicablesa la OO.
ascendente (bottom-up) tienen muy poco significado.
En suma, la integración de operaciones una por una en Los métodos de prueba convencionales de caja negra
una clase (la aproximación de la integración incremen- pueden usarse para realizar pruebas de validación. Ade-
tal convencional), a menudo es imposible por la «inte- más, los casos de prueba deben derivarse del modelo de
racción directa e indirecta de los componentes que comportamiento del objeto y del diagrama de flujo de
conforman la clase» [BER93]. sucesos, creado como parte del AOO.

Existen dos estrategias diferentes para las pruebas
de integración de los sistemas O 0 [BIN94a]. El prime-

Los métodos de diseño para pruebas de caso, para las clases 00,
se discuten de las Secciones 23.4 a 23.6.

411