CAPÍTULO

20      CONCEPTOS  Y  PRINCIPIOS  ORIENTADOS  A  

OBJETOS  
20.1  El  paradigma  orientado  a  objetos  

Durante  muchos  años  el  término  orientado  a  objetos  (00)  se  usó  para  referirse  a  un  
enfoque  de  desarrollo  de  software  que  usaba  uno  de  los  lenguajes  orientados  a  
objetos  (Ada  95,  C++,  Eiffel,  Smalltalk,  etc.).  Hoy  en  día  el  paradigma  O0  encierra  una  
completa  visión  de  la  ingeniería  del  software.  Edward  Berard  hace  notar  esto  cuando  
declara:  
Los  beneficios  de  la  tecnología  orientada  a  objetos  se  fortalecen  si  se  usa  antes  y  
durante  el  proceso  de  ingeniería  del  software.  Esta  tecnología  orientada  a  objetos  
considerada  debe  hacer  sentir  su  impacto  en  todo  el  proceso  de  ingeniería  del  
software.  Un  simple  uso  de  programación  orientada  a  objetos  (POO)  no  brindará  los  
mejores  resultados.  Los  ingenieros  del  software  y  sus  directores  deben  considerar  
tales  elementos  el  análisis  de  requisitos  orientado  a  objetos  (AROO),  el  diseño  
orientado  a  objetos  (DOO),  el  análisis  del  dominio  orientado  a  objetos  (ADOO),  
sistemas  de  gestión  de  bases  de  dalos  orientadas  a  objetos  (SGBDOO)  y  la  ingeniería  
del  software  orientada  a  objetos  asistida  por  computadora  (ISOOAC).  
 
Con  los  objetos  es  realmente  más  fácil  construir  modelo  para  sistemas  complejos  que  
dedicarse  o  la  programación  secuencial.  
 
20.2  Conceptos  de  orientación  a  objetos  

La  programación  orientada  a  objetos  no  es  tanto  una  técnica  de  codificación  de  
paquetes  como  una  manera  de  que  los  constructores  de  software  encapsulen  
funcionalidades  para  proporcionárselas  a  sus  clientes.  

El  encapsulamiento  significa  que  toda  esta  información  se  encuentra  empaquetada  

bajo  un  nombre  y  puede  reutilizarse  como  una  especificación  o  componente  de  
programa.  
 
20.2.1.  Clases  y  objetos  
 
Los  conceptos  fundamentales  que  llevan  a  un  diseño  de  alta  calidad  son  igualmente  
aplicables  a  sistemas  desarrollados  usando  métodos  convencionales  y  orientados  a  
objetos.  Por  esta  razón,  un  modelo  O0  de  software  de  computadora  debe  exhibir  
abstracciones  de  datos  y  procedimientos  que  conducen  a  una  modularidad  eficaz.  Una  
clase  es  un  concepto  O0  que  encapsula  las  abstracciones  de  datos  y  procedimientos  
que  se  requieren  para  describir  el  contenido  y  comportamiento  de  alguna  entidad  del  
mundo  real.  
 
20.3  Identificación  de  los  Elementos  de  un  Modelo  de  Objetos  
 
Los  objetos  se  manifiestan  de  alguna  de  las  formas:  
 
1. Entidades  externas  (por  ejemplo:  otros  sistemas,  dispositivos,  personas)  que  
producen  o  consumen  información  a  usar  por  un  sistemas  computacional.  
2. Cosas  (por  ejemplo:  informes,  presentaciones,  cartas,  señales)  que  son  parte  
del  dominio  de  información  del  problema.  
3. Ocurrencias  o  sucesos5  (por  ejemplo:  una  transferencia  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.  
4. Papeles  o  roles  (por  ejemplo:  director,  ingeniero,  vendedor)  desempeñados  
por  personas  que  interactúan  con  el  sistema.  
5. Unidades  organizacionales  (por  ejemplo:  división,  grupo,  equipo)  que  son  
relevantes  en  una  aplicación.  
6. Lugares  (por  ejemplo:  planta  de  producción  o  muelle  de  carga)  que  establecen  
el  contexto  del  problema  y  la  función  general  del  sistema.  
7. Estructuras  (por  ejemplo:  sensores,  vehículos  de  cuatro  ruedas  o  
computadoras)  que  definen  una  clase  de  objetos  o,  en  casos  extremos,  clases  
relacionadas  de  objetos.  
 
Coad  y  Yourdon  sugieren  seis  características  de  selección  a  usar  cada  vez  que  un  
analista  considera  si  incluye  o  no  un  objeto  potencial  en  el  modelo  de  análisis:  
 
1. Información  retenida:  el  objeto  potencial  será  de  utilidad  durante  el  análisis  
solamente  si  la  información  acerca  de  él  debe  recordarse  para  que  el  sistema  
funcione.  
2. Servicios  necesarios:  el  objeto  potencial  debe  poseer  un  conjunto  de  
operaciones  identificables  que  pueden  cambiar  de  alguna  manera  el  valor  de  
sus  atributos.  
3. Atributos  múltiples:  durante  el  análisis  de  requisitos,  se  debe  centrar  la  
atención  en  la  información  principal  (un  objeto  con  un  solo  atributo  puede,  en  
efecto,  ser  Útil  durante  el  diseño,  pero  seguramente  será  mejor  presentado  
como  un  atributo  de  otro  objeto  durante  la  actividad  de  análisis);  
4. Atributos  comunes:  puede  definirse  un  conjunto  de  atributos  para  el  objeto  
potencial,  los  cuales  son  aplicables  a  todas  las  ocurrencias  del  objeto.  
5. Operaciones  comunes:  puede  definirse  un  conjunto  de  operaciones  para  el  
objeto  potencial,  las  cuales  son  aplicables  a  todas  las  ocurrencias  del  objeto;  
6. Requisitos  esenciales:  entidades  externas  que  aparecen  en  el  espacio  del  
problema  y  producen  o  consumen  información  esencial  para  la  producción  de  
cualquier  solución  para  el  sistema,  serán  casi  siempre  definidas  como  objetos  
en  el  modelo  de  requisitos.  
 
20.4  Gestión  de  proyectos  de  software  orientado  a  objetos  
 
Ed  Berard  y  Grady  Booch,  entre  otros,  sugieren  el  uso  de  un  «modelo  
recursivo/paralelo>>  p  ara  el  desarrollo  de  software  orientado  a  objetos.  En  esencia,  
el  modelo  recursivo/paralelo  funciona  de  la  siguiente  manera:  
 
• Realizar  los  análisis  suficientes  para  aislar  las  clases  del  problema  y  las  
conexiones  más  importantes.  
• Realizar  un  pequeño  diseño  para  determinar  si  las  clases  y  conexiones  pueden  
ser  implementadas  de  manera  práctica.  
• Extraer  objetos  reutilizables  de  una  biblioteca  para  construir  un  prototipo  
previo.  
• Conducir  algunas  pruebas  para  descubrir  errores  en  el  prototipo.  
• Obtener  realimentación  del  cliente  sobre  el  prototipo.  
• Modificar  el  modelo  de  análisis  basándose  en  lo  que  se  ha  aprendido  del  
prototipo,  de  la  realización  del  diseño  y  de  la  realimentación  obtenida  del  
cliente.  
• Refinar  el  diseño  para  acomodar  sus  cambios.  
• Construir  objetos  especiales  (no  disponibles  en  la  biblioteca).  
 
 
 
 
 CAPÍTULO  

21  
                   ANÁLISIS  ORIENTADO  A  OBJETOS  

El  propósito  del  A00  es  definir  todas  las  clases  que  son  relevantes  al  problema  que  se  
va  a  resolver,  las  operaciones  y  atributos  asociados,  las  relaciones  y  comportamientos  
asociadas  con  ellas.  Para  cumplirlo  se  deben  ejecutar  las  siguientes  tareas:  
 
1. Los  requisitos  básicos  del  usuario  deben  comunicarse  entre  el  cliente  y  el  
ingeniero  del  
2. Identificar  las  clases  (es  decir,  definir  atributos  y  métodos).  
3. Se  debe  especificar  una  jerarquía  de  clases.  
4. Representan  las  relaciones  objeto  a  objeto  (conexiones  de  objetos).  
5. Modelar  el  comportamiento  del  objeto.  
6. Repetir  iterativamente  las  tareas  de  la  1  a  la  5  hasta  completar  el  modelo.  
 
21.1.2.  El  panorama  del  A00  
 
El  método  de  Booch.  El  método  de  Booch  abarca  un  «microproceso  de  desarrollo»  y  
un  «macroproceso  de  desarrollo».  El  nivel  micro  define  un  conjunto  de  tareas  de  
análisis  que  se  reaplican  en  cada  etapa  en  el  macro  proceso.  Por  esto  se  mantienen  un  
enfoque  evolutivo.  
El  micro  proceso  de  desarrollo  identifica  clases  y  objetos  y  la  semántica  de  dichas  
clases  y  objetos,  define  las  relaciones  entre  clases  y  objetos  y  realiza  una  serie  de  
refinamientos  para  elaborar  el  modelo  del  análisis.  
 
El  método  de  Rumbaugh.  Rumbaugh  y  sus  colegas  desarrollaron  la  Técnica  de  
Modelado  de  Objetos  (OMT)  para  el  análisis,  diseño  del  sistema  y  diseño  a  nivel  de  
objetos.  La  actividad  de  análisis  crea  tres  modelos:  el  modelo  de  objetos  (una  
representación  de  objetos,  clases,  jerarquías  y  relaciones),  el  modelo  dinámico  (una  
representación  del  comportamiento  del  sistema  y  los  objetos)  y  el  modelo  funcional  
(una  representación  a  alto  nivel  del  flujo  de  información  a  través  del  sistema  similar  al  
DFD).  
 
El  método  de  Jacobson.  También  llamado  OOSE  (en  español  Ingeniería  del  Software  
Orientada  a  Objetos),  el  método  de  Jacobson  es  una  versión  simplificada  de  Objectory,  
un  método  patentado,  también  desarrollado  por  Jacobson.  Este  método  se  diferencia  
de  los  otros  por  la  importancia  que  da  al  caso  de  uso  –  una  descripción  o  escenario  
que  describe  cómo  el  usuario  interactúa  con  el  producto  o  sistema.  
 
El  método  de  Coad  y  Yourdon.  El  método  de  Coad  y  Yourdon  [COA911  se  considera,  
con  frecuencia,  como  uno  de  los  métodos  del  A00  más  sencillos  de  aprender.  
La  notación  del  modelado  es  relativamente  simple  y  las  reglas  para  desarrollar  el  
modelo  de  análisis  son  evidentes.  A  continuación  sigue  una  descripción  resumida  del  
proceso  de  A00  de  Coad  y  Yourdon:  
 
• Identificar  objetos,  usando  el  criterio  de  «qué  buscar».  
• Definir  una  estructura  de  generalización-­‐especificación.  
• Definir  una  estructura  de  todo-­‐parte.  
• Identificar  temas  (representaciones  de  componentes  de  subsistemas).  
• Definir  atributos.  
• Definir  servicios.  
 
El  método  de  Wirfs-­‐Brock.  El  método  de  Wirfs-­‐  Brock  no  hace  una  distinción  clara  
entre  las  tareas  de  análisis  y  diseño.  En  su  lugar,  propone  un  proceso  continuo  que  
comienza  con  la  valoración  de  una  especificación  del  cliente  y  termina  con  el  diseño.  A  
continuación  se  esbozan  brevemente  las  tareas  relacionadas  con  el  análisis  de  Wirfs-­‐
Brock:  
 
• Evaluar  la  especificación  del  cliente.  
• Usar  un  análisis  gramatical  para  extraer  clases  candidatas  de  la  especificación.  
• Agrupar  las  clases  en  un  intento  de  determinar  superclases.  
• Definir  responsabilidades  para  cada  clase.  
• Asignar  responsabilidades  a  cada  clase.  
• Identificar  relaciones  entre  clases.  
• Definir  colaboraciones  entre  clases  basándose  en  sus  responsabilidades.  
• Construir  representaciones  jerárquicas  de  clases  para  mostrar  relaciones  de  
herencia.  
• Construir  un  gafo  de  colaboraciones  para  el  sistema.  
 
21.2  Análisis  del  dominio  
 
El  objetivo  del  análisis  del  dominio  es  definir  el  conjunto  de  clases  (objetos)  que  se  
encuentran  en  el  dominio  de  lo  aplicación.  Dichas  clases  podrán  reutilizarse  muchas  
veces.  
 
21.2.2.  El  proceso  de  análisis  del  dominio  
 
El  análisis  del  dominio  del  software  es  la  identificación,  análisis  y  especificación  de  
requisitos  comunes  de  un  dominio  de  aplicación  específico,  normalmente  para  su  
reutilización  en  múltiples  proyectos  dentro  del  mismo  dominio  de  aplicación  (el  
análisis  orientado  a  objetos  del  dominio  es  la  identificación,  análisis  y  especificación  
de  capacidades  comunes  y  reutilizables  dentro  de  un  dominio  de  aplicación  específico,  
en  términos  de  objetos,  clases,  submontajes  y  marcos  de  trabajo  comunes.  
 
  
 
FIGURA  21.1.  Entrada  y  salida  para  análisis  del  dominio.  
 
 
21.4.2.  Modelado  de  clases-­‐responsabilidades-­‐colaboraciones  
 
Una  vez  que  se  han  desarrollado  los  escenarios  de  uso  básicos  para  el  sistema,  es  el  
momento  de  identificar  las  clases  candidatas  e  indicar  sus  responsabilidades  y  
colaboraciones.  
El  modelado  de  clases-­‐responsabilidades-­‐colaboraciones  (CRC)  aporta  un  medio  
sencillo  de  identificar  y  organizar  las  clases  que  resulten  relevantes  al  sistema  o  
requisitos  del  producto.  Ambler  [AMB95]  describe  el  modelado  CRC  de  la  siguiente  
manera:  
 
Un  modelo  CRC  es  realmente  una  colección  de  tarjetas  índice  estándar  que  
representan  clases.  Las  tarjetas  están  divididas  en  tres  secciones.  A  lo  largo  de  la  
cabecera  de  la  tarjeta  usted  escribe  el  nombre  de  la  clase.  En  el  cuerpo  se  listan  las  
responsabilidades  de  la  clase  a  la  izquierda  y  a  la  derecha  los  colaboradores.  
 
Adicionalmente,  los  objetos  y  clases  pueden  clarificarse  por  un  conjunto  de  
características:  
 
Tangibilidad.  ¿Representa  la  clase  algo  tangible  o  palpable  (por  ejemplo,  un  teclado  o  
sensor),  o  representa  información  más  abstracta  (por  ejemplo:  una  salida  prevista)?  
Exclusividad.  ¿Es  la  clase  atómica  (es  decir,  no  incluye  otras  clases)  o  es  agregada  
(incluye  al  menos  un  objeto  anidado)?    
Secuencia.  ¿Es  la  clase  concurrente  (es  decir  posee  su  propio  hilo  de  control)  o  
secuencial  (es  controlada  por  recursos  externos)?  
Persistencia.  La  clase  es  temporal  (se  crea  durante  !a  ejecución  del  programa  y  es  
eliminada  una  vez  que  éste  termina),  o  permanente  (es  almacenada  en  una  base  de  
datos)?  
Integridad.  ¿Es  la  clase  corrompible  (es  decir,  no  protege  sus  recursos  de  influencias  
externas)  o  es  segura  (la  clase  refuerza  los  controles  de  accesos  a-­‐  sus  recursos)?  
 
 
 
CAPÍTULO  

22
 
                         DISEÑO  ORIENTADO  A  OBJETOS  

22.1  Diseño  para  sistemas  orientados  a  objetos  

 
Las  cuatro  capas  de  la  pirámide  de  diseño  O0  son:  
 
1. La  capa  subsistema.  Contiene  una  representación  de  cada  uno  de  los  
subsistemas,  para  permitir  al  software  conseguir  sus  requisitos  definidos  por  
el  cliente  e  implementar  la  infraestructura  que  soporte  los  requerimientos  del  
cliente.  
2. La  capa  de  clases  y  objetos.  Contiene  la  jerarquía  de  clases,  que  permiten  al  
sistema  ser  creado  usando  generalizaciones  y  cada  vez  especializaciones  más  
acertadas.  Esta  capa  también  contiene  representaciones.  
3. La  capa  de  mensajes.  Contiene  detalles  de  diseño,  que  permite  a  cada  objeto  
comunicarse  con  sus  colaboradores.  Esta  capa  establece  interfaces  externas  e  
internas  para  el  sistema.  
4. La  capa  de  responsabilidades.  Contiene  estructuras  de  datos  y  diseños  
algorítmicos,  para  todos  los  atributos  y  operaciones  de  cada  objeto.  
 

 
FIGURA  22.1.  La  pirámide  del  Diseño  OO.  
 
 
 
22.1.1.  Enfoque  convencional  vs.  OO  
 

 
FIGURA  22.2.  Transformación  de  un  modelo  de  análisis  O0  a  un  modelo  de  diseño  OO.  
 
Fichman  y  Kemerer  [FIC92]  sugieren  diez  componentes  de  diseño  modelado,  que  
pueden  usarse  para  comparar  varios  métodos  convencionales  y  orientados  a  objetos:  
 
1. representación  de  la  jerarquía  de  módulos.  
2. especificación  de  las  definiciones  de  datos.  
3. especificación  de  la  lógica  procedimental.  
4. indicación  de  secuencias  de  proceso  final-­‐a-­‐final  (end-­‐to-­‐end)  
5. representación  de  estados  y  transiciones  de  los  objetos.  
6. definición  de  clases  y  jerarquías.  
7. asignación  de  operaciones  a  las  clases.  
8. definición  detallada  de  operaciones.  
9. especificación  de  conexiones  de  mensajes.  
10. identificación  de  servicios  exclusivos.  
 
22.1.2.  Aspectos  del  diseño  
 
Bertrand  Meyer  sugiere  cinco  criterios  para  juzgar  la  capacidad  de  métodos  de  diseño  
para  conseguir  modularidad,  y  los  relaciona  al  diseño  orientado  a  objetos:  
Descomponibilidad:  la  facilidad  con  que  un  método  de  diseño  ayuda  al  diseñador  a  
descomponer  un  problema  grande  en  problemas  más  pequeños,  haciéndolos  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  componente  de  un  programa  puede  ser  
entendido,  sin  hacer  referencia  a  otra  información  o  módulos.  
Continuidad:  la  habilidad  para  hacer  pequeños  cambios  en  un  programa  y  que  se  
revelen  haciendo  los  cambios  pertinentes  en  uno  o  muy  pocos  módulos.  
Protección:  una  característica  arquitectónica,  que  reduce  la  propagación  de  efectos  
colaterales,  si  ocurre  un  error  en  un  módulo  dado.  
 
De  estos  criterios,  Meyer,  sugiere  cinco  principios  básicos  de  diseño,  que  pueden  ser  
deducidos  para  arquitecturas  modulares:  (1)  unidades  lingüísticas  modulares,  (2)  
pocas  interfaces,  (3)  pequeñas  interfaces  (acoplamiento  débil),  (4)  interfaces  
explícitas  y  (5)  ocultación  de  información.  
 
22.1.3.  El  Panorama  de  DO0  
 
Haremos  una  breve  revisión  global  de  los  primeros  métodos  de  DOO:  
 
El  método  de  Booch.  Como  se  vio  en  el  Capítulo  21,  el  método  Booch  abarca  un  
«proceso  de  micro  desarrollo»  y  un  <<proceso  de  macro  desarrollo».  En  el  contexto  
del  diseño,  el  macro  desarrollo  engloba  una  actividad  de  planificación  arquitectónica,  
que  agrupa  objetos  similares  en  particiones  arquitectónicas  separadas,  capas  de  
objetos  por  nivel  de  abstracción,  identifica  situaciones  relevantes,  crea  un  prototipo  
de  diseño  y  valida  el  prototipo  aplicándolo  a  situaciones  de  uso.  
 
El  método  de  Rumbaugh.  La  técnica  de  modelado  de  objetos  (TMO)  [RUM91]  engloba  
una  actividad  de  diseño  que  alienta  al  diseño  a  ser  conducido  a  dos  diferentes  niveles  
de  abstracción.  El  diseño  de  sistema  se  centra  en  el  esquema  de  los  componentes  que  
se  necesitan  para  construir  un  sistema  o  producto  completo.  El  modelo  de  análisis  se  
divide  en  subsistemas,  los  cuales  se  asignan  a  procesadores  y  tareas.  
 
El  método  de  Jacobson.  El  diseño  para  ISOO  (Ingeniería  del  software  orientada  a  
objetos)  es  una  versión  simplificada  del  método  propietario  Objectory,  también  
desarrollado  por  Jacobson.  El  modelo  de  diseño  enfatiza  la  planificación  para  el  
modelo  de  análisis  ISOO.  En  principio,  el  modelo  idealizado  de  análisis  se  adapta  para  
acoplarse  al  ambiente  del  mundo  real.  
 
El  método  de  Coad  y  Yourdon.  Éste  método  para  DO0,  se  desarrolló  estudiando  «cómo  
es  que  los  diseñadores  orientados  a  objetos  efectivos»  hacen  su  trabajo.  La  
aproximación  de  diseño  dirige  no  sólo  la  aplicación,  sino  también  la  infraestructura  de  
la  aplicación,  y  se  enfoca  en  la  representación  de  cuatro  componentes  mayores  de  
sistemas:  la  componente  de  dominio  del  problema,  la  componente  de  interacción  
humana,  la  componente  de  administración  de  tareas  y  la  de  administración  de  datos.  
 
El  método  de  Wirfs-­‐Brock.  Wirfs-­‐Brock,  Wilkerson  y  Weiner  definen  un  conjunto  de  
tareas  técnicas,  en  la  cual  el  análisis  conduce  sin  duda  al  diseño.  Los  protocolos3  para  
cada  clase  se  construyen  refinando  contratos  entre  objetos.  Cada  operación  
(responsabilidad)  y  protocolo  (diseño  de  interfaz)  se  diseña  hasta  un  nivel  de  detalle  
que  guiará  la  implementación.  Se  desarrollan  las  especificaciones  para  cada  clase  
(definir  responsabilidades  privadas  y  detalles  de  operaciones)  y  cada  subsistema  
(identificar  las  clases  encapsuladas  y  la  interacción  entre  subsistemas).  
 
Para  llevar  a  cabo  un  diseño  orientado  a  objetos,  un  ingeniero  de  software  debe  
ejecutar  las  siguientes  etapas  generales:  
 
1. Describir  cada  subsistema  y  asignar  a  procesadores  y  tareas.  
2. Elegir  una  estrategia  para  implementar  la  administración  de  datos,  soporte  de  
interfaz  y  administración  de  tareas.  
3. Diseñar  un  mecanismo  de  control,  para  el  sistema  apropiado.  
4. Diseñar  objetos  creando  una  representación  procedural  para  cada  operación,  y  
estructuras  de  datos  para  los  atributos  de  clase.  
5. Diseñar  mensajes,  usando  la  colaboración  entre  objetos  y  relaciones.  
6. Crear  el  modelo  de  mensajería.    
7. Revisar  el  modelo  de  diseño  y  renovarlo  cada  vez  que  se  requiera.  
 
 

 
 
 
FIGURA  22.3.  Flujo  de  Proceso  para  DOO.  
 
 
22.2  El  proceso  de  diseño  de  sistema  
 
El  diseño  de  sistema  desarrolla  el  detalle  arquitectónico  requerido  para  construir  un  
sistema  o  producto.  El  proceso  de  diseño  del  sistema  abarca  las  siguientes  actividades:  
 
• Partición  del  modelo  de  análisis  en  subsistemas.  
• Identificar  la  concurrencia  dictada  por  el  problema.  
• Asignar  subsistemas  a  procesadores  y  tareas.  
• Desarrollar  un  diseño  para  la  interfaz  de  usuario.  
• Elegir  una  estrategia  básica  para  implementar  la  administración  (gestión)  de  
datos.  
• Identificar  recursos  globales  y  los  mecanismos  de  control  requeridos  para  su  
acceso.  
• Diseñar  un  mecanismo  de  control  apropiado  para  el  sistema,  incluyendo  
administración  de  tareas.  
• Considerar  cómo  deben  manejarse  las  condiciones  de  frontera.  
• Revisar  y  considerar  trade-­‐offs.  
 
Cuando  se  definen  (y  diseñan)  los  subsistemas,  se  deben  seguir  los  siguientes  criterios  
de  diseño:  
 
• El  subsistema  debe  tener  una  interfaz  bien  definida,  a  través  de  la  cual  se  
reduzcan  todas  las  comunicaciones  con  el  resto  del  sistema.  
• Con  la  excepción  de  un  pequeño  número  de  «clases  de  comunicación»,  las  
clases  incluidas  dentro  del  subsistema  deben  colaborar  sólo  con  otras  clases  
dentro  del  subsistema.  
• El  número  de  subsistemas  debe  ser  bajo.  
• Un  subsistema  puede  ser  particionado  internamente,  para  ayudar  a  reducir  la  
complejidad.  
 
Buschmann  y  sus  colegas  sugieren  el  siguiente  enfoque  de  diseño  para  estratificación  
por  capas:  
 
1. Establecer  los  criterios  de  estratificación  por  capas.  Esto  significa  decidir  cómo  
se  agruparán  los  subsistemas  en  una  arquitectura  de  capas.  
2. Determinar  el  número  de  capas.  Muchas  de  ellas  complican  innecesariamente;  
muy  pocas  debilitan  la  independencia  funcional.  
3. Nombrar  las  capas  y  asignar  subsistemas  (con  sus  clases  encapsuladas)  a  una  
capa.  Asegurarse  de  que  la  comunicación  entre  subsistemas  (clases)  en  una  
capa,  y  otros  subsistemas  (clases)  en  otra  capa,  siguen  la  filosofía  de  diseño  de  
la  arquitectura.  
4. Diseñar  interfaces  para  cada  capa.  
5. Refinar  los  subsistemas,  para  establecer  la  estructura  de  clases  para  cada  capa.  
6. Definir  el  modelo  de  mensajería  para  la  comunicación  entre  capas.  
 7. Revisar  el  diseño  de  capas,  para  asegurar  que  el  acoplamiento  entre  capas  se  
minimiza  (un  protocolo  cliente/servidor  puede  ayudar  a  realizar  esta  tarea)  
8. Iterar  para  refinar  el  diseño  de  capas.  
 
22.2.3.  Componente  de  administración  de  tareas  
 
Coad  y  Yourdon  sugieren  la  estrategia  siguiente,  para  el  diseño  de  objetos  que  
manipulan  tareas  concurrentes:  
• se  determinan  las  características  de  la  tarea.  
• se  define  un  coordinador  de  tarea  y  objetos  asociados.  
• se  integra  el  coordinador  y  otras  tareas.  
 
Las  siguientes  etapas  de  diseño  pueden  aplicarse  para  especificar  un  contrato  para  un  
subsistema:  
1. Listar  cada  petición  que  puede  ser  realizada  por  los  colaboradores  del  
subsistema.  Organizar  las  peticiones  por  subsistema  y  definirlas  dentro  de  uno  
o  más  contratos  apropiados.  Asegurarse  de  anotar  contratos  que  se  hereden  de  
superclases.  
2. Para  cada  contrato,  anotar  las  operaciones  (las  heredadas  y  las  privadas,)  que  
se  requieren  para  implementar  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).  
• Colaboradores:  los  nombres  de  los  subsistemas  que  son  parte  del  contrato.  
• Clase:  los  nombres  de  las  clases  (contenidas  en  el  subsistema),  que  
proporcionan  servicios  denotados  por  el  contrato.  
• Operaciones:  nombres  de  las  operaciones  (dentro  de  la  clase),  que  
implementan  los  servicios.  
• Formato  del  mensaje:  el  formato  del  mensaje  requerido  para  implementar  la  
interacción  entre  colaboradores.  
 

 
4. Si
 los
 modos
 de
 interacción
 entre
 los
 subsistemas
 son
 complejos,
 debe
 crear
 un
 
diagrama
 subsistema-­‐colaboración
 como
 el
 de
 la
 Figura
 22.6.
 El
 grafo
 de
 
colaboración
 es
 similar,
 en
 forma,
 al
 diagrama
 de
 flujo
 de
 sucesos
 examinado
 
en
 el
 Capítulo
 2
 1.
 Cada
 subsistema
 se
 representa,
 junto
 con
 sus
 interacciones
 
con
 otros
 subsistemas.
 Los
 contratos
 que
 se
 invocan
 durante
 interacción,
 se
 
 detallan
 como
 se
 muestra
 en
 la
 Figura.
 Los
 detalles
 de
 la
 interacción
 se
determinan
 observando
 el
 contrato
 en
 la
 tabla
 de
 colaboración
 del
 subsistema.
INGENIERfA DEL SOFTWARE. U N ENFOQUE PR A CTICO
Incluir
 en
 el
 Resumen
 paginas
 387-­‐403
Estudiar
  El objetivo de esta sección es mostrar el uso de diagra-
mas UML, descrito en la Sección 22.25, aplicado a un
  sistema real. Este sistema es un sistema de comercio
electrónico (e-commerce).
 
22.6.1. Libros-en-línea
  Libros-en-línea es una compañía creada reciente-
mente, que es subsidiaria de otra gran compañía mul-
tinacional de comercio, conocida como Pollday
  Publishing. Los directores de Pollday Publishing se
decidieron a llevar a cabo un gran crecimiento en ven-
  tas por internet entre sus clientes, y decidieron pre-
parar a Libros-en-Línea para ello. El concepto que
Pollday tiene es el de un sitio Web de comercio elec-
  trónico, que tenga catálogos detallados de cada libro
que manejan, junto con recursos con los que el usua-
rio del sitio Web puede ordenar libros, utilizando una
forma incluida en una página Web. A continuación,
se muestran algunos extractos, tomados del conjun-
  to de requisitos iniciales, detallados por el equipo téc-
nico de Libros-en-línea:
1. Libros-en-línea desea desarrollar la capacidad de
  ventas en línea por medio de la Web. EL sitio web
que implementa esta capacidad debe permitir al
cliente examinar los detalles del libro, ordenarlo y
  registrar su dirección de correo electrónico para reci-
bir ofertas especiales con detalles, publicaciones nue-
  vas y revisiones.
2. Cuando un cliente accede al sitio Web, cada uno de
los recursos antes descritos se despliegan.
  3. Si el cliente registra su dirección de correo electró-
nico, se le preguntarán su información personal. Esto
  incluye su nombre, una dirección de correo electró-
nico, una dirección postal. Un miembro del equipo
conocido como el administrador de contratos será el
  responsable de enviar información de oferta, etc., a
los clientes.
4. El cliente podrá comprar libros del catálogo en
  línea, examinando las páginas con detalles de los
libros y seleccionando el libro, que comprará
  mediante algún mecanismo como el de presionar
un botón. El sistema deberá mantener un carrito de
compras virtual, en el que los detalles de cada libro
  se almacenan. Conforme el carrito se va llenando
de libros, se muestra al cliente el precio acumulado
de todas sus compras.
5. Cuando el cliente ha terminado de comprar en el sitio
Web, se le pedirá información acerca de qué forma
  de envío se utilizará. Por omisión se mostrará la
opción de envío por correo estándar, y un servicio
de envío expreso garantizado para entregar dentro
  de 24 horas.
  398
6. El sitio web deberá interactuar con un sistema de
control de inventario, que también requiere desarro-
llo. Este sistema de control de inventarios debe mane-
jar el proceso de recepción de libros de los inventarios
de las editoriales, retiro de libros cuando se ordenan
por parte de un cliente, y reordenación de existencia
de un libro, cuando se encuentra por vaciarse, para
encarar un problema de suministros, en un tiempo
de siete días.
7. El control de inventarios por parte del administrador
será fijado en un tiempo de siete semanas. Él o ella
tendrán la responsabilidad de mantener las ventas, y
la disponibilidad de existencias y, cuando las exis-
tencias de un libro se encuentren bajas, hacer un
nuevo pedido. Para realizar esto, este sistema de con-
trol de inventarios debe proporcionar informes de
ventas y existencias de inventario con regularidad.
8. Un Administrador de Marketting intervendrá cada
ocho semanas. El Jefe de Marketting tendrá la fun-
ción de determinar los precios a los que los libros
serán vendidos. Se dará la situación de que un libro
puede tener un número diferente de precios durante
su tiempo de vida; por ejemplo, se debe decidir si se
ofrece con un mayor descuento durante las primeras
semanas, y luego ajustar el precio a los precios reco-
mendados por las editoriales.
La compañía que desarrolló el software para Libros-
en-línea, primero identificó un número de clases candi-
datas, que a continuación se detallan:
RegistroCliente. Detalles de alguien que compra
libros, o que se registró para recibir correos electró-
nicos con información.
Libro. El artículo principal, qué Libros-en-línea
vende.
Orden. Una orden que un cliente realiza, para uno
o más libros. Esta orden debe ser para una simple
copia de un libro, o para copias de un número de
libros o incluso múltiples copias de muchos libros.
Una orden contendrá un número de líneas de orden
(véase a continuación),y una especificación de envío.
LíneaDeOrden. Esta es una simple línea de orden.
Por ejemplo la orden de la copia de un libro. Una
orden consistirá en una o más líneas de orden. Una
línea de orden contendrá información acerca de
qué libro se ordena y la cantidad ordenada (usual-
mente 1).
Carrito. Es un contenedor que existe durante la
exploración del sitio Web, por parte de un cliente que
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.

OrdenEspera. Esta es una parte de la orden, la cual
no puede cumplirse por las existencias del almacén.
Si el cliente está conforme, esperando por un libro
que no está en existencia, entonces se realiza una
orden de espera. Esta orden de espera se satisface,
cuando las existencias del libro se restauran por
Libros-en-línea.
Almacén. Esta es una colección de libros que se
encuentran en existencia. Una orden de libro o de
colección de libros se manda al almacén y de ahí
se retiran los libros de sus cajas del almacén, se
empaquetan y se despachan al cliente. En ese
momento, se ajustan los detalles de las existen-
cias.
RegistroExistencias. Estos son los datos que des-
criben los detalles de las existencias de un libro;
por ejemplo, cuántos hay en existencia, el nivel
actual cuando se ha hecho una requisición a las edi-
toriales, y la localización de los libros dentro del
almacén.
NotaEmpaque. Esta es una nota enviada con una
colección de libros al cliente. La nota de empaque
contiene información acerca de cuántos libros se
enviaron y la tarifa de envío aplicada. También puede
contener detalles de algunos libros, que no pudieron
ser enviados porque no se encontraban en las exis-
tencias.
Tarjetacrédito. Un cliente pagará por sus libros
mediante una tarjeta de crédito. El sistema permite
al cliente pre-registrar su o sus tarjetas, para que
no tenga que reescribirlas cada vez que haga una
orden.
Registro
/ /
’/
Q-------
A \ Comprobar pedido
Borrar tarjeta
de crédito
Registrar
tarjeta de crédito
FIGURA 22.25. Algunos casos de uso para el actor Cliente.
399
CAPfTULO 22 DISENO ORIENTADO A O B J E T O S
Estas fueron, entonces, las clases identificadas princi-
palmente. También se identificaron un número de actores:
Cliente. Este es el actor principal: la persona que
lleva a cabo las acciones, que resultan en los mayo-
res cambios de estado del sistema.
Administrador de marketting. Es un actor importante
que ajusta muchos de los parámetros del sistema,
tales como el precio de los libros.
Administrador del control de inventarios. Alguien
que controla los inventarios en un almacén y toma
decisiones acerca de las órdenes.
Existen un gran número de casos de uso asociados
con estas acciones, muchas de ellas asociados con el
actor cliente, se muestran en la Figura 22.25.
La selección de casos de uso asociados con el Cliente, y
las mostradas en la Figura 22.25 incluyen casos de uso para:
Registro. Aquí el cliente proporciona su nombre y
su clave. Una vez registrada, pueden examinar el
catálogo de libros.
Ordenar. Aquí el cliente ordena una o más copias de
un libro.
Realizar. El cliente completa la orden y ordena al sis-
tema iniciar el proceso en que la orden se despacha.
Buscar un libro. El cliente busca, en el catálogo en
línea, un libro específico.
Eliminar tarjeta de crédito. Aquí el cliente puede eli-
minar una o más de las tarjetas de crédito registra-
das y asociadas con él.
Registrar tarjeta de crédito. Aquí el cliente registra
una o más de sus tarjetas de crédito al sistema.
Una porción de uno de estos diagramas de clase para
el sistema, se muestra en la Figura 22.26. Un número
de roles asociados con el diagrama se ha omitido; regu-
larmente se incluyen. Algunas de las relaciones entre
clase, también se omitieron.
El diagrama muestra muchas de estas clases antes
descritas. Las únicas clases que se omitieron son:
Ordensatisfecha y OrdenEspera. Estas dos clases son
especializaciones de la clase Orden, que representa una
orden de libros para un cliente.
DeQrden
FIGURA 22.26. Una sección de un diagrama de clases
para el caso de estudio.
 con un solo cliente.
Un cliente se asocia con un número de órdenes satis-
fechas, las cuales se realizan sobre un período de
tiempo. Cada orden satisfecha se asocia con un solo
cliente.
Un cliente se asocia con un número de órdenes en
espera, que actualmente no pueden ser satisfechas.
Cada orden en espera se asocia con un solo cliente.
La Figura
- 22.26 muestra solo algunas
- de las rela-
cienes involucradas, por ejemplo, existe una relación
La etapa final de desarrollo, dentro del ciclo de vida
orientada a objetos, es la programación. No es la
intención de este libro llegar a más detalle acerca de
este proceso; la programación es analizada como
importante pero como actividad subsidiaria al análi-
sis y diseño; pero se proporciona una pequeña intro-
ducción en el lenguaje de programación Java. La
sección otras lecturas y fuentes de información al
final del capítulo detalla un gran número de buenos
libros sobre el tema.
El proceso de programación involucra la conversión
de un diseño orientado a objetos en un código de pro-
grama. Efectivamente, esto significa que las clases defi-
nidas en el diseño deben ser convertidas en clases
expresadas en un lenguaje de programación orientado
a objetos como Java, C++ o SmallTalk. Esta sección se
concentra en Java, que se está volviendo rápidamente
el lenguaje de programación de facto, para desarrollar
los modernos sistemas distribuidos.
Una clase en Java se introduce por medio de la pala-
bra clave class, dentro del código para la clase; el pro-
gramador define los atributos y operaciones para la clase.
400
duce a la terminación. Cuando el cliente indica que se
ha llegado al fin de la orden, entonces la orden se vuel-
ve una orden de libros completa. En este punto, el clien-
te tiene dos opciones: cancelar al orden o especificar el
tipo de envío que se usará para la orden. Si se seleccio-
na el tipo de envío, entonces la orden se convierte en
una orden completa. En esta etapa, el cliente tiene otras
dos opciones: confirmar la orden, en este caso la orden
se envía para ser procesada, o cancelar la orden. Ambas
opciones conducen al punto de salida del diagrama de
estados.
TOS
Un ejemplo del código esqueleto de una clase se mues-
tra a continuación.
clacc Cliente {
priva te String NombreCliente;
priva te String DireccionCliente;
// se definen más atributos aquí
public String obtenerNombreCliente/)
i
//código para obtenerNombreCliente
1
public void modificarDireccionCliente( String
direccion j
i
//código para modificarDireccionCliente
1
//código para las operaciones restantes
1
La primera línea de código define que el nombre de
la clase será Cliente. Inmediatamente a continuación,
las descripciones de atributos de clase. En el código
anterior, solo se muestran dos atributos: el nombre del