CasaSegura Errores de comunicación
Lugar de trabajo del equipo de ingeniería de software. Participantes: Jaime Lazar, Vinod Roman y Ed Robins, miembros del equipo de software. La escena:
La conversación: Ed: ¿Qué has oído
sobre el proyecto de
CasaSegura ? Vinod: La reunión de arranque está programada para la semana siguiente. Jamie: Traté de investigar algo, pero no salió bien. Ed: ¿Qué quieres decir? Jamie: Bueno, llamé a Lisa Pérez. Ella es la encargada de mercadotecnia en esto.
¿Qué te dice eso? (Jaime se encoge de hombros.) Vinod: Será que mercadotecnia quiere que actuemos como consultores y que mejor hagamos alguna tarea sobre esta área de productos antes de nuestra junta de arranque. Doug dijo que quería que Vinod:
―colaboráramos‖ con nuestro cliente, así
quería que me dijera las características y funciones de
que será mejor que aprendamos cómo hacerlo. Ed: Tal vez hubiera sido mejor ir a su oficina. Las llamadas por teléfono simplemente no sirven para esta clase de trabajos. Jamie: Están en lo correcto. Tenemos que actuar juntos o nuestras primeras comunicaciones comunicaciones serán una batalla. Vinod: Yo vi a Doug leyendo un libro acerca
CasaSegura… esa clase de cosas. En lugar
de ‖requerimientos de ingeniería‖. Apuesto
Vinod: ¿Y…? Jamie: Yo
de ello comenzó
a hacerme preguntas
sobre sistemas de seguridad, de vigilancia…
No soy experto en eso.
que enlista algunos principios de buena comunicación. comunicación. Voy a pedírselo prestado. Jamie: Buena idea… Luego nos enseñas. Vinod (sonríe): Si, de acuerdo.
CasaSegura Conducción de una reunión para recabar los requerimientos.
Sala de juntas. Está en marcha la primera reunión para recabar los requerimientos. Participantes: Jaime Lazar, integrante del equipo de software; Vinod Roman, miembro del equipo de software; Ed Robbins, miembro del equipo software; Doug Miller, gerente de ingeniería del software; tres trabajadores de mercadotecnia; un representante de ingeniería del producto, y un facilitador. La escena:
La conversación: Facilitador (apunta en un pizarrón):
De modo que esa es la lista actual de objetos y servicios para la función de seguridad del hogar. Persona de mercadotecnia: Eso la cubre, desde nuestro punto de vista. Vinod: ¿No dijo alguien que quería que de toda la funcionalidad de CasaSegura fuera accesible desde internet? Eso incluiría la función de seguridad, ¿o no? Persona de mercadotecnia: Si, así es…
tendremos que añadir esta funcionalidad y los objetos apropiados.
Facilitador:
¿Agrega
eso
algunas
restricciones? Jamie: Si, tanto técnicas como legales.
Nos tendríamos que asegurar de que un extraño no pueda ingresar al sistema, desactivarlo y robar en el lugar o hacer algo peor. Mucha responsabilidad sobre nosotros. Doug: Muy cierto. Representante
del
producto:
Mercadotecnia: Pero lo necesitamos así…
solo asegúrense de impedir que ingrese un extraño. Ed: Eso es más fácil de decir que de hacer. Facilitador (interrumpe): No quiero que debatamos esto ahora. Anotémoslo como un aspecto y continuemos. (Doug, que es el secretario de la reunión, toma debida nota.) Facilitador: Tengo la sensación de que hay más por considerar aquí. (El grupo dedica los siguientes 20 minutos a mejorar y aumentar los detalles de la función de seguridad del hogar.)
CasaSegura Desarrollo de un escenario preliminar de uso
Una sala de juntas, donde continúa la primera reunión para recabar los requerimientos. Participantes: Jaime Lazar, integrante del equipo de software; Vinod Roman, miembro del equipo de software; Ed Robbins, miembro del equipo software; Doug Miller, gerente de ingeniería del software; tres personas de mercadotecnia; un representante de ingeniería del producto, y un facilitador. La escena:
La conversación: Facilitador: Hemos
estado hablando sobre la seguridad para el acceso a la funcionabilidad de CasaSegura si ha de ser posible el ingreso por internet. Me gustaría probar algo. Desarrollemos un escenario de uso para entrar a la función de seguridad. Jamie: ¿Cómo? Facilitador: Podríamos hacerlo de dos maneras, pero de momentos mantengamos las cosas informales. Díganos (señala a una persona de mercadotecnia), ¿cómo visualiza el acceso al sistema. Persona de mercadotecnia: Um… bueno, es
la clase de cosa que haría si estuviera fuera de casa y tuviera que dejar entrar a alguien a ella –por ejemplo, una trabajadora doméstica o un técnico de reparacionesque no tuviera el código de seguridad. Facilitador (sonríe): Esa es la razón por la que lo hace… dígame, ¿cómo lo haría en
realidad?
Persona de mercadotecnia: Bueno… lo
primero que necesitaría sería una PC. Entraría a un sitio web que mantendríamos para todos los usuarios de CasaSegura. Daría mi identificación de usuario y…
La página web tendría que ser segura, encriptado, para garantizar Vinod (interrumpe):
que estuviéramos seguros y… Facilitador (interrumpe): Ésa
es buena información, Vinod, pero es técnica. Concentrémonos en como emplearía el usuario final esta capacidad, ¿está bien? Vinod: No hay problema. Persona de mercadotecnia: Decía que entraría a un sitio web y daría mi identificación de usuario y dos niveles de clave. Jamie: ¿Qué pasa si olvido mi clave? Facilitador (interrumpe): Buena observación, Jamie, pero no entraremos a ella por ahora y la llamaremos una excepción. Estoy seguro de que habrá otras. Persona de mercadotecnia: Después de que introdujera las claves, aparecería una pantalla que representaría todas las funciones CasaSegura. Seleccionaría la función de seguridad del hogar. El sistema pediría que verificara quien soy, pidiendo mi dirección o número telefónico o algo así. Entonces aparecería un dibujo del panel de control del sistema de seguridad y la lista de funciones que puede realizar –activar el sistema, desactivar el sistema o desactivar uno o más sensores-. Supongo que también me permitiría reconfigurar las zonas de seguridad y otras cosas como esa, pero no estoy seguro. (Mientras la persona de mercadotecnia habla, Doug toma muchas notas; esto forma la base para el primer escenario informal de uso. Alternativamente hubiera podido pedirse a la persona de mercadotecnia que escribiera el escenario, pero esto se hubiera hecho fuera de la reunión.)
CasaSegura Desarrollo de un diagrama de caso de uso de alto nivel
Una sala de juntas, donde continúa la reunión para recabar los requerimientos. Participantes: Jaime Lazar, integrante del equipo de software; Vinod Roman, miembro del equipo de software; Ed Robbins, miembro del equipo software; Doug Miller, gerente de ingeniería del software; tres miembros de mercadotecnia; un representante de ingeniería del producto, y un facilitador. La escena:
La conversación: Facilitador: Hemos
pasado un buen tiempo hablando de la función de seguridad del hogar de CasaSegura. Durante el receso hice un diagrama de caso de uso para resumir los escenarios importantes que forman parte de esta función. Veámoslo. (Todos los asistentes observan la figura 5.2) Jamie: Estoy aprendiendo la notación UML. Veo que la función de seguridad del hogar del hogar está representada por el rectángulo grande con óvalos en su interior, ¿verdad? ¿Y los óvalos representan los casos de uso que hemos escrito? Facilitador: Sí. Y las figuras pegadas representan a los actores –personas o
cosas que interactúan con el sistema según los describe el caso de uso… -; ¡ah! Usé el cuadrado para representar un actor que no es persona.. en este caso, sensores. Doug: ¿Es válido eso en UML? Facilitador: La legalidad no es lo importante. El objetivo es comunicar información. Veo que usar una figura humana para representar un equipo sería erróneo. Así que adopté las cosas un poco. No pienso que genere problemas. Vinod: Está bien, entonces tenemos narraciones de casos de uso para cada óvalo. ¿Necesitamos desarrollarlas con base en los formatos obre los que he leído? Facilitador: Es probable, pero eso puede esperar hasta que hayamos considerado otras funciones de CasaSegura. Persona de mercadotecnia: Esperen, he estado observando este diagrama y de pronto me doy cuenta de que hemos olvidado algo. Facilitador: ¿De verdad? Dime, ¿Qué hemos olvidado? (La reunión continúa.)
CasaSegura Modelado preliminar del comportamiento
Sala de juntas, continúa la reunión de requerimientos. Participantes: Jaime Lazar, integrante del equipo de software; Vinod Roman, miembro del equipo de software; Ed Robbins, miembro del equipo software; Doug Miller, gerente de ingeniería del software; tres trabajadores de mercadotecnia; un representante de ingeniería del producto, y un facilitador. La escena:
La conversación: Facilitador: Estamos
por terminar de hablar sobre la funcionalidad de seguridad del hogar de CasaSegura. Pero antes, quisiera que analizáramos el comportamiento de la función. Persona de mercadotecnia: No entiendo lo que quiere decir con comportamiento. Ed (sonríe): Es cuando le das un ―tiempo fuera‖ al producto si se porta mal. Facilitador: No exactamente. Permítanme
explicarlo. (El facilitador explica al equipo encargado de recabar los requerimientos y los
fundamentos de comportamiento.)
modelado
del
Esto parece un poco técnico. No estoy seguro de ser de ayuda aquí. Facilitador: Seguro que lo serás. ¿Qué comportamiento se observa desde el punto de vista de un usuario? Persona de mercadotecnia: Mmm.. bueno, el sistema estará vigilando los sensores. Leerá comandos del propietario. Mostrará su estado. Facilitador: ¿Ves?, lo puedes hacer. Jamie: También estará interrogando a la PC para determinar si hay alguna entrada desde ella, por ejemplo, un acceso por internet o información sobre la configuración. Vinod: Si, en realidad, configurar el sistema es un estado por derecho propio. Doug: Muchachos, lo hacen bien. Pensemos Persona de mercadotecnia:
un poco más… ¿hoy alguna forma de hacer
un diagrama de todo esto? Facilitador: Si lo hay, pero la dejaremos para la próxima reunión.
CasaSegura El principio de una negociación
Oficina de Lisa Pérez, después de la primera reunión para recabar los requerimientos. Participantes: Doug Miller, gerente de ingeniería de software, y Lisa Pérez, gerente de mercadotecnia.
establecida, pero tendríamos que retrasar el acceso por internet hasta el segundo incremento. Lisa: Doug, es el acceso por internet lo que
La conversación: Lisa: Pues escuché
alrededor de eso. Lo tenemos que tener… Doug: Entiendo la situación, de verdad. El
La escena:
que la primera reunión
salió realmente bien. Doug: En realidad, sí. Enviaste buenos
representantes… contribuyeron de verdad. Lisa (sonríe): Si; en realidad me dijeron
que habían entrado y que no había sido una ―actividad que les despejara la cabeza‖. Doug (ríe): La próxima vez me asegurare de quitarme la vena tecnológica… Mira, Lisa,
creo que tenemos un problema para llegar a toda esa funcionalidad del sistema de seguridad para el hogar en las fechas que propone tu dirección. Sé que aún es temprano, pero hice un poco de planeación sobre las rodillas y… Lisa (con el ceño fruncido):
Lo debemos tener para esa fecha, Doug. ¿De qué funcionalidad hablas? Doug: Suponga que podamos tener la funcionalidad completa en la fecha
da a CasaSegura su ―súper‖ atractivo. Toda
nuestra campaña de publicidad va a girar
problema es que para dar acceso por internet tendríamos que tener un sitio web por completo seguro y en operación. Esto requiere tiempo y personal. También tenemos que elaborar mucha funcionalidad adicional en la primera entrega… no creo
que podamos hacerlo con los recursos que tenemos. Lisa (todavía frunce el ceño): Ya veo, pero tienes que imaginar una manera de hacerlo. Tiene importancia crítica para las funciones del hogar y también para otras…
estas podrían esperar hasta las siguientes entregas… estoy de acuerdo con eso.
Lisa y Doug parecen estar en suspenso, pero todavía deben negociar una solución a este problema ¿Pueden ―ganar‖ los dos en
este caso? Si usted fuera el mediador, ¿Qué sugeriría?
CasaSegura Análisis de dominio
Oficina de Doug Miller, después de una reunión con personal de mercadotecnia. Participante: Doug Miller, gerente de ingeniería de software, y Vinos Raman, miembro del equipo de ingeniería de software. La
escena:
La conversación Doug: Te necesito
para un proyecto especial, Vinod Voy a retirarte de las reuniones para recabar los requerimientos. Vinod (con el ceño fruncido): Muy mal. Ese formato en verdad funciona… Estaba
sacando algo de ahí. ¿Qué pasa? Doug: Jamie y Ed te cubrirán. De cualquier manera, el departamento de mercadotecnia insiste en que en la primera entrega de CasaSegura dispongamos de la capacidad de acceso por internet junto con la función de seguridad para el hogar. Estamos bajo
fuego en esto… sin tiempo ni personal
suficiente, así que tenemos que resolver ambos problemas a la vez: la interfaz de PC y la interfaz de web. Vinod (confundido): No sabía que el plan era entregar… ni siquiera hemos terminado
de recabar los requerimientos.
Lo sé, pero los plazos son tan breves que decidí comenzar ya la estrategia con Doug (con una sonrisa tenue):
mercadotecnia…
de
cualquier
modo,
revisaremos cualquier plan tentativo una vez que tengamos la información de todas las juntas que se efectuaran para recabar los requerimientos. Vinod: Está bien, ¿entonces? ¿Qué quieres que haga Doug: ¿Sabes que es el ―análisis de dominio‖?
Algo sé. Buscas patrones similares en aplicaciones que hagan lo mismo que la que estés elaborando. Entonces, si es posible, calcas los patrones y los reutilizas en tu trabajo. Doug: No estoy segura de que la palabra sea calcar, pero básicamente tienes razón. Lo que me gustaría que hicieras es que comenzaras a buscar interfaces de usuario ya existentes para sistemas que controlen algo como CasaSegura. Quiero que propongas un conjunto de patrones y clases de análisis que sean comunes tanto a la interfaz basada en PC que estará en el hogar como a la basada en un navegador al que se accederá por internet. Vinod: Ahorraríamos tiempo si las Vinod:
hiciéramos iguales… ¿Por qué no las
hacemos así?
Doug: Ah… es grato tener ge nte que piense
como lo haces tú. Ese es el meollo del asunto: ahorraremos tiempo y esfuerzo si las dos interfaces son casi idénticas; las implementamos con el mismo código y acabamos con la insistencia de mercadotecnia. Vinod: ¿Entonces, que quieres?, ¿clases, patrones de análisis, patrones de diseño? Doug: Todo eso. Nada formal en este momento. Solo que comencemos despacio con nuestros trabajos de análisis interno y de diseño. Vinod: Iré a nuestra biblioteca de clases y veré que tenemos. También usare un formato de patrones que vi en un libro que leí hace unos meses. Doug: Bien manos a la obra.
CasaSegura Desarrollo de otro escenario preliminar de uso La escena:
Sala de juntas, durante la segunda reunión para recabar los requerimientos. Participantes: Jamie Lazar, miembro del equipo del software; Ed Robbins, integrante del equipo del software; Doug Miller, gerente de ingeniería de software; tres miembros de mercadotecnia; un representante de ingeniería del producto, y un facilitador.
La conversación: Facilitador: Es hora de que hablemos sobre
la función de vigilancia de CasaSegura. Vamos a desarrollar un escenario de usuario que accede a la función de vigilancia. Jamie: ¿Quién juega el papel del actor aquí? Facilitador: Creo que Meredith (persona de mercadotecnia) ha estado trabajando en dicha funcionalidad. ¿Por qué no adoptas tú ese papel? Meredith: Quieres que lo hagamos de la misma forma que la vez pasada, ¿verdad? Facilitador: Si… en cierto modo, Meredith: Bueno, es obvio que la
razón de la vigilancia es permitir que el propietario de la casa la revise cuando se encuentre fuera, así como poder grabar y reproducir el video que se grabe… esa clase de cosas. Ed: ¿Usaremos compresión para grabar el
video?
Buena pregunta, Ed, pero por ahora pospondremos los aspectos de la implementación. ¿Meredith? Meredith: Bien, básicamente hay dos Facilitador:
partes en la función de vigilancia… la
primera configura el sistema, incluso un
plano de la planta – tiene que haber herramientas que ayuden al propietario a hacer esto-, y la segunda parte es la función real de vigilancia. Como el plano es parte de la actividad de configuración, me centrare en la función de vigilancia. Facilitador (sonríe): Me quitaste las palabras de la boca. Meredith: Mmm… quiero tener acceso a la función de vigilancia, ya sea por PC o por internet. Tengo la sensación de que el acceso por internet se usaría con más frecuencia. De cualquier manera, quisiera poder mostrar vistas de la cámara de una PC y controlar el ángulo y acercamiento de una cámara particular. Especificaría la cámara seleccionándola en el plano de la casa. También quiero poder bloquear el acceso a una o más cámaras con una clave determinada. Además, desearía tener la opción de ver pequeñas ventanas con vistas de todas las cámaras y luego escoger una que desee agrandar. Jamie: Ésas se llaman vistas reducidas. Meredith: Bien, entonces quiero vistas reducidas de todas las cámaras. También quisiera que la interfaz de la función de vigilancia tuviera el mismo aspecto y sensación que todas las demás del sistema CasaSegura. Quiero que sea intuitiva, lo que significa que no tenga que leer un manual para usarla. Facilitador: Buen trabajo. Ahora, veamos esta función con un poco más de detalle…
CasaSegura Formato de caso de uso para vigilancia
Caso de uso: Acceder a la vigilancia con cámaras por internet, mostrar vistas de cámaras (AVC- MVC). Iteración: 2, última modificación: 14 de enero por V. Raman. Actor principal: Propietario. Objetivo en contexto: Ver la salida de las cámaras colocadas en la casa desde cualquier ubicación remota por medio de internet. Precondiciones: El sistema debe estar configurado por completo; deben obtenerse las identificaciones y claves de usuario apropiadas. Disparador: El propietario decide ver dentro de la casa mientras está fuera.
2. La función de vigilancia no está configurada para este sistema (el sistema muestra el mensaje de error apropiado; véase el caso de uso Configurar la función de vigilancia ). 3. El propietario selecciona ―Mirar vistas reducidas de todas las cámaras‖ (véase el caso de uso Mirar vistas reducidas de todas las cámaras).
1. El propietario se registra en el sitio web Productos CasaSegura. 2. El propietario introduce su identificación de usuario. 3. El propietario proporciona dos claves (cada una con longitud de al menos ocho caracteres). 4. El sistema despliega todos los botones de las funciones principales.
4. No se dispone o no se ha configurado el plano de la casa (se muestra el mensaje de error apropiado y véase el caso de uso Configurar plano de la casa ). 5. Se encuentra una condición de alarma (véase el caso de uso Condición de alarma encontrada). Prioridad: Moderada, por implementarse después de las funciones básicas. Cuándo estará disponible: En el tercer incremento. Frecuencia de uso: Frecuencia moderada. Canal al actor: A través de un navegador con base en PC y conexión a internet. Actores secundarios: Administrador del sistema, cámaras.
5. El propietario selecciona ―vigilancia‖
Canales a los actores secundarios:
Escenario:
entre los botones de funciones principales.
6. El propietario escoge ―seleccionar una cámara‖.
7. El sistema muestra el plano de la casa. 8. El propietario selecciona un ícono de cámara en el plano de la casa. 9. El propietario pulsa el botón ―vista‖.
10. El sistema muestra la ventana de la vista de la cámara identificada. 11. El sistema presenta una salida de video dentro de la ventana de vistas, con una velocidad de un cuadro por segundo. Excepciones:
1. La identificación o las claves son incorrectas o no se reconocen (véase el caso de uso Validar identificación y claves).
1. Administrador del sistema: sistema basado en PC. 2. Cámaras: conectividad inalámbrica. Asuntos pendientes:
1. ¿Qué mecanismos protegen el uso no autorizado de esta capacidad por parte de los empleados de Productos CasaSegura? 2. Es suficiente la seguridad? El acceso ilegal a esta característica representaría una invasión grave de la privacidad. 3. ¿Será aceptable la respuesta del sistema por internet dado el ancho de banda que requieren las vistas de las cámaras? 4. ¿Desarrollaremos una capacidad que provea el video a una velocidad más alta en cuadros por segundo cuando se disponga de conexiones con un ancho de banda mayor?
CasaSegura Modelos de clase
Cubículo de Ed, cuando comienza el modelado de los requerimientos. Participantes: Jamie, Vinod y Ed, todos ellos miembros del equipo de ingeniería de software para CasaSegura. La
escena:
La conversación:
[Ed ha estado trabajando para obtener las clases a partir del formato del caso de uso para AVC-MVC (presentado en un recuadro anterior de este capítulo) y expone a sus colegas las que ha obtenido]. Ed: Entonces, cuando el propietario quiere escoger una cámara, la tiene que elegir del plano. Definí una clase llamada Plano. Éste es el diagrama. (Observan la figura 6.10.) Jamie: Entonces, Plano es un objeto que agrupa paredes, puertas, ventanas y cámaras. Eso significa esas líneas con leyendas, ¿verdad? Ed: Sí, se llaman ―asociaciones‖. Una clase
se asocia con otra de acuerdo con las asociaciones que se ven (las asociaciones se estudian en la sección 6.5.5). Vinod: Es decir, el plano real está constituido por paredes que con- tienen en su interior cámaras y sensores. ¿Cómo sabe el plano dónde colocar estos objetos? Ed: No lo sabe, pero las otras clases sí. Mira los atributos de, digamos, SegmentodePared, que se usa para construir una pared. El segmento de muro tiene coordenadas de inicio y final, y la operación draw( ) hace el resto.
Jamie: Y
lo mismo vale para las ventanas y puertas. Parece como si cámara tuviera algunos atributos adicionales. Ed: Sí. Los necesito para dar información del alcance y el acercamiento. Vinod: Tengo una pregunta. ¿Por qué tiene la cámara una identificación pero las demás no? Veo que tienes un atributo llamado ParedSiguiente. ¿Cómo sabe SegmentodePared cuál será la pared siguiente? Ed: Buena pregunta, pero, como dijimos, ésa es una decisión de diseño, por lo que la voy a retrasar hasta... Jamie: Momento... Apuesto a que ya lo has imaginado. Ed (sonríe con timidez): Es cierto, voy a usar una estructura de lista que modelaré cuando vayamos a diseñar. Si somos puristas en cuanto a separar el análisis y el diseño, el nivel de detalle podría parecer sospechoso. Jamie: Me parece muy bien, pero tengo más preguntas. (Jamie hace preguntas que dan como resultado modificaciones menores.) Vinod: ¿Tienes tarjetas CRC para cada uno de los objetos? Si así fuera, debemos actuar con ellas, sólo para estar seguros de que no hemos omitido nada. Ed: No estoy seguro de cómo hacerlas. Vinod: No es difícil y en verdad convienen. Te mostraré.
CasaSegura Modelos CRC
La escena: Cubículo de Ed cuando comienza el modelado de los requerimientos. Participantes: Vinod y Ed, miembros del equipo de ingeniería de software de CasaSegura. La conversación:
[Vinod ha decidido enseñar a Ed con un ejemplo cómo desarrollar las tarjetas CRC.] Vinod: Mientras tú trabajabas en la vigilancia y Jamie lo hacía con la seguridad, yo estaba en la función de administración del hogar. Ed: ¿Cuál es el estado de eso? Mercadotecnia cambia lo que quiere a cada rato. Vinod: Aquí está la primera versión de caso de uso para toda la función... la mejoramos un poco, pero debe darte el panorama general... Caso de uso: Función de administración de CasaSegura. Narración: Queremos usar la interfaz de administración del hogar en una PC o en una conexión de internet para controlar los dispositivos electrónicos que tengan controladores de interfaz inalámbrica. El sistema debe permitir encender y apagar focos específicos, controlar aparatos conectados a una interfaz inalámbrica y fijar el sistema de calefacción y aire acondicionado a la temperatura que desee. Para hacer esto, quiero seleccionar los aparatos en el plano de la casa. Cada equipo debe estar identificado en el plano. Como característica opcional, quiero controlar todos los equipos audiovisuales: sonido, televisión, DVD, grabadoras digitales, etcétera. Con una sola selección, quiero preparar toda la casa para distintas situaciones. Una es casa, otra es salir, la tercera es viaje nocturno y la cuarta es viaje largo. Todas estas situaciones tienen especificaciones que se aplicarán a todos los equipos. En los estados de viaje nocturno y viaje largo, el sistema debe encender y apagar focos en momentos elegidos al azar (para que parezca que hay alguien en casa) y controlar el sistema de calefacción y aire acondicionado. Debo poder hacer esta preparación por internet, con la protección de claves adecuadas... Ed: ¿El personal de hardware ya tiene listas todas las interfaces inalámbricas? Vinod (sonríe): Están trabajando en eso; dicen que no hay problema. De cualquier forma, obtuve muchas clases para la administración del hogar y podemos usar una como ejemplo. Tomemos la clase InterfazdeAdministracióndelHogar. Ed: Bien... entonces, las responsabilidades son... los atributos y operaciones para la clase, y las colaboraciones son las clases que indican las responsabilidades. Vinod: Pensé que no habías entendido el concepto CRC. Ed: Un poco, quizá, pero continúa. Vinod: Aquí está mi definición de la clase InterfazdeAdministracióndelHogar. Atributos:
PaneldeOpciones: contiene información sobre los botones que permiten al usuario seleccionar funcionalidad. PaneldeSituación: contiene información acerca de los botones que permiten que el usuario seleccione la situación. Plano: igual que el objeto de vigilancia, pero éste muestra los equipos. ÍconosdeAparatos: informa sobre los íconos que representan luces, aparatos, calefacción y aire acondicionado, etcétera. PaneldeAparatos: simula el panel de control de un aparato o equipo; permite controlarlo.
Operaciones:
DesplegarControl( ), SeleccionarControl( ), DesplegarSituación( ), SeleccionarSituación( ), AccederaPlano( ), SeleccionarÍconodeEquipo( ), DesplegarPaneldeEquipo( ), AccederaPaneldeEquipo( ),... Clase: InterfazdeAdministracióndelHogar Responsabilidad
Colaborador
DesplegarControl( ) PaneldeOpciones (clase) SeleccionarControl( ) PaneldeOpciones (clase) DesplegarSituación( ) PaneldeSituación (clase) SeleccionarSituación( ) PaneldeSituación (clase) AccederaPlano( ) Plano (clase) . . . ... Ed: De modo que cuando se invoque a operación AccederaPlano( ), colabora con el objeto Plano de igual manera que el que desarrollamos para vigilancia. Espera, aquí tengo su descripción (ven la figura 6.10). Vinod: Exactamente. Y si quisiéramos revisar todo el modelo de la clase, podríamos comenzar con esta tarjeta índice, luego iríamos a la del colaborador y de ahí a una de los colaboradores del colaborador, y así sucesivamente. Ed: Buena forma de encontrar omisiones o errores. Vinod: Sí
CasaSegura Modelado del flujo de datos La escena: Cubículo
de Jamie, después de que terminó la última junta para recabar los requerimientos. Participantes: Jamie, Vinod y Ed, miembros del equipo de ingeniería de software de CasaSegura. La conversación:
(Jamie presenta a Ed y a Vinod los dibujos que hizo de los modelos que se muestran en las figuras 7.1 a 7.5.) Jamie: En la universidad tomé un curso de ingeniería de software y aprendí esto. El profesor dijo que es un poco anticuado, pero, saben, me ayuda a aclarar las cosas. Ed: Está muy bien. Pero no veo ninguna clase de objetos ahí. Jamie: No... Esto sólo es un modelo del flujo con un poco de comportamiento ilustrado. Vinod: Así que estos DFD representan la EP-S del software, ¿o no? Ed: ¿E-P-S? Vinod: Entrada-proceso-salida. En realidad, los DFD son muy intuitivos... si se observan un rato, indican cómo fluyen los objetos de datos por el sistema y cómo se transforman mientras lo hacen.
Ed: Parece
que pudiéramos convertir cada burbuja en un componente ejecutable... al menos en el nivel más bajo del DFD. Jamie: Ésa es la mejor parte, sí se puede. En realidad, hay una forma de traducir los DFD a una arquitectura de diseño. Ed: ¿En verdad? Jamie: Sí, pero primero tenemos que desarrollar un modelo completo de los requerimientos, y esto no lo es. Vinod: Bueno, es un primer paso, pero vamos a tener que enfrentar los elementos basados en clases y también los aspectos de comportamiento, aunque el diagrama de estado y la TAP hacen algo de eso. Ed: Tenemos mucho trabajo por hacer y poco tiempo. (Entra al cubículo Doug, el gerente de ingeniería de software.) Doug: Así que dedicaremos los siguientes días a desarrollar el modelo de los requerimientos, ¿eh? Jamie (con orgullo): Ya comenzamos. Doug: Qué bueno, tenemos mucho trabajo por hacer y poco tiempo. (Los tres ingenieros de software se miran entre sí y sonríen.)
CasaSegura Diseño versus codificación La escena: El
cubículo de Jamie, cuando el equipo se prepara para traducir a diseño los requerimientos. Participantes: Jamie, Vinod y Ed, miembros del equipo de ingeniería de software para CasaSegura. La conversación: Jamie: Ustedes
saben, Doug [el gerente del equipo] está obsesiona- do con el diseño. Tengo que ser honesto, lo que realmente amo es codificar. Denme C++ o Java y soy feliz. Ed: No… te gusta diseñar. Jamie: No me estás escuchando;
codificar
es lo mío. Vinod: Creo que Ed quiere decir que en realidad no es codificar lo que te gusta; te gusta diseñar y expresarlo en código. El código es el lenguaje que usas para representar el diseño. Jamie: ¿Y qué tiene de malo? Vinod: El nivel de abstracción.
Jamie: ¿Qué? Ed: Un lenguaje
de programación es bueno para representar detalles tales como estructuras de datos y algoritmos, pero no es tan bueno para representar la arquitectura o la colaboración entre componentes… algo así. Vinod: Y una arquitectura complicada arruina al mejor código. Jamie (piensa unos momentos): Entonces, dicen que no puede representarse la arquitectura con código... eso no es cierto. Vinod: Claro que es posible implicar la arquitectura con el código, pero en la mayor parte de lenguajes de programación, es muy difícil lograr un panorama rápido y amplio de la arquitectura con el análisis del código. Ed: Y eso es lo que queremos hacer antes de empezar a codificar. Jamie: Está bien, tal vez diseñar y codificar sean cosas distintas, pero aun así me gusta más codificar.
CasaSegura Conceptos de diseño La escena:
Cubículo de Vinod, cuando comienza el modelado del diseño. Participantes: Vinod, Jamie y Ed, miembros del equipo de ingeniería del software de CasaSegura. También Shakira, nueva integrante del equipo.
habló… ésa es la razón por la que funcionan
La conversación:
siempre que se pueda… esa clase de cosas. Ed: Modularidad, independencia funcional, ocultamiento, patrones… ya veo. Jamie: Todavía recuerdo el primer curso de programación que tomé… nos ens eñaron
[Los cuatro miembros del equipo acaban de regresar de un seminario matutino llamado ―Aplicación de los conceptos básicos del diseño‖, ofrecido por una profesora local de ciencias de la computación.] Vinod: ¿Les dejó algo el seminario? Ed: Sabíamos la mayor parte de lo que trató, pero creo que no fue mala idea escucharlo de nuevo. Jamie: Cuando estudiaba la carrera de ciencias de la computación, nunca entendí, en realidad, por qué era tan importante, como decían, ocultar información. Vinod: Por… la línea de base… es u na técnica para reducir la propagación del error en un programa. En realidad, la independencia funcional hace lo mismo. Shakira: Yo no estudié una carrera de computación, así que mucho de lo que dijo el instructor fue nuevo para mí. Soy capaz de generar buen código y rápido. No veo por qué es tan importante todo eso. Jamie: He visto tu trabajo, Shak, y aplicas de manera natural mucho de lo que se
bien tus diseños y códigos. Shakira (sonríe): Bueno, siempre trato de realizar la partición del código, hacer que se aboque a una cosa, construir interfaces sencillas y restringidas, reutilizar código
a refinar el código en forma iterativa. Vinod: Lo mismo puede aplicarse al diseño, ya sabes. Vinod: Los únicos conceptos que no había
escuchado antes fueron los de ―aspectos‖ y ―rediseño‖. Shakira: Eso se utiliza en programación
extrema. Ed: Sí. No es muy diferente del refinamiento, sólo que lo haces una vez terminado el diseño o código. Si me preguntan, diré que es algo así como una etapa de optimización del software. Jamie: Volvamos al diseño de CasaSegura. Pienso que mientras desarrollemos el modelo de su diseño, debemos poner estos conceptos en nuestra lista de revisión. Vinod: Estoy de acuerdo. Pero es importante que todos nos comprometamos a pensar en ellos al hacer el diseño.
CasaSegura Refinamiento de una clase de análisis en una clase de diseño La escena:
El cubículo de Ed, cuando comienza el modelado del diseño. Participantes: Vinod y Ed, miembros del equipo de ingeniería de software de CasaSegura. La conversación:
[Ed
está
trabajando en la clase PlanodelaPlanta (véanse el recuadro en la sección 6.5.3 y la figura 6.10) y la ha refinado para el modelo del diseño.] Ed: Entonces recuerdas la clase PlanodelaPlanta, ¿verdad? Se usa como parte de las funciones de vigilancia y administración de la casa. Vinod (afirma con la cabeza): Sí, recuerdo que la usamos como parte de nuestros análisis CRC para la administración de la casa. Ed: Así es. De cualquier modo, la estoy mejorando para el diseño. Quiero mostrarte cómo implantaremos en realidad la clase PlanodelaPlanta. Mi idea es implementarla como un conjunto de listas ligadas [una estructura de datos específica] de modo que… tuve que refinar la clase de análisis PlanodelaPlanta (véase
la figura 6.10) y, en verdad, simplificarla.
Vinod: La
clase de análisis sólo mostraba cosas en el dominio del problema, bueno, en la pantalla de la computadora, visibles para el usuario final, ¿de acuerdo? Ed: Sí, pero para la clase de diseño PlanodelaPlanta, he tenido que agregar algunas cosas específicas para la implantación. Necesité mostrar que PlanodelaPlanta es un agregado de segmentos —de ahí la clase Segmento— y que la clase Segmento está compuesta de listas para segmentos de pared, ventanas, puertas, etc. La clase Cámara colabora con PlanodelaPlanta y, obviamente, hay muchas cámaras en el piso. Vinod: Ah… veamos la ilustración de esta nueva clase de diseño, PlanodelaPlanta.
[Ed muestra a Vinod el diagrama que aparece en la figura 8.3.] Vinod: Bien, ya veo lo que tratas de hacer. Esto te permite modificar el plano de la planta con facilidad porque los nuevos temas se agregan, o eliminan de la lista (el agregado), sin problemas. Ed (asiente): Sí, creo que funcionará. Vinod: También yo.
CasaSegura Elección de un estilo de arquitectura La escena:
Cubículo de Jamie, cuando comienza la modelación del diseño. Participantes: Jamie y Ed, miembros del equipo de ingeniería de software de CasaSegura. La conversación: Ed (frunce el ceño):
Hemos estado modelando la función de seguridad con el empleo de UML, ya sabes, clases, relaciones y demás. Así que supongo que la arquitectura orientada a objeto3 es la elección apropiada. Jamie: ¿Pero…? Ed: Pero… tengo problemas para vis ualizar
lo que es una arquitectura orientada a objeto. Entiendo la arquitectura de llamar y regresar, que es algo así como una jerarquía de proceso convencional, pero la orientada a objeto… no sé, parece algo
amorfo.
Jamie (sonríe): Amorfo, ¿eh?
Ed: Sí… lo que quiero decir es que no
visualizo una estructura real, sólo clases de diseño que flotan en el espacio. Jamie: Bueno, eso no es cierto. Hay jerarquías de clase… piensa en la jerarquía (agregado) que hicimos para el objeto Plano [figura 8.3]. Una arquitectura orientada a objetos es una combinación de esta estructura y de las interconexiones — ya sabes, colaboraciones— entre las clases. Puede mostrarse con la descripción completa de los atributos y operaciones, los mensajes que hay y la estructura de las clases. Ed: Voy a dedicar una hora a mapear una arquitectura de llamar y regresar; luego volveré a considerar la orientada a objeto. Jamie: Doug no tendrá problemas con eso. Dijo que deben considerarse alternativas arquitectónicas. Por cierto, no hay ninguna razón para no usar estas arquitecturas combinadas entre sí. Ed: Bueno. Estoy en eso.
CasaSegura Evaluación de la arquitectura La escena: Oficina
de Doug Miller, cuando avanza la modelación del diseño arquitectónico. Participantes: Vinod, Jamie y Ed, miembros del equipo de ingeniería de software de CasaSegura, y Doug Miller, gerente del grupo de ingeniería de software. La conversación: Doug: Sé que están
desarrollando un par de diferentes arquitecturas para el producto CasaSegura, y eso es bueno. Mi pregunta es, ¿cómo vamos a elegir la mejor? Ed: Estoy trabajando en un estilo de llamada y regreso, luego alguno de los dos, Jamie o yo, derivará a una arquitectura OO. Doug: Muy bien. ¿Y cómo podemos elegir? Jamie: En mi último año de estudios de ciencias de la computación, tomé un curso de diseño y recuerdo que había varios modos de hacerlo. Vinod: Los hay, pero son algo académicos. Miren, pienso que podemos evaluarlos y escoger el correcto con el uso de casos y escenarios. Doug: ¿No es lo mismo? Vinod: No si hablas de evaluar la arquitectura. Ya tenemos un conjunto completo de casos de uso. Así que los aplicaremos a las dos arquitecturas y
veremos cómo reacciona cada sistema y cómo funcionan los componentes y conectores en el contexto del caso de uso. Ed: Buena idea. Nos aseguramos de no dejar nada fuera. Vinod: Es cierto, pero también nos dice si el diseño arquitectónico tiene rizos o si el sistema tiene que volver sobre sí mismo en un lazo para hacer el trabajo. Jamie: Los escenarios no sólo son otro nombre de los casos de uso. Vinod: No, en este caso, un escenario implica algo diferente. Doug: Hablas de un escenario de calidad o de un escenario de cambio, ¿verdad? Vinod: Sí. Lo que hacemos es regresar con los participantes y preguntarles cómo les gustaría que CasaSegura cambiara, digamos, en los próximos tres años. Ya sabes, nuevas versiones, características, esa clase de cosas. Construimos un conjunto de escenarios de cambio. También desarrollamos un conjunto de escenarios de calidad que defina los atributos que nos gustaría ver en la arquitectura del software. Jamie: Y los aplicamos a las alternativas. Vinod: Exacto. Elegiremos el estilo que mejor maneje los casos de uso y los escenarios.
CasaSegura Refinación de la arquitectura de primer corte La escena: El
cubículo de Jamie, cuando comienza la modelación del diseño. Participantes: Jamie y Ed, miembros del equipo de ingeniería de software de CasaSegura. La conversación:
[Ed acaba de terminar el diseño de primer corte del subsistema de vigilancia de sensores. Se detiene para solicitar la opinión de Jamie.] Ed: Pues bien, aquí está la arquitectura que obtuve. [Ed muestra a Jamie la figura 9.16, y ella la estudia unos momentos.] Jamie: Está muy bien, pero creo que podemos hacer algo para que sea más sencilla… y mejor. Ed: ¿Cómo qué? Jamie: Bueno, ¿por qué usaste el componente controlador de sensores de entrada? Ed: Porque se necesita un controlador para el mapeo. Jamie: No en realidad. El controlador no hace gran cosa, ya que estamos manejando
una sola trayectoria de flujo para los datos de entrada. Puede eliminarse el controlador sin que pase nada. Ed: Puedo vivir con eso. Lo cambiaré y… Jamie (sonríe): Espera… También podemos
hacer la implosión de los componentes establecer condiciones de alarma y seleccionar número telefónico. El controlador de la transformación que presentas en realidad no es necesario y la poca disminución en la cohesión es tolerable. Ed: Simplificación, ¿eh? Jamie: Sí. Y al hacer refinamientos sería buena idea hacer la implosión de los componentes formatear pantalla y generar pantalla. El formateo de la pantalla para el panel de control es algo sencillo. Puede definirse un nuevo módulo llamado producir pantalla. Ed (dibuja): Entonces, ¿esto es lo que piensas que debemos hacer? [Muestra a Jamie la figura 9.17.] Jamie: Es un buen comienzo.
CasaSegura El PAC en acción
La escena: El cubículo de Vinod. Participantes: Vinod y Shakira,
miembros del equipo de ingeniería de software de CasaSegura. La conversación: Vinod: Me acaba
de llamar Doug [gerente del equipo]. Dice que mercadotecnia quiere agregar un nuevo sensor. Shakira (con sonrisa cómplice): No otra vez, por favor… Vinod: Sí… y no vas a creer con lo que salieron… Shakira: Sorpréndeme. Vinod (ríe): Lo llaman sensor de angustia
del perro. Shakira: ¿Qué dijiste? Vinod: Es para la gente que deja su mascota en departamentos o condominios o casas que están muy cerca una de otra. El perro comienza a ladrar, el vecino se enoja y se queja. Con este sensor, si el perro ladra durante, digamos, más de un minuto, el sensor hace sonar una alarma especial que llama al propietario a su teléfono móvil. Shakira: Bromeas, ¿verdad?
Vinod: No,
no. Doug quiere saber cuánto tiempo nos llevaría agregar eso a la función de seguridad. Shakira (piensa un momento): No mucho…
mira [muestra a Vinod la figura 10.4]. Hemos aislado las clases reales sensor atrás de la interfaz sensor. Cuando tengamos las especificaciones para el sensor perrito, será pan comido agregarlo. Lo único que tendré que hacer es crear un componente apropiado para él… mmm, una
clase. El componente Detector no cambiará en absoluto. Vinod: Entonces diré a Doug que no hay problema. Shakira: Conociendo a Doug, nos estará vigilando; yo no le daría el asunto del perrito hasta la siguiente entrega. Vinod: No está mal, pero podrías implantarlo ahora si él quisiera, ¿o no? Shakira: Sí, la forma en la que diseñamos la interfaz me permite hacerlo sin problemas. Vinod (piensa un momento): ¿Has oído hablar del Principio Abierto-Cerrado? Shakira (encoge los hombros): Nunca. Vinod (sonríe): No hay problema.
CasaSegura La cohesión en acción La escena: Cubículo de Jamie. Participantes: Jamie y Ed, miembros
del equipo de ingeniería de software que trabajan en la función de vigilancia. La conversación: Ed: Tengo un diseño
de primer corte del
componente cámara. Jamie: ¿Quieres revisarlo rápido? Ed: Sí… pero en realidad quisiera qu e
me dijeras algo. (Con señas, Jamie lo invita a que continúe.) Ed: Originalmente definimos cinco operaciones para cámara. Mira… DeterminarTipo( ) dice el tipo de cámara. CambiarUbicación( ) permite mover la
cámara por el plano de la casa. MostrarIdentificación( ) obtiene la identificación de la cámara y la muestra cerca de su ícono. MostrarVista( ) presenta el campo de visión de la cámara en forma gráfica. MostrarAcercamiento( ) muestra gráficamente la amplificación de la cámara. Ed: Las diseñé por separado y son operaciones muy simples. Por eso pensé que sería una buena idea combinar todas las operaciones de la pantalla en una sola que denominé MostrarCámara( ) y que mostrará la identificación, vista y acercamiento. ¿Cómo la ves? Jamie (hace una mueca): No estoy seguro de que sea una buena idea. Ed (frunce el ceño): ¿Por qué? Todas esas pequeñas operaciones pueden dar dolores de cabeza.
Jamie: El
problema de que las combinemos es que se pierde cohesión, ya sabes, la operación MostrarCámara( ) no tendrá un único objetivo. Ed (un poco exasperado): ¿Y qué? Todo este asunto requerirá menos de 100 líneas de código fuente, si acaso. Será más fácil de implantar… creo. Jamie: ¿Y qué pasa si decidimos cambiar la
forma en la que representamos el campo de visión? Ed: Sólo se pasa a la operación MostrarCámara( ) y se hace la modificación. Jamie: ¿Qué hay con los efectos colaterales? Ed: ¿Qué quieres decir? Jamie: Bueno, digamos que se hace el cambio, pero, sin darnos cuenta, se genera un problema al mostrar en la pantalla la identificación. Ed: No sería tan torpe. Jamie: Tal vez no, pero, ¿qué tal si alguien de apoyo tiene que hacer la modificación dentro de dos años? Tal vez no entenderá la operación tan bien como tú, y, ¿quién sabe?, podría ser torpe. Ed: Entonces, ¿estás en contra? Jamie: Tú eres el diseñador… es tu decisión… sólo asegúrate de que entiendes
las consecuencias de la poca cohesión. Ed (piensa un momento): Tal vez haga operaciones de pantalla separadas. Jamie: Buena decisión.
CasaSegura El acoplamiento en acción La escena: Cubículo de Shakira. Participantes: Vinod y Shakira, miembros
del equipo de software de CasaSegura, que trabajan en la función de seguridad. La conversación: Shakira: Tuve lo que considero una gran idea… entonces lo pensé un poco y me
pareció que no era tan buena. Al final la deseché, pero pensé en hacerla para ustedes. Vinod: Seguro. ¿Cuál es la idea? Shakira: Bueno, cada uno de los sensores reconoce una condición de alarma de algún tipo, ¿verdad? Vinod (sonríe): Por eso se llaman sensores, Shakira. Shakira (exasperada): Sarcasmo, Vinod, tienes que mejorar tus habilidades interpersonales. Vinod: ¿Decías? Shakira: Bien, de cualquier modo, me pregunté… por qué no crea r una operación dentro de cada objeto de sensor llamada HacerLlamada( ) que colaboraría directamente con el componente
SaleLlamada, bueno, con una interfaz hacia el componente SaleLlamada. Vinod (pensativo): Quieres decir, ¿eso en
vez de hacer que esa colaboración ocurra fuera de un componente como PaneldeControl o algún otro? Shakira: Sí… Pero entonces me dije que
eso significaba que cada objeto de sensor estaría conectado al componente SaleLlamada, y que eso querría decir que estaría acoplado de manera indirecta con el mundo exterior y… bueno, pensé que sólo
complicaría las cosas. Vinod: Estoy de acuerdo. En este caso, es mejor idea dejar que la interfaz del sensor pase información a PaneldeControl y que inicie la llamada de salida. Además, diferentes sensores tal vez darían como resultado números telefónicos distintos. Tú no querrías que el sensor guardara esa información, porque si cambiara… Shakira: No lo sentí bien. Vinod: La heurística del diseño para el
acoplamiento nos dice que no está bien. Shakira: Pues sí.
CasaSegura Violación de la regla dorada de la interfaz de usuario
Cubículo de Vinod, cuando comienza el diseño de la interfaz de usuario. Participantes: Vinod y Jamie, miembros del equipo de ingeniería de software de CasaSegura. La escena:
La conversación: Jamie: He estaba
pensando en la interfaz de la función de vigilancia. Vinod (sonríe): Es bueno pensar. Jamie: Creo que tal vez podamos simplificar algunas cosas. Vinod: ¿Qué quiere decir? Jamie: Bueno, que tal si eliminamos el plano de la casa. Es bueno, pero va a requerir mucho esfuerzo de desarrollo. En vez de eso, puede pedirse al usuario que especifique la cámara que quiere ver y que luego despliegue el video en una ventana. Vinod: ¿Cómo recordaría el propietario cuanta cámaras hay y dónde están? Jamie (algo irritado): Él es el propietario; debe saberlo. Vinod: ¿Y si no es así? Jamie: Debería.
Vinod: Eso no es lo que estaos discutiendo… ¿Qué pasa si se olvida? Jamie: Bueno, podríamos darle una lista de
cámaras y sus ubicaciones. Vinod: Es posible, pero, ¿pero por qué debería pedir una lista? Jamie: Bueno, damos la lista la pidan o no. Vinod: Eso está mejor. Al menos no tendrá no tendrá que recordar cosas que le podemos dar. Jamie (piensa uno instantes): Pero, ¿te gusta o no el plano de la casa? Vinod: Mmm. Jamie: ¿Cuál piensas que le agrade más a mercadotecnia? Vinod: Bromeas, verdad. Jamie: No. Vinod:
Mmm…
el
plano…
adoran
las product os…
características bonitas de los no les importas cual es el más fácil de elaborar. Jamie (suspira): Bien, quizás hagamos ambos prototipos. Vinod: Buena idea… así dejamos que el
cliente decida.
CasaSegura Casos de uso para el diseño de la interfaz de usuario La escena: Cubículo de Vinod, cuando sigue el
Caso de uso informal: quiero poder preparar
diseño de la interfaz de usuario. Participantes: Vinod y Jamie, miembros del equipo de ingeniería de software Casa Segura.
o editar la planilla del sistema en cualquier momento. Cuando prepara el sistema selecciona una función de administración. Esta pregunta si desea hacer una nueva sesión o editar una ya existente. Si selecciona una nueva, el sistema presenta una pantalla de dibujo que permite dibujar el plano de una casa en una cuadricula. Habrá iconos para, ventanas y puertas, de manera que sea fácil dibujarlas. Solo estiro los iconos a las longitudes apropiadas. El sistema mostrara las longitudes en pies o metros (puede elegir el sistema de medidas). Selecciono en una biblioteca sensores y cámaras, y las coloco en el plano de la casa. Etiquetando cada una o los sistemas lo hacen de manera automática. Puedo establecer los valores de los sensores y cámara desde menús apropiados. Si elijo editarlos, puedo mover sensores o cámaras, agregar otros nuevos o eliminar los ya existentes, editar los planos de la casa y editar los parámetros de sensores y cámaras. En todo caso espero que el sistema haga una comprobación y que me ayude evitar los errores. Vinod (después de leer el escenario): Bien, es probable que hayan algunos patrones de diseños útiles [véase el capítulo 12] o componentes reutilizables para las interfaces graficas de usuario para los programas de dibujo. Apuesto 50 dólares a que implementamos una parte o el total de la interfaz del administrador con el uso de ellos. Jamie: De acuerdo. Lo verificare.
La conversación: Jamie: vi a
nuestro contacto de mercadotecnia y le pedí que me escribiera un caso de uso para la interfaz de vigilancia. Vinod: ¿Desde el punto de vista de quién? Jamie: Del propietario, ¿de quién más? Vinod: También está el papel del administrador del sistema; aun si fuera del propietario, sería un punto de vista distinto. El ―administrador‖ prepara el sistema, lo configura, elige el plano, sitúa las cámaras… Jamie: Todo lo que perdí fue que
desempeñara del papel de una propietaria que quiere ver el video. Vinod: Está bien. Es uno de los comportamientos principales de la interfaz de la función de vigilancia. Pero también vamos a tener el comportamiento de administración del sistema. Jamie (irritado): Tienes razón. (Jamie sale para encontrarse con la persona de mercadotecnia. Regresa pocas horas después). Jamie: Tuve suerte, la encontré y trabajamos juntos en el caso de uso del administrador. Básicamente vamos a definir ―administración‖ como una función aplicable a
todas las demás de Casa Segura ahí está lo q estuvimos. (Jamie presenta el caso de uso informal a Vinod)
CasaSegura Revisión del diseño de la interfaz La escena: Oficina de Doug Miller. Participantes: Doug Miller (gerente del grupo de ingeniería de software CasaSegura) y Vinod Roman, miembro del equipo de ingeniería de software del producto de CasaSegura. La conversación: Doug: Vinod, ¿han
podido revisar tú y el equipo el prototipo de la interfaz del comercio electrónico de CasaSeguraAsegurada.com? Vinod: Si… todos lo vimos desde un punto de vista técnico, y tengo muchas observaciones. Se las envié ayer por correo electrónico a Sharon [gerente de equipo de webapp para la venta externa del sitio web de comercio electrónico de CasaSegura]. Doug: Tú y Sharon pueden reunirse y analizar eso… hazme un resumen de los aspectos importantes. Vinod: Sobre todo, han hecho un buen trabajo, nada grandioso, pero es una interfaz normal de comercio electrónico, estética aceptable, distribución razonable, atendieron todas las funciones importantes… Doug (sonríe contrito): ¿Pero? Vinod: Bueno hay algunas cosas… Doug: Cómo… Vinod (presenta a Doug una secuencia de esquema de prototipos de interfaz): Aquí
está el menú de funciones principales que aparecen en la página de inicio. Aprenda sobre CasaSegura. Describa su casa. Recomendaciones sobre componentes de CasaSegura.
Compre un sistema de CasaSegura. Obtenga ayuda técnica.
El problema no está en estas funciones. Está bien pero el nivel de abstracción no es el correcto. Doug: Todas las funciones principales, o ¿no? Vinod: Lo son, pero ahí hay algo... puedes comprar un sistema sin introducir una lista de componentes, no hay una necesidad real de describir la casa si no quieres hacerlo. Sugiero que solo haya 4 opciones de menú en la página de inicio. Aprenda sobre CasaSegura Especifique el sistema de CasaSegura que necesite. Compre un sistema de CasaSegura Obtén ayuda técnica. Cuando se seleccione Especifique el sistema de CasaSegura que necesite entonces se
tendrán las siguientes opciones: Seleccione los componentes de CasaSegura. Recomendaciones sobre los componentes de CasaSegura.
Si eres u usuario conocedor, seleccionarás los componentes de un conjunto de menús desplegables clasificados en sensores, cámaras, paneles de control, etc. Si necesitaras ayuda, solicitaras una recomendación y eso requeriría que describas tu casa. Creo que es un poco más lógico. Doug: Estoy de acuerdo. ¿Has hablado con Sharon de esto? Vinod: No, primero quiero analizar esto con la gente de mercadotecnia; después la llamare.
CasaSegura Aplicación de patrones
Plática informal durante el diseño de un incremento de software que implementa el control de sensores por internet para CasaSeguraAsegurada.com Participantes: Jamie (responsable de diseño) y Vinod (arquitecto jefe del sistema de CasaSeguraAsegurda.com). La escena:
La conversación: Vinod: Entonces,
¿Cómo va el diseño de la interfaz de control de la cámara? Jamie: No va mal. Ya diseñe la mayoría de las capacidades para conectarla a los sensores reales sin demasiados problemas. También comencé a pensar acerca de la interfaz para que los usuarios en verdad muevan, abran y acerquen las cámaras desde una página web remota, pero no estoy seguro de haber terminado ya. Vinod: ¿Qué es lo que tienes? Jamie: Bueno, los requerimientos son el control de la cámara sea muy interactivo: cuando el usuario mueva el control, la cámara debe moverse tan pronto como sea posible. Entonces, pensaba en disponer varios botones, como en una cámara normal, para que cuando el usuario controle la cámara haga clic en ellos. Vinod: Mmm. Sí, eso funcionaria, pero no estoy seguro de que este bien: cada vez que se haga clic con el control, se necesitara esperar para que ocurra toda la comunicación entre cliente y servidor, por lo que no habrá una buena percepción de retroalimentación rápida. Jamie: Eso es lo que he pensado y para ello
no estoy muy conforme con el enfoque, pero no estoy seguro de que mas hacer. Vinod: Bueno, ¿por qué no usar el patrón ControldeDispositivoInteractivo? Jamie: Mmm. ¿Qué es eso? Nunca
oído.
lo he
Básicamente es un patrón para el problema exacto que describes. La solución que propone es crear una conexión de control entre el servidor y el dispositivo, a través del cual pueden enviarse los comandos de control. De esa forma, no necesitas mandar solicitudes HTTP normales. El patrón incluso muestra cómo puedes implementar con el uso de algunas técnicas AJAX sencillas. En el lado del cliente tenemos algunos scripts de Java que se comunican directamente con el servidor y que envían los comandos tan pronto como el usuario esta sin hacer nada. Vinod:
Jamie: Genial… eso es justo lo que necesito
para resolver el problema. ¿Dónde lo encuentro? Vinod: Está disponible en un repositorio en línea. Esta es la URL. Jamie: Iré a revisarlo. Vinod: Si, pero recuerda revisar el campo de consecuencias para el patrón. Creo recordar que había algo acerca de tener cuidado con ciertos aspectos de seguridad. Pienso que es porque se crea un canal de control se parado y de ese modo se evaden los mecanismos normales de seguridad web. Jamie: Buena observación. Es probable que no se me hubiera ocurrido… Gracias.
