[NGENIERIA DEL SOFTWARE. UN ENFOQUE PRACTICO
tener la cohesién entre médulos), seria necesario desa-
rrollar médulos de dibujo para cada tipo de grfico. Segtin
esto, dentro del disefio para cada tipo de gréfico, se debe-
14 afiadir una I6gica de control semejante a la siguiente:
case of tipe_grafico:
if tipe_grafico = grafico_linéa then
Dibujartinea (datos) +
if tipe_grafico = grafico
DibujarTarta (datos:
if tipo_gratico = gratico_histograna
then Dibujariisto(datos):
if tipo_grafico = grafico_kiviat ‘then
Dibujarkiviat (datos) +
end case:
eta then
Aunque este disefio es razonablemente evidente, afa-
dir nuevos tipos de graficos puede ser complicado, pues
hay que crear un nuevo médulo de dibujo para cada tipo
de grifico y actualizar la I6gica de control para cada
sritico.
ara resolver este problema, cada uno de los grifi-
‘cos mencionados anteriormente se convierte en una sub-
clase de una clase general llamada Grafico. Usando un
concepto llamado sobrecarga {TAY90), cada subclase
define una operaci6n llamada dibujar. Un objeto pue-
de enviar un mensaje dibujar a cualquiera de ‘os obje-
tos instanciados de cualquiera de las subclases. El objeto
ue recibe el mensaje invocard su propia operac:én dibu-
Jar para crear el grifico apropiado. Por esto, el diseiio
‘mostrado anteriormente se reduce a:
tipo_grafico dibujar
‘Cuando hay que afiadir un nuevo tipo de grifico al
sistema, se crea una subclase con su propia operacién
Los elementos de un modelo de objetos —clases y obje-
tos, atributos, operaciones y mensajes— fueron definidos
yy examinados en la seccién precedente. Pero, ,o6mo pode-
‘mos hacer para identificar estos elementos en un proble-
‘ma real? Las secciones que siguen presentan una serie de
directrices informales que nos ayudardn en la identifica-
Cin de los elementos de un modelo de objetos.
20.8.1. Identificacién de clases y objetos
Si usted observa a su alrededor en una habitacién, exis-
ten un conjunto de objetos fisicos que pueden ser fécil-
‘mente identificados, clasificados y definidos (en términos
de atributos y operaciones). Pero cuando usted «observa»
elespacio dé un problema en una aplicacién de software,
los objetos pueden ser més dificles de identifica
dibujar. Pero no se requieren cambios dentro de un obje=
to que quiere dibujar un grafico pues el mensaje
tipo_grafico dibujar no cambia. En resumen, el poli=
‘morfismo permite que un niimero de operaciones dife=
rentes tengan el mismo nombre. Esto reduce ef
acoplamiento entre objetos, haciendo a cada uno ms
independiente,
as
Elfe|_|
i if
F
:
fetes
k HE
ey
5
UE
jae)
les)
(sed
FIGURA 20.8b. Jorarquia de clases reestructurada.
Podemos empezar a identificar objetos‘ examinando
el planteamiento del problema 0 (usando la terminolo-
‘gia del Capitulo 12) realizando un «andlisis sintsctico
‘gramatical» en la narrativa del sistema que se va a cons-
‘tuir, Los objetos se determinan subrayando cada nom-
bre o cléusula nominal e introduciéndola en una tabla
simple. Los sinénimos deben destacarse. Si se requie-
re del objeto que implemente una solucién, entonces
‘TE realidad, el Analisis 00 intentaidenticar las clases a partir de
las cuales se instancian los objetes Por tanto, cuando aislamos obje-
tos potencials, también ientiicamos miembros de clases poten-
lakes,6 te formaré parte del espacio de solucién; en caso de
que el objeto se necesite solamente para describir una
solucién, éste forma parte del espacio del problema.
Pero, {qué debemos buscar una vez que se han aislado
todos los nombres?
Como identfcr objets
‘wando estudio como
solver un problema?
Los objetos se manifiestan de alguna de las formas
mostradas en la Figura 20.9. y pueden ser:
+ entidades externas (por ejemplo: otros sistemas,
positivos, personas) que producen o constumen infor-
‘macién a usar por un sistemas computacional;
+ cosas (por ejemplo: informes, presentaciones, car-
tas, sefiales) que son parte del dominio de informa-
ci6n del problema;
+ ocurrencias 0 sucesos* (por ejemplo: una transfe~
rencia de propiedad o la terminacién de una serie de
movimientos en un robot) que ocurren dentro del
contexto de una operacién del sistema;
+ papeles o roles (por ejemplo: director, ingeniero, ven-
dedor) desempefiados por personas que interactdan
con el sistem
+ unidades organizacionales (por ejemplo: divisién,
grupo, equipo) que son relevantes en una aplicacin:
+ lugares (por ejemplo: planta de produccién o mue-
lle de carga) que establecen el contexto del problema
y la funcién general del sistema;
+ estructuras (por ejemplo: sensores, vehiculos de cua-
tro ruedas o computadoras) que definen una clase de
objetos o, en casos extremos, clases relacionadas de
objetos
Tin extecontexto, el término suceso denota cualquier ocurenci,
Nonecesariamente implica control, en el sentido del Capitulo 12
cartroto a cONCEFTOS Y PRINCI
La clasificacién mostrada anteriormente es una de
Jas muchas que se han propuesto en la literatura.
También es importante destacar qué no son los obje-
tos. En general, un objeto nunca debe tener un «nom-
bre procedimental imperativo» [CAS89]. Por ejemplo,
si los desarrolladores de un software para un sistema
‘grdfico médico definieron un objeto con el nombre
inversion de imagen, estarian cometiendo un sutil eror.
La imagen obtenida por el software pudiera ser, en efec-
to, un objeto (es un elemento que forma parte del domi-
nio de informacién), pero la inversién de la imagen es
tuna operacién que se aplica a dicho objeto. Inversion
debe definirse como una operacién del objeto imagen,
Pero no como objeto separado que signifique