Ingenieria Del Software. Un Enfoque Practico - Roger Pressman 7th.ed

el un

15 El nombre “cristal” se deriva de los cristales de minerales, cada uno de los cuales tiene propiedades específicas de color, forma y dureza.

03Pressman(055-080).indd 72

14/1/10 13:41:13

C AP Í T UL O 3

73

DESARROLLO ÁG IL

FIGURA 3.5 Desarrollo impulsado por las características [Coa99] (con permiso)

Elaborar una lista de características

Desarrollar un modelo general

(más forma que contenido)

Lista de características agrupadas en conjuntos y áreas temáticas

Plan según características

Plan de desarrollo Propietarios de clase Propietarios de conjuntos de características

Diseño según características

Construir según características

Paquete de diseño (secuencias)

Función terminada con valor para el cliente

donde es “una persona, lugar o cosa (incluso roles, momentos del tiempo o intervalos temporales, o descripciones parecidas a las entradas de un catálogo)”. Algunos ejemplos de características para una aplicación de comercio electrónico son los siguientes: Agregar el producto al carrito de compras Mostrar las especificaciones técnicas del producto Guardar la información de envío para el cliente Un conjunto de características agrupa las que son similares en categorías relacionadas con el negocio y se define así: un Por ejemplo: Haciendo una venta del producto es un conjunto de características que agruparía las que ya se mencionaron y otras más. El enfoque DIC define cinco actividades estructurales “colaborativas” [Coa99] (en el enfoque DIC se llaman “procesos”), como se muestra en la figura 3.5. El DIC pone más énfasis que otros métodos ágiles en los lineamientos y técnicas para la administración de proyectos. A medida que éstos aumentan su tamaño y complejidad, no es raro que la administración de proyectos ad hoc sea inadecuada. Para los desarrolladores, sus gerentes y otros participantes, es esencial entender el estado del proyecto, es decir, los avances realizados y los problemas que han surgido. Si la presión por cumplir el plazo de entrega es mucha, tiene importancia crítica determinar si la entrega de los incrementos del software está programada en forma adecuada. Para lograr esto, el DIC define seis puntos de referencia durante el diseño e implementación de una característica: “recorrido por el diseño, diseño, inspección del diseño, código, inspección del código, decisión de construir” [Coa99].

3.5.6

Desarrollo esbelto de software (DES)

El desarrollo esbelto de software (DES) adapta los principios de la manufactura esbelta al mundo de la ingeniería de software. Los principios de esbeltez que inspiran al proceso DES se resumen como sigue ([Pop03], [Pop06a]): eliminar el desperdicio, generar calidad, crear conocimiento, aplazar el compromiso, entregar rápido, respetar a las personas y optimizar al todo. Es posible adaptar cada uno de estos principios al proceso del software. Por ejemplo, eliminar el desperdicio en el contexto de un proyecto de software ágil significa [Das05]: 1) no agregar características o funciones extrañas, 2) evaluar el costo y el efecto que tendrá en la programación de actividades cualquier nuevo requerimiento solicitado, 3) eliminar cualesquiera etapas superfluas del proceso, 4) establecer mecanismos para mejorar la forma en la que los miembros


14/1/10 13:41:13

74

PAR T E UN O

E L PR OCESO DEL SOFT WARE

del equipo obtienen información, 5) asegurar que las pruebas detecten tantos errores como sea posible, 6) reducir el tiempo requerido para pedir y obtener una decisión que afecta al software o al proceso que se aplica para crearlo, y 7) simplificar la manera en la que se transmite la información a todos los participantes involucrados en el proceso. Para un análisis detallado del DES y para conocer lineamientos prácticos a fin de implementar el proceso, debe consultarse [Pop06a] y [Pop06b].

3.5.7 WebRef En la dirección www. agilemodeling.com hay información amplia sobre el modelado ágil.

Modelado ágil (MA)

Hay muchas situaciones en las que los ingenieros de software deben construir sistemas grandes de importancia crítica para el negocio. El alcance y complejidad de tales sistemas debe modelarse de modo que: 1) todos los actores entiendan mejor cuáles son las necesidades que deben satisfacerse, 2) el problema pueda dividirse con eficacia entre las personas que deben resolverlo, y 3) se asegure la calidad a medida que se hace la ingeniería y se construye el sistema. En los últimos 30 años se ha propuesto una gran variedad de métodos de modelado y notación para la ingeniería de software con objeto de hacer el análisis y el diseño (tanto en la arquitectura como en los componentes). Estos métodos tienen su mérito, pero se ha demostrado que son difíciles de aplicar y sostener (en muchos proyectos). Parte del problema es el “peso” de dichos métodos de modelación. Con esto se hace referencia al volumen de la notación que se requiere, al grado de formalismo sugerido, al tamaño absoluto de los modelos para proyectos grandes y a la dificultad de mantener el(los) modelo(s) conforme suceden los cambios. Sin embargo, el análisis y el modelado del diseño tienen muchos beneficios para los proyectos grandes, aunque no fuera más que porque hacen a esos proyectos intelectualmente más manejables. ¿Hay algún enfoque ágil para el modelado de la ingeniería de software que brinde una alternativa? En el “sitio oficial de modelado ágil”, Scott Ambler [Amb02a] describe el modelado ágil (MA)

Cita: “El otro día fui a la farmacia por una medicina para el resfriado… no fue fácil. Había toda una pared cubierta de productos. Al recorrerla vi uno que era de acción rápida, pero otro que era de larga duración… ¿Qué es más importante, el presente o el futuro?” Jerry Seinfeld

del modo siguiente: El modelado ágil (MA) es una metodología basada en la práctica para modelar y documentar con eficacia los sistemas basados en software. En pocas palabras, es un conjunto de valores, principios y prácticas para hacer modelos de software aplicables de manera eficaz y ligera a un proyecto de desarrollo de software. Los modelos ágiles son más eficaces que los tradicionales porque son sólo buenos, sin pretender ser perfectos.

El modelado ágil adopta todos los valores del manifiesto ágil. La filosofía de modelado ágil afirma que un equipo ágil debe tener la valentía para tomar decisiones que impliquen rechazar un diseño y reconstruirlo. El equipo también debe tener la humildad de reconocer que los tecnólogos no tienen todas las respuestas y que los expertos en el negocio y otros participantes deben ser respetados e incluidos. Aunque el MA sugiere una amplia variedad de principios de modelado “fundamentales” y “suplementarios”, aquellos que son exclusivos del MA son los siguientes [Amb02a]: Modelo con un propósito.

Un desarrollador que use el MA debe tener en mente una

meta específica (por ejemplo, comunicar información al cliente o ayudarlo a entender mejor algún aspecto del software) antes de crear el modelo. Una vez identificada la meta para el modelo, el tipo y nivel de detalle de la notación por usar serán más obvios. Uso de modelos múltiples.

Hay muchos modelos y notaciones diferentes que pueden

usarse para describir el software. Para la mayoría de proyectos sólo es esencial un pequeño subconjunto. El MA sugiere que para dar la perspectiva necesaria, cada modelo debe presentar un diferente aspecto del sistema y que sólo deben utilizarse aquellos modelos que den valor al público al que se dirigen.


14/1/10 13:41:14

C AP Í T UL O 3

CONSEJO

“Viajar ligero” es una filosofía apropiada para todo el trabajo de ingeniería de software. Construir sólo aquellos modelos que agreguen valor… ni más ni menos.

75

DESARROLLO ÁG IL

Viajar ligero.

Conforme avanza el trabajo de ingeniería de software, conserve sólo aque-

llos modelos que agreguen valor a largo plazo y elimine los demás. Todo producto del trabajo que se conserve debe recibir mantenimiento cuando haya cambios. Esto representa una labor que hace lento al equipo. Ambler [Amb02a] afirma que “cada vez que se decide conservar un modelo, se pierde agilidad en nombre de la conveniencia de tener disponible esa información en forma abstracta para el equipo (y de ese modo mejorar potencialmente la comunicación dentro del equipo, así como con los participantes)”. El contenido es más importante que la representación.

El modelado debe transmitir

información al público al que se dirige. Un modelo con sintaxis perfecta que transmita poco contenido útil no es tan valioso como otro que tenga notación defectuosa, pero que, no obstante, provea contenido de valor para los usuarios. Conocer los modelos y herramientas que se utilizan en su creación.

Entender las

fortalezas y debilidades de cada modelo y las herramientas que se emplean para crearlos. Adaptación local.

El enfoque de modelado debe adaptarse a las necesidades del equipo

ágil. Un segmento importante de la comunidad de ingeniería de software ha adoptado el lenguaje de unificado de modelado (UML, por sus siglas en inglés)16 como el método preferido para representar modelos del análisis y del diseño. El proceso unificado (véase el capítulo 2) fue desarrollado para proveer una estructura para la aplicación del UML. Scott Ambler [Amb06] desarrolló una versión simplificada del PU que integra su filosofía de modelado ágil.

3.5.8

El proceso unificado ágil (PUA)

El proceso unificado ágil (PUA) adopta una filosofía “en serie para lo grande” e “iterativa para lo pequeño” [Amb06] a fin de construir sistemas basados en computadora. Al adoptar las actividades en fase clásicas del PU —concepción, elaboración, construcción y transición—, el PUA brinda un revestimiento en serie (por ejemplo, una secuencia lineal de actividades de ingeniería de software) que permite que el equipo visualice el flujo general del proceso de un proyecto de software. Sin embargo, dentro de cada actividad, el equipo repite con objeto de alcanzar la agilidad y entregar tan rápido como sea posible incrementos de software significativos a los usuarios finales. Cada iteración del PUA aborda las actividades siguientes [Amb06]:

• Modelado. Se crean representaciones de UML de los dominios del negocio y el problema. No obstante, para conservar la agilidad, estos modelos deben ser “sólo suficientemente buenos” [Amb06] para permitir que el equipo avance.

• Implementación. Los modelos se traducen a código fuente. • Pruebas. Igual que con la XP, el equipo diseña y ejecuta una serie de pruebas para detectar errores y garantizar que el código fuente cumple sus requerimientos.

• Despliegue. Como en la actividad general del proceso que se estudió en los capítulos 1 y 2, el despliegue en este contexto se centra en la entrega de un incremento de software y en la obtención de retroalimentación de los usuarios finales.

• Configuración y administración del proyecto. En el contexto del PUA, la administración de la configuración (véase el capítulo 22) incluye la administración del cambio y el riesgo, y el control de cualesquiera productos del trabajo persistentes17 que produzca el equipo.

16 En el apéndice 1 se presenta un método breve para aprender UML. 17 Un producto del trabajo persistente es un modelo o documento o caso de prueba producido por el equipo y que se conservará durante un periodo indeterminado. No se eliminará una vez entregado el incremento de software.


14/1/10 13:41:14

76

PAR T E UN O


La administración del proyecto da seguimiento y controla el avance del equipo y coordina sus actividades.

• Administración del ambiente. La administración del ambiente coordina una infraestructura del proceso que incluye estándares, herramientas y otra tecnología de apoyo de la que dispone el equipo. Aunque el PUA tiene conexiones históricas y técnicas con el lenguaje unificado de modelado, es importante observar que el modelado UML puede usarse junto con cualesquiera de los modelos de proceso ágil descritos en la sección 3.5.

H ERRAMIENTAS Desarrollo ágil Objetivo: El objetivo de las herramientas de desarrollo ágil es ayudar en uno o más aspectos de éste, con énfasis en facilitar la elaboración rápida de software funcional. Estas herramientas también pueden emplearse cuando se aplican modelos de proceso prescriptivo (véase el capítulo 2). Mecánica: Las herramientas de mecánica varían. En general, las herramientas ágiles incluyen el apoyo automatizado para la planeación del proyecto, el desarrollo de casos y la obtención de requerimientos, el diseño rápido, la generación de código y la realización de pruebas.

DE SOFTWARE

car herramientas que lo apoyan. Las que se mencionan a continuación tienen características que las hacen particularmente útiles para los proyectos ágiles. OnTime, desarrollada por Axosoft (www.axosoft.com), presta apoyo a la administración de un proceso ágil para distintas actividades técnicas dentro del proceso. Ideogramic UML, desarrollada por Ideogramic (www.ideogramic. com), es un conjunto de herramientas UML desarrolladas específicamente para usarlas dentro de un proceso ágil. Together Tool Set, distribuido por Borland (www.borland.com), proporciona un grupo de herramientas para apoyar muchas actividades técnicas dentro de XP y otros procesos ágiles.

Herramientas representativas:18 Nota: Debido a que el desarrollo ágil es un tema de moda, la mayoría de los vendedores de herramientas de software tratan de colo-

3. 6 PU

CONJUNTO

DE HERRAMIENTAS PARA EL PROCESO ÁGIL

Algunos defensores de la filosofía ágil afirman que las herramientas automatizadas de software

NT

O

CLAVE

El “conjunto de herramientas” que da apoyo a los procesos ágiles se centra más en aspectos de la persona que en los de la tecnología.

(por ejemplo, las de diseño) deben verse como un complemento menor de las actividades del equipo, y no como algo fundamental para el éxito. Sin embargo, Alistair Cockburn [Coc04] sugiere que las herramientas tienen un beneficio y que “los equipos ágiles favorecen el uso de herramientas que permiten el flujo rápido de entendimiento. Algunas de estas herramientas son sociales y comienzan incluso en la etapa de reclutamiento. Otras son tecnológicas y ayudan a que los equipos distribuidos simulen su presencia física. Muchas herramientas son físicas y permiten que las personas las manipulen en talleres”. Prácticamente todos los modelos de proceso ágil son elementos clave en la contratación del personal adecuado (reclutamiento), la colaboración en equipo, la comunicación con los participantes y la administración indirecta; por eso, Cockburn afirma que las “herramientas” que se abocan a dichos aspectos son factores críticos para el éxito de la agilidad. Por ejemplo, una “herramienta” de reclutamiento tal vez sea el requerimiento de que un prospecto a miembro del equipo pase algunas horas programando en pareja con alguien que ya es integrante del equipo. El “ajuste” se evalúa de inmediato. Las “herramientas” de colaboración y comunicación por lo general son de baja tecnología e incorporan cualquier mecanismo (“proximidad física, pizarrones, tableros, tarjetas y notas ad-

18 Las herramientas mencionadas aquí no son obligatorias, sólo son una muestra en esta categoría. En la mayoría de casos, sus nombres son marcas registradas por sus respectivos desarrolladores.


14/1/10 13:41:14

C AP Í T UL O 3

DESARROLLO ÁG IL

77

heribles” [Coc04] que provea información y coordinación entre los desarrolladores ágiles. La comunicación activa se logra por medio de la dinámica del equipo (por ejemplo, la programación en parejas), mientras que la comunicación pasiva se consigue con “radiadores de información” (un tablero que muestre el estado general de de los distintos componentes de un incremento). Las herramientas de administración de proyectos no ponen el énfasis en la gráfica de Gantt y la sustituyen con otras de valor agregado o “gráficas de pruebas creadas versus pasadas; otras herramientas ágiles se utilizan para optimizar el ambiente en el que trabaja el equipo ágil (por ejemplo, áreas más eficientes para reunirse), mejoran la cultura del equipo por medio de cultivar las interacciones sociales (equipos con algo en común), dispositivos físicos (pizarrones electrónicos) y el mejoramiento del proceso (por ejemplo, la programación por parejas o la caja de tiempo)” [Coc04]. ¿Algunas de las mencionadas son en verdad herramientas? Sí, lo son, si facilitan el trabajo efectuado por un miembro del equipo ágil y mejoran la calidad del producto final.

3. 7

RESUMEN En una economía moderna, las condiciones del mercado cambian con rapidez, los clientes y usuarios finales necesitan evolucionar y surgen nuevas amenazas competitivas sin aviso previo. Los profesionales deben enfocar la ingeniería de software en forma que les permita mantenerse ágiles para definir procesos maniobrables, adaptativos y esbeltos que satisfagan las necesidades de los negocios modernos. Una filosofía ágil para la ingeniería de software pone el énfasis en cuatro aspectos clave: la importancia de los equipos con organización propia que tienen el control sobre el trabajo que realizan, la comunicación y colaboración entre los miembros del equipo y entre los profesionales y sus clientes, el reconocimiento de que el cambio representa una oportunidad y la insistencia en la entrega rápida de software que satisfaga al consumidor. Los modelos de proceso ágil han sido diseñados para abordar cada uno de estos aspectos. La programación extrema (XP) es el proceso ágil de más uso. Organizada con cuatro actividades estructurales: planeación, diseño, codificación y pruebas, la XP sugiere cierto número de técnicas innovadoras y poderosas que permiten a un equipo ágil generar entregas frecuentes de software que posee características y funcionalidad que han sido descritas y clasificadas según su prioridad por los participantes. Otros modelos de proceso ágil también insisten en la colaboración humana y en la organización propia del equipo, pero definen sus actividades estructurales y seleccionan diferentes puntos de importancia. Por ejemplo, el DAS utiliza un proceso iterativo que incluye un ciclo de planeación adaptativa, métodos relativamente rigurosos para recabar requerimientos, y un ciclo de desarrollo iterativo que incorpora grupos de consumidores y revisiones técnicas formales como mecanismos de retroalimentación en tiempo real. El Scrum pone el énfasis en el uso de un conjunto de patrones de software que han demostrado ser eficaces para proyectos que tienen plazos de entrega apretados, requerimientos cambiantes o que se emplean en negocios críticos. Cada patrón de proceso define un conjunto de tareas de desarrollo y permite al equipo Scrum construir un proceso que se adapte a las necesidades del proyecto. El método de desarrollo de sistemas dinámicos (MDSD) resalta el uso de la programación con caja de tiempo y sugiere que en cada incremento de software sólo se requiere el trabajo suficiente que facilite el paso al incremento que sigue. Cristal es una familia de modelos de proceso ágil que se adaptan a las características específicas del proyecto. El desarrollo impulsado por las características (DIC) es algo más “formal” que otros métodos ágiles, pero conserva su agilidad al centrar al equipo del proyecto en el desarrollo de características, funciones valiosas para el cliente que pueden implementarse en dos semanas o menos. El


14/1/10 13:41:14

78

PAR T E UN O


desarrollo esbelto de software (DES) ha adaptado los principios de la manufactura esbelta al mundo de la ingeniería de software. El modelado ágil (MA) sugiere que el modelado es esencial para todos los sistemas, pero que la complejidad, tipo y tamaño del modelo deben ajustarse al software que se va a elaborar. El proceso unificado ágil (PUA) adopta una filosofía “serial en lo grande” e “iterativo en lo pequeño” para la elaboración de software.

PROBLEMAS

Y PUNTOS POR EVALUAR

3.1. Vuelva a leer el “Manifiesto para el desarrollo ágil de software” al principio de este capítulo. ¿Puede pensar en una situación en la que uno o más de los cuatro “valores” pudieran causar problemas al equipo de software? 3.2. Describa con sus propias palabras la agilidad (para proyectos de software). 3.3. ¿Por qué un proceso iterativo hace más fácil administrar el cambio? ¿Es iterativo todo proceso ágil analizado en este capítulo? ¿Es posible terminar un proyecto en sólo una iteración y aún así conseguir que sea ágil? Explique sus respuestas. 3.4. ¿Podría describirse cada uno de los procesos ágiles con el uso de las actividades estructurales generales mencionadas en el capítulo 2? Construya una tabla que mapee las actividades generales en las actividades definidas para cada proceso ágil. 3.5. Proponga un “principio de agilidad” más que ayudaría al equipo de ingeniería de software a ser aún más maniobrable. 3.6. Seleccione un principio de agilidad mencionado en la sección 3.3.1 y trate de determinar si está incluido en cada uno de los modelos de proceso presentados en este capítulo. [Nota: sólo se presentó el panorama general de estos modelos de proceso, por lo que tal vez no fuera posible determinar si un principio está incluido en uno o más de ellos, a menos que el lector hiciera una investigación (lo que no se requiere para este problema)]. 3.7. ¿Por qué cambian tanto los requerimientos? Después de todo, ¿la gente no sabe lo que quiere? 3.8. La mayoría de modelos de proceso ágil recomiendan la comunicación cara a cara. No obstante, los miembros del equipo de software y sus clientes tal vez estén alejados geográficamente. ¿Piensa usted que esto implica que debe evitarse la separación geográfica? ¿Se le ocurren formas de resolver este problema? 3.9. Escriba una historia de usuario XP que describa la característica de “lugares favoritos” o “marcadores” disponible en la mayoría de navegadores web. 3.10. ¿Qué es una solución en punta en XP? 3.11. Describa con sus propias palabras los conceptos de rediseño y programación en parejas de XP. 3.12. Haga otras lecturas y describa lo que es una caja de tiempo. ¿Cómo ayuda a un equipo DAS para que entregue incrementos de software en un corto periodo? 3.13. ¿Se logra el mismo resultado con la regla de 80% del MDSD y con el enfoque de la caja de tiempo del DAS? 3.14. Con el formato de patrón de proceso presentado en el capítulo 2, desarrolle uno para cualquiera de los patrones Scrum presentados en la sección 3.5.2. 3.15. ¿Por qué se le llama a Cristal familia de métodos ágiles? 3.16. Con el formato de característica DIC descrito en la sección 3.5.5, defina un conjunto de características para un navegador web. Luego desarrolle un conjunto de características para el primer conjunto. 3.17. Visite el sitio oficial de modelación ágil y elabore la lista completa de todos los principios fundamentales y secundarios del MA. 3.18. El conjunto de herramientas propuestas en la sección 3.6 da apoyo a muchos de los aspectos “suaves” de los métodos ágiles. Debido a que la comunicación es tan importante, recomiende un conjunto de herramientas reales que podría utilizarse para que los participantes de un equipo ágil se comuniquen mejor.


14/1/10 13:41:15

C AP Í T UL O 3

DESARROLLO ÁG IL

LECTURAS

ADICIONALES Y FUENTES DE INFOR MACIÓN

79

La filosofía general y principios que subyacen al desarrollo de software ágil se estudian a profundidad en muchos de los libros mencionados a lo largo de este capítulo. Además, los textos de Shaw y Warden (The Art of Agile Development, O’Reilly Media, Inc., 2008), Hunt (Agile Software Construction, Springer, 2005) y Carmichael y Haywood (Better Software Faster, Prentice-Hall, 2002) presentan análisis útiles del tema. Aguanno (Managing Agile Projects, Multi-Media Publications, 2005), Highsmith (Agile Project Management: Creating Innovative Products, Addison-Wesley, 2004) y Larman (Agile and Iterative Development: A Manager’s Guide, Addison-Wesley, 2003) presentan el punto de vista de la administración y consideran ciertos aspectos de la administración de proyectos. Highsmith (Agile Software Development Ecosystems, Addison-Wesley, 2002) expone una encuesta acerca de los principios, procesos y prácticas ágiles. Booch y sus colegas (Balancing Agility and Discipline, Addison-Wesley, 2004) hacen un análisis fructífero del delicado equilibrio entre agilidad y disciplina. Martin (Clean Code: A Handbook of Agile Software Craftsmanship, Prentice-Hall, 2009) explica los principios, patrones y prácticas que se requieren para desarrollar “código limpio” en un ambiente de ingeniería de software ágil. Leffingwell (Scaling Software Agility: Best Practices for Large Enterprises, Addison-Wesley, 2007) estudia estrategias para ampliar las prácticas ágiles en proyectos grandes. Lippert y Rook (Refactoring in Large Software Projects: Performing Complex Restructurings Succesfully, Wiley, 2006) analizan el uso del rediseño cuando se aplica a sistemas grandes y complejos. Stamelos y Sfetsos (Agile Software Development Quality Assurance, IGI Global, 2007) analizan las técnicas SQA que forman la filosofía ágil. En la última década se han escrito decenas de libros sobre programación extrema. Beck (Extreme Programming Explained: Embrace Change, 2a. ed., Addison-Wesley, 2004) sigue siendo la referencia definitiva al respecto. Además, Jeffries y sus colegas (Extreme Programming Installed, Addison-Wesley, 2000), Succi y Marchesi (Extreme Programming Examined, Addison-Wesley, 2001), Newkirk y Martin (Extreme Programming in Practice, Addison-Wesley, 2001) y Auer y sus colegas (Extreme Programming Applied: Play to Win, AddisonWesley, 2001) hacen un análisis detallado de XP y dan una guía para aplicarla de la mejor forma. McBreen (Questioning Extreme Programming, Addison-Wesley, 2003) adopta un enfoque crítico sobre XP, y define cuándo y dónde es apropiada. Un estudio profundo de la programación por parejas se presenta en McBreen (Pair Programming Illuminated, Addison-Wesley, 2003). Highsmith [Hig00] analiza con detalle el DAS. Schwaber (The Enterprise and Scrum, Microsoft Press, 2007) estudia el empleo de Scrum para proyectos que tienen un efecto grande en los negocios. Los detalles de Scrum los estudian Schwaber y Beedle (Agile Software Development with SCRUM, Prentice-Hall, 2001). Algunos tratamientos útiles del MDSD han sido escritos por DSDM Consortium (DSDM: Business Focused Development, 2a. ed., Pearson Education, 2003) y Stapleton (DSDM: The Method in Practice, Addison-Wesley, 1997). Cockburn (Crystal Clear, Addison-Wesley, 2005) presenta un panorama excelente de la familia de procesos Cristal. Palmer y Felsing [Pal02] dan un tratamiento detallado del DIC. Carmichael y Haywood (Better Software Faster, Prentice-Hall, 2002) proporcionan otro análisis útil del DIC, que incluye un recorrido, paso a paso, por la mecánica del proceso. Poppendieck y Poppendieck (Lean Development: An Agile Toolkit for Software Development Managers, Addison-Wesley, 2003) dan lineamientos para la administración y el control de proyectos ágiles. Ambler y Jeffries (Agile Modeling, Wiley, 2002) estudian el MA con cierta profundidad. En internet existe una amplia variedad de fuentes de información sobre el desarrollo de software ágil. En el sitio web del libro hay una lista actualizada de referencias en la Red Mundial que son relevantes para el proceso ágil, en la dirección: www.mhhe.com/engcs/compsci/pressman/professional/olc/ser.htm.


14/1/10 13:41:15


14/1/10 13:41:15

PAR TE

Dos MODELADO

n esta parte de la obra, aprenderá sobre los principios, conceptos y métodos que se usan para crear requerimientos de alta calidad y para diseñar modelos. En los capítulos que siguen se abordan preguntas como las siguientes:

E

• ¿Qué conceptos y principios guían la práctica de la ingeniería de software? • ¿Qué son los requerimientos de ingeniería y cuáles son los conceptos subyacentes que llevan a un buen análisis de requerimientos? • ¿Cómo se crean los requerimientos del modelo y cuáles son sus elementos? • ¿Cuáles son los elementos de un buen diseño? • ¿Cómo establece el diseño de la arquitectura una estructura para todas las demás acciones de diseño y qué modelos se utilizan? • ¿Cómo se diseñan componentes de software de alta calidad? • ¿Qué conceptos, modelos y métodos se aplican al diseñar una interfaz de usuario? • ¿Qué es el diseño basado en patrones? • ¿Qué estrategias y métodos especializados se emplean para diseñar webapps? Una vez que se respondan estas preguntas, el lector estará mejor preparado para aplicar en la práctica la ingeniería de software.

81


26/1/10 17:31:55

CAPÍTULO

4 CONCEPTOS

PRINCIPIOS

QUE GUÍAN

LA PRÁCTICA

CLAVE

Principios fundamentales . . . . 83 Principios que gobiernan lo siguiente:

n un libro que explora las vidas y pensamientos de los ingenieros de software, Ellen Ull-

E

man [Ull97] ilustra una parte de su vida con el relato de lo que piensa un profesional del software cuando está bajo presión:

No tengo idea de la hora que es. En esta oficina no hay ventanas ni reloj, sólo la pantalla de un horno

codificación . . . . . . . . . . . . . 94

de microondas que parpadea su LED de color rojo: 12:00, 12:00, 12:00. Joel y yo hemos estado pro-

comunicación. . . . . . . . . . . . 86

gramando durante varios días. Tenemos una falla, endemoniada y testaruda. Así que nos sentimos

despliegue . . . . . . . . . . . . . 96

bien con el pulso rojo sin tiempo, como si fuera un pasmo de nuestros cerebros, de algún modo sin-

diseño . . . . . . . . . . . . . . . . 92

cronizados al mismo ritmo del parpadeo…

modelado . . . . . . . . . . . . . . 90 planeación . . . . . . . . . . . . . 88

¿En qué estamos trabajando? Los detalles se me escapan. Tal vez ayudamos a personas pobres y

pruebas . . . . . . . . . . . . . . . 95

enfermas o mejoramos un conjunto de rutinas de bajo nivel de un protocolo de base de datos distri-

requerimientos . . . . . . . . . . 91

buida, no me importa. Debería importarme; en otra parte de mi ser —más tarde, quizá cuando salga de este cuarto lleno de computadoras— me preocuparé mucho de por qué y para quién y con qué propósito estoy escribiendo software. Pero ahora, no. He cruzado una membrana tras la que el mundo real y sus asuntos ya no importan. Soy ingeniera de software.

La anterior es una imagen tenebrosa de la práctica de la ingeniería de software, pero si se detienen un poco a pensarlo, muchos de los lectores de este libro se verán reflejados en ella. Las personas que elaboran software de cómputo practican el arte, artesanía o disciplina1 conocida como ingeniería de software. Pero, ¿qué es la “práctica” de la ingeniería de software? En un sentido general, es un conjunto de conceptos, principios, métodos y herramientas a los que un ingeniero de software recurre en forma cotidiana. La práctica permite que los gerentes

UNA ¿Qué es? La práctica de la ingeniería de software es un conjunto amplio de principios, RÁPIDA conceptos, métodos y herramientas que deben considerarse al planear y desarrollar software. ¿Quién lo hace? Los profesionales (ingenieros de software) y sus gerentes realizan varias tareas de ingeniería de software. ¿Por qué es importante? El proceso de software proporciona a todos los involucrados en la creación de un sistema o producto basado en computadora un mapa para llegar con éxito al destino. La práctica proporciona los detalles que se necesitarán para circular por la carretera. Indica dónde se localizan los puentes, los caminos cerrados y las bifurcaciones. Ayuda a entender los conceptos y principios que deben entenderse y seguirse a fin de llegar con seguridad y rapidez. Enseña a manejar, dónde disminuir la velocidad y en qué lugares acelerar. En el contexto de la ingeniería de software, la práctica es lo que se hace día tras día conforme el software evoluciona de idea a realidad.

MIRADA

1

82


¿Cuáles son los pasos? Son tres los elementos de la práctica que se aplican sin importar el modelo de proceso que se elija. Se trata de: principios, conceptos y métodos. Un cuarto elemento de la práctica —las herramientas— da apoyo a la aplicación de los métodos. ¿Cuál es el producto final? La práctica incluye las actividades técnicas que generan todos los productos del trabajo definidos por el modelo del proceso de software que se haya escogido. ¿Cómo me aseguro de que lo hice bien? En primer lugar, hay que tener una comprensión sólida de los principios que se aplican al trabajo (por ejemplo, el diseño) en cuestión. Después, asegúrese de que se escogió el método apropiado para el trabajo, use herramientas automatizadas cuando sean adecuadas para la tarea y sea firme respecto de la necesidad de técnicas de aseguramiento de la calidad de los productos finales que se generen.

Algunos escritores afirman que cualquiera de estos términos excluye a los otros. En realidad, la ingeniería de software es las tres cosas.

26/1/10 17:31:56

C AP Í T UL O 4

83

PRINCIPIOS Q U E G U ÍAN LA PRÁCT ICA

administren proyectos de software y que los ingenieros de software elaboren programas de cómputo. La práctica da al modelo del proceso de software el saber técnico y administrativo para realizar el trabajo. La práctica transforma un enfoque caprichoso y disperso en algo más organizado, más eficaz y con mayor probabilidad de alcanzar el éxito. A lo largo de lo que resta del libro se estudiarán distintos aspectos de la práctica de la ingeniería de software. En este capítulo, la atención se pone en los principios y conceptos que la guían en lo general.

4. 1

CONOCIMIENTO

DE LA INGENIERÍA DE SOFTWARE

En un editorial publicado hace diez años en IEEE Software, Steve McConnell [McC99] hizo el siguiente comentario: Muchos trabajadores del software piensan que el conocimiento de la ingeniería de software casi exclusivamente consiste en tecnologías específicas: Java, Perl, html, C++, Linux, Windows NT, etc. Para programar computadoras es necesario conocer los detalles tecnológicos específicos. Si alguien pide al lector que escriba un programa en C++, tiene que saber algo sobre este lenguaje a fin de que el programa funcione. Es frecuente escuchar que el conocimiento del desarrollo de software tiene una vida media de tres años, lo que significa que la mitad de lo que es necesario saber hoy será obsoleto dentro de tres años. En el dominio del conocimiento relacionado con la tecnología es probable que eso se cumpla. Pero hay otra clase de conocimiento de desarrollo de software —algo que el autor considera como los “principios de la ingeniería de software”— que no tiene una vida media de tres años. Es factible que dichos principios sirvan al programador profesional durante toda su carrera.

McConnell continúa y plantea que el cuerpo de conocimientos de la ingeniería de software (alrededor del año 2000) ha evolucionado para convertirse en un “núcleo estable” que representa cerca de “75% del conocimiento necesario para desarrollar un sistema complejo”. Pero, ¿qué es lo que hay dentro de ese núcleo estable? Como dice McConnell, los principios fundamentales —ideas elementales que guían a los ingenieros de software en el trabajo que realizan— dan ahora un fundamento a partir del cual pueden aplicarse y evaluarse los modelos, métodos y herramientas de ingeniería.

4. 2

PRINCIPIOS

FUNDAMENTALES

La práctica de la ingeniería de software está guiada por un conjunto de principios fundamenta-

Cita: “En teoría no hay diferencia entre la teoría y la práctica. Pero en la práctica sí la hay.” Jan van de Snepscheut

les que ayudan en la aplicación del proceso de software significativo y en la ejecución de métodos eficaces de ingeniería de software. En el nivel del proceso, los principios fundamentales establecen un fundamento filosófico que guía al equipo de software cuando realiza actividades estructurales y actividades sombrilla, cuando navega por el flujo del proceso y elabora un conjunto de productos del trabajo de la ingeniería de software. En el nivel de la práctica, los principios fundamentales definen un conjunto de valores y reglas que sirven como guía cuando se analiza un problema, se diseña una solución, se implementa y prueba ésta y cuando, al final, se entrega el software a la comunidad de usuarios. En el capítulo 1 se identificó un conjunto de principios generales que amplían el proceso y práctica de la ingeniería de software: 1) agregar valor para los usuarios finales, 2) mantenerlo sencillo, 3) fijar la visión (del producto y el proyecto), 4) reconocer que otros consumen (y deben entender) lo que usted produce, 5) abrirse al futuro, 6) planear la reutilización y 7) ¡pensar! Aunque estos principios generales son importantes, se caracterizan en un nivel tan alto de abstracción que en ocasiones son difíciles de traducir en la práctica cotidiana de la ingeniería de


26/1/10 17:31:56

84

PAR T E DOS

MO D E LADO

software. En las subsecciones que siguen se analizan con más detalle los principios fundamentales que guían el proceso y la práctica.

4.2.1

Principios que guían el proceso

En la parte 1 de este libro se estudia la importancia del proceso de software y se describen los abundantes modelos de proceso que se han propuesto para hacer el trabajo de ingeniería de software. Sin que importe que un modelo sea lineal o iterativo, prescriptivo o ágil, puede caracterizarse con el empleo de la estructura general del proceso aplicable a todos los modelos de proceso. Los siguientes principios fundamentales se aplican a la estructura y, por extensión, a todo proceso de software: CONSEJO

Todo proyecto y equipo son únicos. Esto significa que debe adaptar el proceso para que se ajuste mejor a sus necesidades.

Principio 1. Ser ágil. Ya sea que el modelo de proceso que se elija sea prescriptivo o ágil, son los principios básicos del desarrollo ágil los que deben gobernar el enfoque. Todo aspecto del trabajo que se haga debe poner el énfasis en la economía de acción: en mantener el enfoque técnico tan sencillo como sea posible, hacer los productos del trabajo que se generan tan concisos como se pueda y tomar las decisiones localmente, siempre que sea posible. Principio 2. En cada etapa, centrarse en la calidad.

La condición de salida para toda

actividad, acción y tarea del proceso debe centrarse en la calidad del producto del trabajo que se ha generado. Principio 3. Estar listo para adaptar. El proceso no es una experiencia religiosa, en él no hay lugar para el dogma. Cuando sea necesario, adapte su enfoque a las restricciones impuestas por el problema, la gente y el proyecto en sí. Principio 4. Formar un equipo eficaz. El proceso y práctica de la ingeniería de software son importantes, pero el objetivo son las personas. Forme un equipo con organización propia en el que haya confianza y respeto mutuos. Principio 5. Establecer mecanismos para la comunicación y coordinación.

Los pro-

yectos fallan porque la información importante cae en las grietas o porque los participantes no coordinan sus esfuerzos para crear un producto final exitoso. Éstos son aspectos de la administración que deben enfrentarse. Principio 6. Administrar el cambio. El enfoque puede ser formal o informal, pero de-

Cita:

ben establecerse mecanismos para administrar la forma en la que los cambios se solicitan,

“La verdad es que siempre se sabe lo que es correcto hacer. La parte difícil es hacerlo.”

evalúan, aprueban e implementan.

General H. Norman Schwarzkopf

Principio 8. Crear productos del trabajo que agreguen valor para otros. Sólo genere

Principio 7. Evaluar el riesgo. Son muchas las cosas que pueden salir mal cuando se desarrolla software. Es esencial establecer planes de contingencia. aquellos productos del trabajo que agreguen valor para otras actividades, acciones o tareas del proceso. Todo producto del trabajo que se genere como parte de la práctica de ingeniería de software pasará a alguien más. La lista de las funciones y características requeridas se dará a la persona (o personas) que desarrollará(n) un diseño, el diseño pasará a quienes generan código y así sucesivamente. Asegúrese de que el producto del trabajo imparte la información necesaria sin ambigüedades u omisiones. La parte 4 de este libro se centra en aspectos de la administración del proyecto y del proceso, y analiza en detalle varios aspectos de cada uno de dichos principios.

4.2.2

Principios que guían la práctica

La práctica de la ingeniería de software tiene un solo objetivo general: entregar a tiempo software operativo de alta calidad que contenga funciones y características que satisfagan las ne-


26/1/10 17:31:57

C AP Í T UL O 4

85


cesidades de todos los participantes. Para lograrlo, debe adoptarse un conjunto de principios fundamentales que guíen el trabajo técnico. Estos principios tienen mérito sin que importen los métodos de análisis y diseño que se apliquen, ni las técnicas de construcción (por ejemplo, el lenguaje de programación o las herramientas automatizadas) que se usen o el enfoque de verificación y validación que se elija. Los siguientes principios fundamentales son vitales para la práctica de la ingeniería de software: PU

Principio 1. Divide y vencerás.

NT

O

CLAVE

Los problemas son más fáciles de resolver cuando se subdividen en entidades separadas, distintas entre sí, solucionables individualmente y verificables.

Dicho en forma más técnica, el análisis y el diseño siem-

pre deben enfatizar la separación de entidades (SdE). Un problema grande es más fácil de resolver si se divide en un conjunto de elementos (o entidades). Lo ideal es que cada entidad entregue funcionalidad distinta que pueda desarrollarse, y en ciertos casos validarse, independientemente de otras entidades. Principio 2. Entender el uso de la abstracción.

En su parte medular, una abstracción

es una simplificación de algún elemento complejo de un sistema usado para comunicar significado en una sola frase. Cuando se usa la abstracción hoja de cálculo, se supone que se comprende lo que es una hoja de cálculo, la estructura general de contenido que presenta y las funciones comunes que se aplican a ella. En la práctica de la ingeniería de software, se usan muchos niveles diferentes de abstracción, cada uno de los cuales imparte o implica significado que debe comunicarse. En el trabajo de análisis y diseño, un equipo de software normalmente comienza con modelos que representan niveles elevados de abstracción (por ejemplo, una hoja de cálculo) y poco a poco los refina en niveles más bajos de abstracción (como una columna o la función SUM). Joel Spolsky [Spo02] sugiere que “todas las abstracciones no triviales hasta cierto punto son esquivas”. El objetivo de una abstracción es eliminar la necesidad de comunicar detalles. Pero, en ocasiones, los efectos problemáticos precipitados por estos detalles se “filtran” por todas partes. Sin la comprensión de los detalles, no puede diagnosticarse con facilidad la causa de un problema. Principio 3. Buscar la coherencia.

Ya sea que se esté creando un modelo de los reque-

rimientos, se desarrolle un diseño de software, se genere código fuente o se elaboren casos de prueba, el principio de coherencia sugiere que un contexto familiar hace que el software sea más fácil de usar. Como ejemplo, considere el diseño de una interfaz de usuario para una webapp. La colocación consistente de opciones de menú, el uso de un esquema coherencia de color y el uso coherencia de íconos reconocibles ayudan a hacer que la interfaz sea muy buena en el aspecto ergonómico. Principio 4. Centrarse en la transferencia de información.

El software tiene que ver

con la transferencia de información: de una base de datos a un usuario final, de un sistema heredado a una webapp, de un usuario final a una interfaz gráfica de usuario (GUI, por sus siglas en inglés), de un sistema operativo a una aplicación, de un componente de software a otro… la lista es casi interminable. En todos los casos, la información fluye a través de una interfaz, y como consecuencia hay posibilidades de cometer errores, omisiones o ambigüedades. Este principio implica que debe ponerse atención especial al análisis, diseño, construcción y prueba de las interfaces. Principio 5. Construir software que tenga modularidad eficaz.

La separación de enti-

dades (principio 1) establece una filosofía para el software. La modularidad proporciona un mecanismo para llevar a cabo dicha filosofía. Cualquier sistema complejo puede dividirse en módulos (componentes), pero la buena práctica de la ingeniería de software demanda más. La modularidad debe ser eficaz. Es decir, cada módulo debe centrarse exclusivamente en un aspecto bien delimitado del sistema: debe ser cohesivo en su función o restringido en el contenido que representa. Además, los módulos deben estar interconectados en forma


26/1/10 17:31:57

86

PAR T E DOS

MO D E LADO

relativamente sencilla: cada módulo debe tener poco acoplamiento con otros módulos, fuentes de datos y otros aspectos ambientales. Principio 6. Buscar patrones. Brad Appleton [App00] sugiere que: CONSEJO

El objetivo de los patrones dentro de la comunidad de software es crear un cúmulo de bibliografía

Use patrones (véase el capítulo 12) a fin de acumular conocimiento y experiencia para las futuras generaciones de ingenieros de software.

que ayude a los desarrolladores de software a resolver problemas recurrentes que surgen a lo largo del desarrollo. Los patrones ayudan a crear un lenguaje compartido para comunicar perspectiva y experiencia acerca de dichos patrones y sus soluciones. La codificación formal de estas soluciones y sus relaciones permite acumular con éxito el cuerpo de conocimientos que define nuestra comprensión de las buenas arquitecturas que satisfacen las necesidades de sus usuarios.

Principio 7. Cuando sea posible, representar el problema y su solución desde varias perspectivas diferentes.

Cuando un problema y su solución se estudian desde varias

perspectivas distintas, es más probable que se tenga mayor visión y que se detecten los errores y omisiones. Por ejemplo, un modelo de requerimientos puede representarse con el empleo de un punto de vista orientado a los datos, a la función o al comportamiento (véanse los capítulos 6 y 7). Cada uno brinda un punto de vista diferente del problema y de sus requerimientos. Principio 8. Tener en mente que alguien dará mantenimiento al software.

El soft-

ware será corregido en el largo plazo, cuando se descubran sus defectos, se adapte a los cambios de su ambiente y se mejore en el momento en el que los participantes pidan más capacidades. Estas actividades de mantenimiento resultan más fáciles si se aplica una práctica sólida de ingeniería de software a lo largo del proceso de software. Estos principios no son todo lo que se necesita para elaborar software de alta calidad, pero establecen el fundamento para todos los métodos de ingeniería de software que se estudian en este libro.

4. 3

PRINCIPIOS

QUE GUÍAN TODA ACTIVIDAD ESTRUCTURAL

En las secciones que siguen se consideran los principios que tienen mucha relevancia para el

Cita: “El ingeniero ideal es una mezcla… no es un científico, no es un matemático, no es un sociólogo ni un escritor; pero para resolver problemas de ingeniería utiliza conocimiento y técnicas de algunas o de todas esas disciplinas.” N. W. Dougherty

éxito de cada actividad estructural genérica, definida como parte del proceso de software. En muchos casos, los principios que se estudian para cada una de las actividades estructurales son un refinamiento de los principios presentados en la sección 4.2. Tan sólo son principios fundamentales planteados en un nivel más bajo de abstracción.

4.3.1

Principios de comunicación

Antes de que los requerimientos del cliente se analicen, modelen o especifiquen, deben recabarse a través de la actividad de comunicación. Un cliente tiene un problema que parece abordable mediante una solución basada en computadora. Usted responde a la solicitud de ayuda del cliente. Ha comenzado la comunicación. Pero es frecuente que el camino que lleva de la comunicación a la comprensión esté lleno de agujeros. La comunicación efectiva (entre colegas técnicos, con el cliente y otros participantes, y con los gerentes de proyecto) se encuentra entre las actividades más difíciles que deben enfrentarse. En este contexto, aquí se estudian principios de comunicación aplicados a la comunicación con el cliente. Sin embargo, muchos de ellos se aplican por igual en todas las formas de comunicación que ocurren dentro de un proyecto de software. Principio 1. Escuchar. Trate de centrarse en las palabras del hablante en lugar de formular su respuesta a dichas palabras. Si algo no está claro, pregunte para aclararlo, pero evite las interrupciones constantes. Si una persona habla, nunca parezca usted beligerante en sus palabras o actos (por ejemplo, con giros de los ojos o movimientos de la cabeza).


26/1/10 17:31:57

C AP Í T UL O 4

Principio 2. Antes de comunicarse, prepararse.

CONSEJO

87


Dedique algún tiempo a entender el

problema antes de reunirse con otras personas. Si es necesario, haga algunas investigacio-

Antes de comunicarse, asegúrese de que entiende el punto de vista de la otra parte, conozca un poco sus necesidades y después escuche.

nes para entender el vocabulario propio del negocio. Si tiene la responsabilidad de conducir la reunión, prepare una agenda antes de que ésta tenga lugar. Principio 3. Alguien debe facilitar la actividad. Toda reunión de comunicación debe tener un líder (facilitador) que: 1) mantenga la conversación en movimiento hacia una dirección positiva, 2) sea un mediador en cualquier conflicto que ocurra y 3) garantice que se sigan otros principios. Principio 4. Es mejor la comunicación cara a cara. Pero por lo general funciona me-

Cita:

jor cuando está presente alguna otra representación de la información relevante. Por ejem-

“Las preguntas directas y las respuestas directas son el camino más corto hacia las mayores perplejidades.”

plo, un participante quizá genere un dibujo o documento en “borrador” que sirva como

Mark Twain

rio” y escribir todos los temas y decisiones importantes.

centro de la discusión. Principio 5. Tomar notas y documentar las decisiones. Las cosas encuentran el modo de caer en las grietas. Alguien que participe en la comunicación debe servir como “secretaPrincipio 6. Perseguir la colaboración. La colaboración y el consenso ocurren cuando el conocimiento colectivo de los miembros del equipo se utiliza para describir funciones o características del producto o sistema. Cada pequeña colaboración sirve para generar confianza entre los miembros del equipo y crea un objetivo común para el grupo. Principio 7. Permanecer centrado; hacer módulos con la discusión. Entre más personas participen en cualquier comunicación, más probable es que la conversación salte de un tema a otro. El facilitador debe formar módulos de conversación para abandonar un tema sólo después de que se haya resuelto (sin embargo, considere el principio 9). Principio 8. Si algo no está claro, hacer un dibujo. La comunicación verbal tiene sus límites. Con frecuencia, un esquema o dibujo arroja claridad cuando las palabras no bastan para hacer el trabajo.

?

¿Qué pasa si no puede llegarse a un acuerdo con el cliente en algún aspecto relacionado con el proyecto?

Principio 9. a) Una vez que se acuerde algo, avanzar. b) Si no es posible ponerse de acuerdo en algo, avanzar. c) Si una característica o función no está clara o no puede aclararse en el momento, avanzar.

La comunicación, como cualquier actividad

de ingeniería de software, requiere tiempo. En vez de hacer iteraciones sin fin, las personas que participan deben reconocer que hay muchos temas que requieren análisis (véase el principio 2) y que “avanzar” es a veces la mejor forma de tener agilidad en la comunicación. Principio 10. La negociación no es un concurso o un juego. Funciona mejor cuando las dos partes ganan.

Hay muchas circunstancias en las que usted y otros participantes

deben negociar funciones y características, prioridades y fechas de entrega. Si el equipo ha

I NFOR MACIÓN La diferencia entre los clientes y los usuarios finales Los ingenieros de software se comunican con muchos participantes diferentes, pero los clientes y los usuarios finales son quienes tienen el efecto más significativo en el trabajo técnico que se desarrollará. En ciertos casos, el cliente y el usuario final son la misma persona, pero para muchos proyectos son individuos distintos que trabajan para diferentes gerentes en distintas organizaciones de negocios. Un cliente es la persona o grupo que 1) solicitó originalmente que se construyera el software, 2) define los objetivos generales del negocio para el software, 3) proporciona los requerimientos básicos del


producto y 4) coordina la obtención de fondos para el proyecto. En un negocio de productos o sistema, es frecuente que el cliente sea el departamento de mercadotecnia. En un ambiente de tecnologías de la información (TI), el cliente tal vez sea un componente o departamento del negocio. Un usuario final es la persona o grupo que 1) usará en realidad el software que se elabore para lograr algún propósito del negocio y 2) definirá los detalles de operación del software de modo que se alcance el propósito del negocio.

26/1/10 17:31:58

88

PAR T E DOS

MO D E LADO

C ASA S EGURA Errores de comunicación La escena: Lugar de trabajo del equipo de ingeniería de software. Participantes: Jamie Lazar, Vinod Roman y Ed Robins, miembros del equipo de software. La conversación: Ed: ¿Qué has oído sobre el proyecto 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. Vinod: ¿Y…? Jamie: Yo quería que me dijera las características y funciones de CasaSegura… esa clase de cosas. En lugar de ello, comenzó a hacerme preguntas sobre sistemas de seguridad, de vigilancia… No soy experto en eso.

Vinod: ¿Qué te dice eso? (Jamie se encoge de hombros.) Vinod: Será que mercadotecnia quiere que actuemos como consultores y mejor que hagamos alguna tarea sobre esta área de productos antes de nuestra junta de arranque. Doug dijo que quería que “colaboráramos” con nuestro cliente, así 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 serán una batalla. Vinod: Yo vi a Doug leyendo un libro acerca de “requerimientos de ingeniería”. Apuesto a que enlista algunos principios de buena comunicación. Voy a pedírselo prestado. Jamie: Buena idea… luego nos enseñas. Vinod (sonríe): Sí, de acuerdo.

colaborado bien, todas las partes tendrán un objetivo común. Aun así, la negociación demandará el compromiso de todas las partes.

4.3.2

Principios de planeación

La actividad de comunicación ayuda a definir las metas y objetivos generales (por supuesto, sujetos al cambio conforme pasa el tiempo). Sin embargo, la comprensión de estas metas y objetivos no es lo mismo que definir un plan para lograrlo. La actividad de planeación incluye un conjunto de prácticas administrativas y técnicas que permiten que el equipo de software defina un mapa mientras avanza hacia su meta estratégica y sus objetivos tácticos. Créalo, es imposible predecir con exactitud cómo se desarrollará un proyecto de software. No

Cita: “Al prepararme para una batalla siempre descubro que los planes son inútiles, pero que la planeación es indispensable.” General Dwight D. Eisenhower

existe una forma fácil de determinar qué problemas técnicos se encontrarán, qué información importante permanecerá oculta hasta que el proyecto esté muy avanzado, qué malos entendidos habrá o qué aspectos del negocio cambiarán. No obstante, un buen equipo de software debe planear con este enfoque. Hay muchas filosofías de planeación.2 Algunas personas son “minimalistas” y afirman que es frecuente que el cambio elimine la necesidad de hacer un plan detallado. Otras son “tradicionalistas” y dicen que el plan da un mapa eficaz y que entre más detalles tenga menos probable será que el equipo se pierda. Otros más son “agilistas” y plantean que tal vez sea necesario un “juego de planeación” rápido, pero que el mapa surgirá a medida que comience el “trabajo real” con el

WebRef En la dirección www.4pm.com/ repository.htm, hay excelentes materiales informativos sobre la planeación y administración de proyectos.

software. ¿Qué hacer? En muchos proyectos, planear en exceso consume tiempo y es estéril (porque son demasiadas las cosas que cambian), pero planear poco es una receta para el caos. Igual que la mayoría de cosas de la vida, la planeación debe ser tomada con moderación, suficiente para que dé una guía útil al equipo, ni más ni menos. Sin importar el rigor con el que se haga la planeación, siempre se aplican los principios siguientes:

2


En la parte 4 de este libro hay un análisis detallado de la planeación y administración de proyectos de software.

26/1/10 17:31:58

C AP Í T UL O 4

89


Principio 1. Entender el alcance del proyecto.

Es imposible usar el mapa si no se sabe

a dónde se va. El alcance da un destino al equipo de software. Principio 2. Involucrar en la actividad de planeación a los participantes del software.

Los participantes definen las prioridades y establecen las restricciones del pro-

yecto. Para incluir estas realidades, es frecuente que los ingenieros de software deban negociar la orden de entrega, los plazos y otros asuntos relacionados con el proyecto. Principio 3. Reconocer que la planeación es iterativa.

Un plan para el proyecto nunca

está grabado en piedra. Para cuando el trabajo comience, es muy probable que las cosas hayan cambiado. En consecuencia, el plan deberá ajustarse para incluir dichos cambios. Además, los modelos de proceso iterativo incrementales dictan que debe repetirse la planeación después de la entrega de cada incremento de software, con base en la retroalimentación recibida de los usuarios. Principio 4. Estimar con base en lo que se sabe. El objetivo de la estimación es obte-

Cita:

ner un índice del esfuerzo, costo y duración de las tareas, con base en la comprensión que

“El éxito es más una función del sentido común coherente que del genio.”

tenga el equipo sobre el trabajo que va a realizar. Si la información es vaga o poco confia-

An Wang

que tendrían un efecto grande y es muy probable que ocurran, entonces es necesario ela-

ble, entonces las estimaciones tampoco serán confiables. Principio 5. Al definir el plan, tomar en cuenta los riesgos. Si ha identificado riesgos borar planes de contingencia. Además, el plan del proyecto (incluso la programación de actividades) deberá ajustarse para que incluya la posibilidad de que ocurran uno o más de dichos riesgos. Principio 6. Ser realista. Las personas no trabajan 100% todos los días. En cualquier comunicación humana hay ruido. Las omisiones y ambigüedad son fenómenos de la vida. Los cambios ocurren. Aun los mejores ingenieros de software cometen errores. Éstas y otras realidades deben considerarse al establecer un proyecto.

PU

Principio 7. Ajustar la granularidad cuando se defina el plan.

NT

O

La granularidad se re-

fiere al nivel de detalle que se adopta cuando se desarrolla un plan. Un plan con “mucha

CLAVE

granularidad” proporciona detalles significativos en las tareas para el trabajo que se planea,

El término granularidad se refiere al detalle con el que se representan o efectúan algunos elementos de la planeación.

en incrementos durante un periodo relativamente corto (por lo que el seguimiento y control suceden con frecuencia). Un plan con “poca granularidad” da tareas más amplias para el trabajo que se planea, para plazos más largos. En general, la granularidad va de poca a mucha conforme el tiempo avanza. En las siguientes semanas o meses, el proyecto se planea con detalles significativos. Las actividades que no ocurrirán en muchos meses no requieren mucha granularidad (hay demasiadas cosas que pueden cambiar). Principio 8. Definir cómo se trata de asegurar la calidad.

El plan debe identificar la

forma en la que el equipo de software busca asegurar la calidad. Si se realizan revisiones técnicas,3 deben programarse. Si durante la construcción va a utilizarse programación por parejas (véase el capítulo 3), debe definirse en forma explícita en el plan. Principio 9. Describir cómo se busca manejar el cambio. Aun la mejor planeación puede ser anulada por el cambio sin control. Debe identificarse la forma en la que van a recibirse los cambios a medida que avanza el trabajo de la ingeniería de software. Por ejemplo, ¿el cliente tiene la posibilidad de solicitar un cambio en cualquier momento? Si se solicita uno, ¿está obligado el equipo a implementarlo de inmediato? ¿Cómo se evalúan el efecto y el costo del cambio?

3


Las revisiones técnicas se estudian en el capítulo 15.

26/1/10 17:31:59

90

PAR T E DOS

MO D E LADO

Principio 10. Dar seguimiento al plan con frecuencia y hacer los ajustes que se requieran. Los proyectos de software se atrasan respecto de su programación. Por tanto, tiene sentido evaluar diariamente el avance, en busca de áreas y situaciones problemáticas en las que las actividades programadas no se apeguen al avance real. Cuando se detecten desviaciones, hay que ajustar el plan en consecuencia. Para ser más eficaz, cada integrante del equipo de software debe participar en la actividad de planeación. Sólo entonces sus miembros “firmarán” el plan.

4.3.3

Principios de modelado

Se crean modelos para entender mejor la entidad real que se va a construir. Cuando ésta es física (por ejemplo, un edificio, un avión, una máquina, etc.), se construye un modelo de forma idéntica pero a escala. Sin embargo, cuando la entidad que se va a construir es software, el modelo debe adoptar una forma distinta. Debe ser capaz de representar la información que el software transforma, la arquitectura y las funciones que permiten que esto ocurra, las características que desean los usuarios y el comportamiento del sistema mientras la transformación tiene lugar. Los modelos deben cumplir estos objetivos en diferentes niveles de abstracción, en primer lugar con la ilustración del software desde el punto de vista del cliente y después con su representación en un nivel más técnico. PU

En el trabajo de ingeniería de software se crean dos clases de modelos: de requerimientos y

NT

O

CLAVE

Los modelos de requerimientos representan los requerimientos del cliente. Los modelos del diseño dan una especificación concreta para la construcción del software.

de diseño. Los modelos de requerimientos (también conocidos como modelos de análisis) representan los requerimientos del cliente mediante la ilustración del software en tres dominios diferentes: el de la información, el funcional y el de comportamiento. Los modelos de diseño representan características del software que ayudan a los profesionales a elaborarlo con eficacia: arquitectura, interfaz de usuario y detalle en el nivel de componente. En su libro sobre modelado ágil, Scott Ambler y Ron Jeffries [Amb02b] definen un conjunto de principios de modelado4 dirigidos a todos aquellos que usan el modelo de proceso ágil (véase el capítulo 3), pero que son apropiados para todos los ingenieros de software que efectúan acciones y tareas de modelado: Principio 1. El equipo de software tiene como objetivo principal elaborar software, no crear modelos. Agilidad significa entregar software al cliente de la manera más rápida posible. Los modelos que contribuyan a esto son benéficos, pero deben evitarse aquellos que hagan lento el proceso o que den poca perspectiva. Principio 2. Viajar ligero, no crear más modelos de los necesarios. Todo modelo que se cree debe actualizarse si ocurren cambios. Más importante aún es que todo modelo nuevo exige tiempo, que de otra manera se destinaría a la construcción (codificación y pruebas). Entonces, cree sólo aquellos modelos que hagan más fácil y rápido construir el software. Principio 3. Tratar de producir el modelo más sencillo que describa al problema o

CONSEJO

al software.

El objetivo de cualquier modelo es comunicar información. Para lograr esto, use un formato consistente. Suponga que usted no estará para explicar el modelo. Por eso, el modelo debe describirse por sí solo.

No construya software en demasía [Amb02b]. Al mantener sencillos los mo-

delos, el software resultante también lo será. El resultado es que se tendrá un software fácil de integrar, de probar y de mantener (para que cambie). Además, los modelos sencillos son más fáciles de entender y criticar por parte de los miembros del equipo, lo que da como resultado un formato funcional de retroalimentación que optimiza el resultado final. Principio 4. Construir modelos susceptibles al cambio. Suponga que sus modelos cambiarán, pero vigile que esta suposición no lo haga descuidado. Por ejemplo, como los

4


Para fines de este libro, se han abreviado y reescrito los principios mencionados en esta sección.

26/1/10 17:31:59

C AP Í T UL O 4

91


requerimientos se modificarán, hay una tendencia a ignorar los modelos. ¿Por qué? Porque se sabe que de todos modos cambiarán. El problema con esta actitud es que sin un modelo razonablemente completo de los requerimientos, se creará un diseño (modelo de diseño) que de manera invariable carecerá de funciones y características importantes. Principio 5. Ser capaz de enunciar un propósito explícito para cada modelo que se cree. Cada vez que cree un modelo, pregúntese por qué lo hace. Si no encuentra una razón sólida para la existencia del modelo, no pierda tiempo en él. Principio 6. Adaptar los modelos que se desarrollan al sistema en cuestión.

Tal vez

sea necesario adaptar a la aplicación la notación del modelo o las reglas; por ejemplo, una aplicación de juego de video quizá requiera una técnica de modelado distinta que el software incrustado que controla el motor de un automóvil en tiempo real. Principio 7. Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos.

Cuando un ingeniero de software construye modelos de requerimientos y di-

seño, alcanza un punto de rendimientos decrecientes. Es decir, el esfuerzo requerido para terminar por completo el modelo y hacerlo internamente consistente deja de beneficiarse por tener dichas propiedades. ¿Se sugiere que el modelado debe ser pobre o de baja calidad? La respuesta es “no”. Pero el modelado debe hacerse con la mirada puesta en las siguientes etapas de la ingeniería de software. Las iteraciones sin fin para obtener un modelo “perfecto” no cumplen la necesidad de agilidad. Principio 8. No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para comunicar contenido, la representación es secundaria.

Aunque cada miembro

del equipo de software debe tratar de usar una notación consistente durante el modelado, la característica más importante del modelo es comunicar información que permita la realización de la siguiente tarea de ingeniería. Si un modelo tiene éxito en hacer esto, es perdonable la sintaxis incorrecta. Principio 9. Si su instinto dice que un modelo no es el correcto a pesar de que se vea bien en el papel, hay razones para estar preocupado. Si usted es un ingeniero de software experimentado, confíe en su instinto. El trabajo de software enseña muchas lecciones, algunas en el nivel del inconsciente. Si algo le dice que un modelo de diseño está destinado a fracasar (aun cuando esto no pueda demostrarse en forma explícita), hay razones para dedicar más tiempo a su estudio o a desarrollar otro distinto. Principio 10. Obtener retroalimentación tan pronto como sea posible.

Todo modelo

debe ser revisado por los miembros del equipo. El objetivo de estas revisiones es obtener retroalimentación para utilizarla a fin de corregir los errores de modelado, cambiar las interpretaciones equivocadas y agregar las características o funciones omitidas inadvertidamente. Requerimientos de los principios de modelado.

En las últimas tres décadas se han desa-

rrollado numerosos métodos de modelado de requerimientos. Los investigadores han identificado los problemas del análisis de requerimientos y sus causas, y han desarrollado varias notaciones de modelado y los conjuntos heurísticos correspondientes para resolver aquéllos. Cada método de análisis tiene un punto de vista único. Sin embargo, todos están relacionados por ciertos principios operacionales: Principio 1. Debe representarse y entenderse el dominio de información de un problema.

El dominio de información incluye los datos que fluyen hacia el sistema (usua-

rios finales, otros sistemas o dispositivos externos), los datos que fluyen fuera del sistema (por la interfaz de usuario, interfaces de red, reportes, gráficas y otros medios) y los almacenamientos de datos que recaban y organizan objetos persistentes de datos (por ejemplo, aquellos que se conservan en forma permanente).


26/1/10 17:31:59

92

PU

PAR T E DOS

MO D E LADO

Principio 2. Deben definirse las funciones que realizará el software.

NT

O

CLAVE

El modelado del análisis se centra en tres atributos del software: la información que se va a procesar, la función que se va a entregar y el comportamiento que va a suceder.

Las funciones

del software dan un beneficio directo a los usuarios finales y también brindan apoyo interno para las características que son visibles para aquéllos. Algunas funciones transforman los datos que fluyen hacia el sistema. En otros casos, las funciones activan algún nivel de control sobre el procesamiento interno del software o sobre los elementos externos del sistema. Las funciones se describen en muchos y distintos niveles de abstracción, que van de un enunciado de propósito general a la descripción detallada de los elementos del procesamiento que deben invocarse. Principio 3. Debe representarse el comportamiento del software (como consecuen-

Cita: “En cualquier trabajo de diseño, el primer problema del ingeniero es descubrir cuál es realmente el problema.” Autor desconocido

cia de eventos externos). El comportamiento del software de computadora está determinado por su interacción con el ambiente externo. Las entradas que dan los usuarios finales, el control de los datos efectuado por un sistema externo o la vigilancia de datos reunidos en una red son el motivo por el que el software se comporta en una forma específica. Principio 4. Los modelos que representen información, función y comportamiento deben dividirse de manera que revelen los detalles en forma estratificada (o jerárquica).

El modelado de los requerimientos es el primer paso para resolver un pro-

blema de ingeniería de software. Eso permite entender mejor el problema y proporciona una base para la solución (diseño). Los problemas complejos son difíciles de resolver por completo. Por esta razón, debe usarse la estrategia de divide y vencerás. Un problema grande y complejo se divide en subproblemas hasta que cada uno de éstos sea relativamente fácil de entender. Este concepto se llama partición o separación de entidades, y es una estrategia clave en el modelado de requerimientos. Principio 5. El trabajo de análisis debe avanzar de la información esencial hacia la implementación en detalle. El modelado de requerimientos comienza con la descripción del problema desde la perspectiva del usuario final. Se describe la “esencia” del problema sin considerar la forma en la que se implementará la solución. Por ejemplo, un juego de video requiere que la jugadora “enseñe” a su protagonista en qué dirección avanzar cuando se mueve hacia un laberinto peligroso. Ésa es la esencia del problema. La implementación detallada (normalmente descrita como parte del modelo del diseño) indica cómo se desarrollará la esencia. Para el juego de video, quizá se use una entrada de voz, o se escriba un comando en un teclado, o tal vez un joystick (o mouse) apunte en una dirección específica, o quizá se mueva en el aire un dispositivo sensible al movimiento. Con la aplicación de estos principios, un ingeniero de software aborda el problema en forma sistemática. Pero, ¿cómo se aplican estos principios en la práctica? Esta pregunta se responderá en los capítulos 5 a 7. Principios del modelado del diseño.

El modelo del diseño del software es análogo a los

planos arquitectónicos de una casa. Se comienza por representar la totalidad de lo que se va a construir (por ejemplo, un croquis tridimensional de la casa) que se refina poco a poco para que guíe la construcción de cada detalle (por ejemplo, la distribución de la plomería). De manera similar, el modelo del diseño que se crea para el software da varios puntos de vista distintos del

Cita:

sistema. No escasean los métodos para obtener los distintos elementos de un diseño de software.

“Vea primero que el diseño es sabio y justo: eso comprobado, siga resueltamente; no para uno renunciar a rechazar el propósito de que ha resuelto llevar a cabo.”

Algunos son activados por datos, lo que hace que sea la estructura de éstos la que determine la

William Shakespeare

se apegan a principios de diseño que se aplican sin importar el método empleado.


arquitectura del programa y los componentes de procesamiento resultantes. Otros están motivados por el patrón, y usan información sobre el dominio del problema (el modelo de requerimientos) para desarrollar estilos de arquitectura y patrones de procesamiento. Otros más están orientados a objetos, y utilizan objetos del dominio del problema como impulsores de la creación de estructuras de datos y métodos que los manipulan. No obstante la variedad, todos ellos

26/1/10 17:32:00

C AP Í T UL O 4

93


Principio 1. El diseño debe poderse rastrear hasta el modelo de requerimientos.

El

modelo de requerimientos describe el dominio de información del problema, las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases de requerimientos que agrupa los objetos del negocio con los métodos que les dan servicio. El modelo de diseño traduce esta información en una arquitectura, un conjunto de subsistemas que implementan las funciones principales y un conjunto de componentes que son la realización de las clases de requerimientos. Los elementos del modelo de diseño deben poder rastrearse en el modelo de requerimientos. Principio 2. Siempre tomar en cuenta la arquitectura del sistema que se va a

WebRef

construir.

En la dirección cs.wwc.edu/ ~aabyan/Design/, se encuentran comentarios profundos sobre el proceso de diseño, así como un análisis de la estética del diseño.

La arquitectura del software (véase el capítulo 9) es el esqueleto del sistema

que se va a construir. Afecta interfaces, estructuras de datos, flujo de control y comportamiento del programa, así como la manera en la que se realizarán las pruebas, la susceptibilidad del sistema resultante a recibir mantenimiento y mucho más. Por todas estas razones, el diseño debe comenzar con consideraciones de la arquitectura. Sólo después de establecida ésta deben considerarse los aspectos en el nivel de los componentes. Principio 3. El diseño de los datos es tan importante como el de las funciones de procesamiento. El diseño de los datos es un elemento esencial del diseño de la arquitectura. La forma en la que los objetos de datos se elaboran dentro del diseño no puede dejarse al azar. Un diseño de datos bien estructurado ayuda a simplificar el flujo del programa, hace más fácil el diseño e implementación de componentes de software y más eficiente el procesamiento conjunto. Principio 4. Las interfaces (tanto internas como externas) deben diseñarse con

Cita:

cuidado.

La manera en la que los datos fluyen entre los componentes de un sistema tiene

mucho que ver con la eficiencia del procesamiento, la propagación del error y la simplici-

“Las diferencias no son menores; por el contrario, son como las que había entre Salieri y Mozart. Un estudio tras otro muestran que los mejores diseñadores elaboran estructuras más rápidas, pequeñas, sencillas, claras y producidas con menos esfuerzo.”

dad del diseño. Una interfaz bien diseñada hace que la integración sea más fácil y ayuda a quien la somete a prueba a validar las funciones componentes. Principio 5. El diseño de la interfaz de usuario debe ajustarse a las necesidades del usuario final. Sin embargo, en todo caso debe resaltar la facilidad de uso. La interfaz de usuario es la manifestación visible del software. No importa cuán sofisticadas sean sus funciones internas, ni lo incluyentes que sean sus estructuras de datos, ni lo bien diseñada que esté su arquitectura, un mal diseño de la interfaz con frecuencia conduce a la percepción de que el software es “malo”.

Frederick P. Brooks

Principio 6. El diseño en el nivel de componentes debe tener independencia funcional.

La independencia funcional es una medida de la “mentalidad única” de un

componente de software. La funcionalidad que entrega un componente debe ser cohesiva, es decir, debe centrarse en una y sólo una función o subfunción.5 Principio 7. Los componentes deben estar acoplados con holgura entre sí y con el ambiente externo. El acoplamiento se logra de muchos modos: con una interfaz de componente, con mensajería, por medio de datos globales, etc. A medida que se incrementa el nivel de acoplamiento, también aumenta la probabilidad de propagación del error y disminuye la facilidad general de dar mantenimiento al software. Entonces, el acoplamiento de componentes debe mantenerse tan bajo como sea razonable. Principio 8. Las representaciones del diseño (modelos) deben entenderse con facilidad.

El propósito del diseño es comunicar información a los profesionales que gene-

rarán el código, a los que probarán el software y a otros que le darán mantenimiento en el futuro. Si el diseño es difícil de entender, no servirá como medio de comunicación eficaz.

5


En el capítulo 8 hay más análisis de la cohesión.

26/1/10 17:32:00

94

PAR T E DOS

MO D E LADO

Principio 9. El diseño debe desarrollarse en forma iterativa. El diseñador debe buscar más sencillez en cada iteración.

Igual que ocurre con casi todas las actividades

creativas, el diseño ocurre de manera iterativa. Las primeras iteraciones sirven para mejorar el diseño y corregir errores, pero las posteriores deben buscar un diseño tan sencillo como sea posible. Cuando se aplican en forma apropiada estos principios de diseño, se crea uno que exhibe factores de calidad tanto externos como internos [Mye78]. Los factores de calidad externos son aquellas propiedades del software fácilmente observables por los usuarios (por ejemplo, velocidad, confiabilidad, corrección y usabilidad). Los factores de calidad internos son de importancia para los ingenieros de software. Conducen a un diseño de alta calidad desde el punto de vista técnico. Para obtener factores de calidad internos, el diseñador debe entender los conceptos básicos del diseño (véase el capítulo 8).

4.3.4

Principios de construcción

La actividad de construcción incluye un conjunto de tareas de codificación y pruebas que lleva

Cita: “Durante gran parte de mi vida he sido un mirón del software, y observo furtivamente el código sucio de otras personas. A veces encuentro una verdadera joya, un programa bien estructurado escrito en un estilo consistente, libre de errores, desarrollado de modo que cada componente es sencillo y organizado, y que está diseñado de modo que el producto es fácil de cambiar.” David Parnas

a un software operativo listo para entregarse al cliente o usuario final. En el trabajo de ingeniería de software moderna, la codificación puede ser 1) la creación directa de lenguaje de programación en código fuente (por ejemplo, Java), 2) la generación automática de código fuente que usa una representación intermedia parecida al diseño del componente que se va a construir o 3) la generación automática de código ejecutable que utiliza un “lenguaje de programación de cuarta generación” (por ejemplo, Visual C++). Las pruebas dirigen su atención inicial al componente, y con frecuencia se denomina prueba unitaria. Otros niveles de pruebas incluyen 1) de integración (realizadas mientras el sistema está en construcción), 2) de validación, que evalúan si los requerimientos se han satisfecho para todo el sistema (o incremento de software) y 3) de aceptación, que efectúa el cliente en un esfuerzo por utilizar todas las características y funciones requeridas. Los siguientes principios y conceptos son aplicables a la codificación y prueba: Principios de codificación.

Los principios que guían el trabajo de codificación se relacionan

de cerca con el estilo, lenguajes y métodos de programación. Sin embargo, puede enunciarse cierto número de principios fundamentales: Principios de preparación: Antes de escribir una sola línea de código, asegúrese de:

• Entender el problema que se trata de resolver. • Comprender los principios y conceptos básicos del diseño. • Elegir un lenguaje de programación que satisfaga las necesidades del software que se va a elaborar y el ambiente en el que operará.

• Seleccionar un ambiente de programación que disponga de herramientas que hagan CONSEJO

Evite desarrollar un programa elegante que resuelva el problema equivocado. Ponga especial atención al primer principio de preparación.

más fácil su trabajo.

• Crear un conjunto de pruebas unitarias que se aplicarán una vez que se haya terminado el componente a codificar. Principios de programación: Cuando comience a escribir código, asegúrese de:

• Restringir sus algoritmos por medio del uso de programación estructurada [Boh00]. • Tomar en consideración el uso de programación por parejas. • Seleccionar estructuras de datos que satisfagan las necesidades del diseño. • Entender la arquitectura del software y crear interfaces que son congruentes con ella. • Mantener la lógica condicional tan sencilla como sea posible.


26/1/10 17:32:00

C AP Í T UL O 4

95


• Crear lazos anidados en forma tal que se puedan probar con facilidad. • Seleccionar nombres significativos para las variables y seguir otros estándares locales de codificación.

• Escribir código que se documente a sí mismo. • Crear una imagen visual (por ejemplo, líneas con sangría y en blanco) que ayude a entender. Principios de validación: Una vez que haya terminado su primer intento de codificación, asegúrese de:

• Realizar el recorrido del código cuando sea apropiado. • Llevar a cabo pruebas unitarias y corregir los errores que se detecten. • Rediseñar el código. WebRef En la dirección www. literateprogramming.com/ fpstyle.html, hay una amplia variedad de vínculos a estándares de codificación.

Se han escrito más libros sobre programación (codificación) y sobre los principios y conceptos que la guían que sobre cualquier otro tema del proceso de software. Los libros sobre el tema incluyen obras tempranas sobre estilo de programación [Ker78], construcción de software práctico [McC04], perlas de programación [Ben99], el arte de programar [Knu98], temas pragmáticos de programación [Hun99] y muchísimos temas más. El análisis exhaustivo de estos principios y conceptos está más allá del alcance de este libro. Si tiene interés en profundizar, estudie una o varias de las referencias que se mencionan. Principios de la prueba.

En un libro clásico sobre las pruebas de software, Glen Myers

[Mye79] enuncia algunas reglas que sirven bien como objetivos de prueba:

?

• La prueba es el proceso que ejecuta un programa con objeto de encontrar un error.

¿Cuáles son los objetivos de probar el software?

• Un buen caso de prueba es el que tiene alta probabilidad de encontrar un error que no se ha detectado hasta el momento.

• Una prueba exitosa es la que descubre un error no detectado hasta el momento. CONSEJO

En un contexto amplio del diseño de software, recuerde que se comienza “por lo grande” y se centra en la arquitectura del software, y que se termina “en lo pequeño” y se atiende a los componentes. Para la prueba sólo se invierte el proceso.

Estos objetivos implican un cambio muy grande en el punto de vista de ciertos desarrolladores de software. Ellos avanzan contra la opinión común de que una prueba exitosa es aquella que no encuentra errores en el software. El objetivo es diseñar pruebas que detecten de manera sistemática diferentes clases de errores, y hacerlo con el mínimo tiempo y esfuerzo. Si las pruebas se efectúan con éxito (de acuerdo con los objetivos ya mencionados), descubrirán errores en el software. Como beneficio secundario, la prueba demuestra que las funciones de software parecen funcionar de acuerdo con las especificaciones, y que los requerimientos de comportamiento y desempeño aparentemente se cumplen. Además, los datos obtenidos conforme se realiza la prueba dan una buena indicación de la confiabilidad del software y ciertas indicaciones de la calidad de éste como un todo. Pero las pruebas no pueden demostrar la inexistencia de errores y defectos; sólo demuestran que hay errores y defectos. Es importante recordar esto (que de otro modo parecería muy pesimista) cuando se efectúe una prueba. Davis [Dav95b] sugiere algunos principios para las pruebas,6 que se han adaptado para usarlos en este libro: Principio 1. Todas las pruebas deben poder rastrearse hasta los requerimientos del cliente.7

El objetivo de las pruebas de software es descubrir errores. Entonces, los defec-

6

Aquí sólo se mencionan pocos de los principios de prueba de Davis. Para más información, consulte [Dav95b].

7

Este principio se refiere a las pruebas funcionales, por ejemplo, aquellas que se centran en los requerimientos. Las pruebas estructurales (las que se centran en los detalles de arquitectura o lógica) tal vez no aborden directamente los requerimientos específicos.


26/1/10 17:32:00

96

PAR T E DOS

MO D E LADO

tos más severos (desde el punto de vista del cliente) son aquellos que hacen que el programa no cumpla sus requerimientos. Principio 2. Las pruebas deben planearse mucho antes de que den comienzo.

La

planeación de las pruebas (véase el capítulo 17) comienza tan pronto como se termina el modelo de requerimientos. La definición detallada de casos de prueba principia apenas se ha concluido el modelo de diseño. Por tanto, todas las pruebas pueden planearse y diseñarse antes de generar cualquier código. Principio 3. El principio de Pareto se aplica a las pruebas de software.

En este con-

texto, el principio de Pareto implica que 80% de todos los errores no detectados durante las pruebas se relacionan con 20% de todos los componentes de programas. Por supuesto, el problema es aislar los componentes sospechosos y probarlos a fondo. Principio 4. Las pruebas deben comenzar “en lo pequeño” y avanzar hacia “lo grande”. Las primeras pruebas planeadas y ejecutadas por lo general se centran en componentes individuales. Conforme avanzan las pruebas, la atención cambia en un intento por encontrar errores en grupos integrados de componentes y, en última instancia, en todo el sistema. Principio 5. No son posibles las pruebas exhaustivas. Hasta para un programa de tamaño moderado, el número de permutaciones de las rutas es demasiado grande. Por esta razón, durante una prueba es imposible ejecutar todas las combinaciones de rutas. Sin embargo, es posible cubrir en forma adecuada la lógica del programa y asegurar que se han probado todas las condiciones en el nivel de componentes.

4.3.5

Principios de despliegue

Como se dijo en la parte 1 del libro, la actividad del despliegue incluye tres acciones: entrega, apoyo y retroalimentación. Como la naturaleza de los modelos del proceso del software moderno es evolutiva o incremental, el despliegue ocurre no una vez sino varias, a medida que el software avanza hacia su conclusión. Cada ciclo de entrega pone a disposición de los clientes y usuarios finales un incremento de software operativo que brinda funciones y características utilizables. Cada ciclo de apoyo provee documentación y ayuda humana para todas las funciones y características introducidas durante los ciclos de despliegue realizados hasta ese momento. Cada ciclo de retroalimentación da al equipo de software una guía importante que da como resultado modificaciones de las funciones, de las características y del enfoque adoptado para el siguiente incremento. CONSEJO

Asegúrese de que su cliente sabe lo que puede esperar antes de que se entregue un incremento de software. De otra manera, puede apostar a que el cliente espera más de lo que usted le dará.

La entrega de un incremento de software representa un punto de referencia importante para cualquier proyecto de software. Cuando el equipo se prepara para entregar un incremento, deben seguirse ciertos principios clave: Principio 1. Deben manejarse las expectativas de los clientes. Con demasiada frecuencia, el cliente espera más de lo que el equipo ha prometido entregar, y la desilusión llega de inmediato. Esto da como resultado que la retroalimentación no sea productiva y arruine la moral del equipo. En su libro sobre la administración de las expectativas, Naomi Karten [Kar94] afirma que “el punto de inicio de la administración de las expectativas es ser más consciente de lo que se comunica y de la forma en la que esto se hace”. Ella sugiere que el ingeniero de software debe tener cuidado con el envío de mensajes conflictivos al cliente (por ejemplo, prometer más de lo que puede entregarse de manera razonable en el plazo previsto, o entregar más de lo que se prometió en un incremento de software y para el siguiente entregar menos). Principio 2. Debe ensamblarse y probarse el paquete completo que se entregará. Debe ensamblarse en un CD-ROM u otro medio (incluso descargas desde web) todo el software ejecutable, archivos de datos de apoyo, documentos de ayuda y otra información rele-


26/1/10 17:32:01

C AP Í T UL O 4

97


vante, para después hacer una prueba beta exhaustiva con usuarios reales. Todos los scripts de instalación y otras características de operación deben ejecutarse por completo en tantas configuraciones diferentes de cómputo como sea posible (por ejemplo, hardware, sistemas operativos, equipos periféricos, configuraciones de red, etcétera). Principio 3. Antes de entregar el software, debe establecerse un régimen de apoyo. Un usuario final espera respuesta e información exacta cuando surja una pregunta o problema. Si el apoyo es ad hoc, o, peor aún, no existe, el cliente quedará insatisfecho de inmediato. El apoyo debe planearse, los materiales respectivos deben prepararse y los mecanismos apropiados de registro deben establecerse a fin de que el equipo de software realice una evaluación categórica de las clases de apoyo solicitado. Principio 4. Se deben proporcionar a los usuarios finales materiales de aprendizaje apropiados. El equipo de software entrega algo más que el software en sí. Deben desarrollarse materiales de capacitación apropiados (si se requirieran); es necesario proveer lineamientos para solución de problemas y, cuando sea necesario, debe publicarse “lo que es diferente en este incremento de software”.8 Principio 5. El software defectuoso debe corregirse primero y después entregarse. Cuando el tiempo apremia, algunas organizaciones de software entregan incrementos de baja calidad con la advertencia de que los errores “se corregirán en la siguiente entrega”. Esto es un error. Hay un adagio en el negocio del software que dice así: “Los clientes olvidarán pronto que entregaste un producto de alta calidad, pero nunca olvidarán los problemas que les causó un producto de mala calidad. El software se los recuerda cada día.” El software entregado brinda beneficios al usuario final, pero también da retroalimentación útil para el equipo que lo desarrolló. Cuando el incremento se libere, debe invitarse a los usuarios finales a que comenten acerca de características y funciones, facilidad de uso, confiabilidad y cualesquiera otras características.

4. 4

RESUMEN La práctica de la ingeniería de software incluye principios, conceptos, métodos y herramientas que los ingenieros de software aplican en todo el proceso de desarrollo. Todo proyecto de ingeniería de software es diferente. No obstante, existe un conjunto de principios generales que se aplican al proceso como un todo y a cada actividad estructural, sin importar cuál sea el proyecto o el producto. Existe un conjunto de principios fundamentales que ayudan en la aplicación de un proceso de software significativo y en la ejecución de métodos de ingeniería de software eficaz. En el nivel del proceso, los principios fundamentales establecen un fundamento filosófico que guía al equipo de software cuando avanza por el proceso del software. En el nivel de la práctica, los principios fundamentales establecen un conjunto de valores y reglas que sirven como guía al analizar el diseño de un problema y su solución, al implementar ésta y al someterla a prueba para, finalmente, desplegar el software en la comunidad del usuario. Los principios de comunicación se centran en la necesidad de reducir el ruido y mejorar el ancho de banda durante la conversación entre el desarrollador y el cliente. Ambas partes deben colaborar a fin de lograr la mejor comunicación. Los principios de planeación establecen lineamientos para elaborar el mejor mapa del proceso hacia un sistema o producto terminado. El plan puede diseñarse sólo para un incremento

8

Durante la actividad de comunicación, el equipo de software debe determinar los tipos de materiales de ayuda que quiere el usuario.


26/1/10 17:32:01

98

PAR T E DOS

MO D E LADO

del software, o para todo el proyecto. Sin que esto importe, debe definir lo que se hará, quién lo hará y cuándo se terminará el trabajo. El modelado incluye tanto el análisis como el diseño, y describe representaciones cada vez más detalladas del software. El objetivo de los modelos es afirmar el entendimiento del trabajo que se va a hacer y dar una guía técnica a quienes implementarán el software. Los principios de modelado dan fundamento a los métodos y notación que se utilizan para crear representaciones del software. La construcción incorpora un ciclo de codificación y pruebas en el que se genera código fuente para cierto componente y es sometido a pruebas. Los principios de codificación definen las acciones generales que deben tener lugar antes de que se escriba el código, mientras se escribe y una vez terminado. Aunque hay muchos principios para las pruebas, sólo uno predomina: la prueba es el proceso que lleva a ejecutar un programa con objeto de encontrar un error. El despliegue ocurre cuando se presenta al cliente un incremento de software, e incluye la entrega, apoyo y retroalimentación. Los principios clave para la entrega consideran la administración de las expectativas del cliente y darle información de apoyo adecuada sobre el software. El apoyo demanda preparación anticipada. La retroalimentación permite al cliente sugerir cambios que tengan valor para el negocio y que brinden al desarrollador información para el ciclo iterativo siguiente de ingeniería de software.

PROBLEMAS


4.1. Toda vez que la búsqueda de la calidad reclama recursos y tiempo, ¿es posible ser ágil y centrarse en ella? 4.2. De los ocho principios fundamentales que guían el proceso (lo que se estudió en la sección 4.2.1), ¿cuál cree que sea el más importante? 4.3. Describa con sus propias palabras el concepto de separación de entidades. 4.4. Un principio de comunicación importante establece que hay que “prepararse antes de comunicarse”. ¿Cómo debe manifestarse esta preparación en los primeros trabajos que se hacen? ¿Qué productos del trabajo son resultado de la preparación temprana? 4.5. Haga algunas investigaciones acerca de cómo “facilitar” la actividad de comunicación (use las referencias que se dan u otras distintas) y prepare algunos lineamientos que se centren en la facilitación. 4.6. ¿En qué difiere la comunicación ágil de la comunicación tradicional de la ingeniería de software? ¿En qué se parecen? 4.7. ¿Por qué es necesario “avanzar”? 4.8. Investigue sobre la “negociación” para la actividad de comunicación y prepare algunos lineamientos que se centren sólo en ella. 4.9. Describa lo que significa granularidad en el contexto de la programación de actividades de un proyecto. 4.10. ¿Por qué son importantes los modelos en el trabajo de ingeniería de software? ¿Siempre son necesarios? ¿Hay calificadores para la respuesta que se dio sobre esta necesidad? 4.11. ¿Cuáles son los tres “dominios” considerados durante el modelado de requerimientos? 4.12. Trate de agregar un principio adicional a los que se mencionan en la sección 4.3.4 para la codificación. 4.13. ¿Qué es una prueba exitosa? 4.14. Diga si está de acuerdo o en desacuerdo con el enunciado siguiente: “Como entregamos incrementos múltiples al cliente, no debiéramos preocuparnos por la calidad en los primeros incrementos; en las iteraciones posteriores podemos corregir los problemas. Explique su respuesta. 4.15. ¿Por qué es importante la retroalimentación para el equipo de software?


26/1/10 17:32:01

C AP Í T UL O 4


LECTURAS

Y FUENTES DE INFOR MACIÓN ADICIONALES

99

La comunicación con el cliente es una actividad de importancia crítica en la ingeniería de software, pero pocos de sus practicantes dedican tiempo a leer sobre ella. Withall (Software Requirements Patterns, Microsoft Press, 2007) presenta varios patrones útiles que analizan problemas en la comunicación. Sutliff (User-Centred Requirements Engineering, Springer, 2002) se centra mucho en los retos relacionados con la comunicación. Los libros de Weigers (Software Requierements, 2a. ed., Microsoft Press, 2003), Pardee (To Satisfy and Delight Your Customer, Dorset House, 1996) y Karten [Kar94] analizan a profundidad los métodos para tener una interacción eficaz con el cliente. Aunque su libro no se centra en el software, Hooks y Farry (Customer Centered Products, American Management Association, 2000) presentan lineamientos generales útiles para la comunicación con los clientes. Young (Effective Requirements Practices, Addison-Wesley, 2001) pone el énfasis en un “equipo conjunto” de clientes y desarrolladores que recaben los requerimientos en colaboración. Somerville y Kotonya (Requirements Engineering: Processes and Techniques, Wiley, 1998) analizan el concepto de “provocación” y las técnicas y otros requerimientos de los principios de ingeniería. Los conceptos y principios de la comunicación y planeación son estudiados en muchos libros de administración de proyectos. Entre los más útiles se encuentran los de Bechtold (Essentials of Software Project Management, 2a. ed., Management Concepts, 2007), Wysocki (Effective Project Management: Traditional, Adaptive, Extreme, 4a. ed., Wiley, 2006), Leach (Lean Project Management: Eight Principles for Success, BookSurge Publishing, 2006) Hughes (Software Project Management, McGraw-Hill, 2005) y Stellman y Greene (Applied Software Project Management, O’Reilly Media, Inc., 2005). Davis [Dav95] hizo una compilación excelente de referencias sobre principios de la ingeniería de software. Además, virtualmente todo libro al respecto contiene un análisis útil de los conceptos y principios para análisis, diseño y prueba. Entre los más utilizados (además de éste, claro) se encuentran los siguientes: Abran, A., y J. Moore, SWEBOK: Guide to the Software Engineering Body of Knowledge, IEEE, 2002. Christensen, M., y R. Thayer, A Project Manager’s Guide to Software Engineering Best Practices, IEEE-CS Press (Wiley), 2002. Jalote, P., An Integrated Approach to Software Engineering, Springer, 2006. Pfleeger, S., Software Engineering: Theory and Practice, 3a. ed., Prentice-Hall, 2005. Schach, S., Object- Oriented and Classical Software Engineering, McGraw-Hill, 7a. ed., 2006. Sommerville, I., Software Engineering, 8a. ed., Addison-Wesley, 2006 Estos libros también presentan análisis detallados sobre los principios de modelado y construcción. Los principios de modelado se estudian en muchos libros dedicados al análisis de requerimientos o diseño de software. Los libros de Lieberman (The Art of Software Modeling, Auerbach, 2007), Rosenberg y Stephens (Use Case Driven Object Modeling with UML: Theory and Practice, Apress, 2007), Roques (UML in Practice, Wiley, 2004) y Penker y Eriksson (Business Modeling with UML: Business Patterns at Work, Wiley, 2001) analizan los principios y métodos de modelado. Todo ingeniero de software que trate de hacer diseño está obligado a leer el texto de Norman (The Design of Everyday Things, Currency/Doubleday, 1990). Winograd y sus colegas (Bringing Design to Software, Addison-Wesley, 1996) editaron una excelente colección de ensayos sobre aspectos prácticos del diseño de software. Constantine y Lockwood (Software for Use, Addison-Wesley, 1999) presenta los conceptos asociados con el “diseño centrado en el usuario”. Tognazzini (Tog on Software Design, Addison-Wesley, 1995) presenta una reflexión filosófica útil sobre la naturaleza del diseño y el efecto que tienen las decisiones sobre la calidad y la capacidad del equipo para producir software que agregue mucho valor para su cliente. Stahl y sus colegas (Model-Driven Software Development: Technology, Engineering, Wiley, 2006) estudian los principios del desarrollo determinado por el modelo. Son cientos los libros que abordan uno o más elementos de la actividad de construcción. Kernighan y Plauger [Ker78] escribieron un texto clásico sobre el estilo de programación, McConell [McC93] presenta lineamientos prácticos para la construcción de software, Bentley [Ben99] sugiere una amplia variedad de perlas de la programación, Knuth [Knu99] escribió una serie clásica de tres volúmenes acerca del arte de programar y Hunt [Hun99] sugiere lineamientos pragmáticos para la programación. Myers y sus colegas (The Art of Software Testing, 2a. ed., Wiley, 2004) desarrollaron una revisión importante de su texto clásico y muchos principios importantes para la realización de pruebas. Los libros de Perry (Effective Methods for Software Testing, 3a. ed., Wiley 2006), Whittaker (How to Break Software, Addison-Wesley, 2002), Kaner y sus colegas (Lessons Learned in Software Testing, Wiley, 2001) y Marick (The Craft of Software Testing, Prentice-Hall, 1997) presentan por separado conceptos y principios importantes para hacer pruebas, así como muchas guías prácticas.


26/1/10 17:32:01

100

PAR T E DOS

MO D E LADO

En internet existe una amplia variedad de fuentes de información sobre la práctica de ingeniería de software. En el sitio web del libro se encuentra una lista actualizada de referencias en la Red Mundial que son relevantes para la ingeniería de software: www.mhe.com/engcs/compsci/pressman/professional/ olc/ser.htm


26/1/10 17:32:02

CAPÍTULO

COMPRENSIÓN

DE

LOS REQUERIMIENTOS CONCEPTOS

CLAVE

administración de los requerimientos . . . . . . . . . . 105

5

ntender los requerimientos de un problema es una de las tareas más difíciles que enfrenta

E

el ingeniero de software. Cuando se piensa por primera vez, no parece tan difícil desarrollar un entendimiento claro de los requerimientos. Después de todo, ¿acaso no sabe el

casos de uso . . . . . . . . . . . . 113

cliente lo que se necesita? ¿No deberían tener los usuarios finales una buena comprensión de

colaboración . . . . . . . . . . . . 107

las características y funciones que le darán un beneficio? Sorprendentemente, en muchas ins-

concepción . . . . . . . . . . . . . 102

tancias la respuesta a estas preguntas es “no”. E incluso si los clientes y los usuarios finales

despliegue de la función de calidad . . . . . . . . . . . . . . 111

explican sus necesidades, éstas cambiarán mientras se desarrolla el proyecto.

elaboración . . . . . . . . . . . . . 117 especificación . . . . . . . . . . . 104

En el prólogo a un libro escrito por Ralph Young [You01] sobre las prácticas eficaces respecto de los requerimientos, escribí lo siguiente:

indagación . . . . . . . . . . . . . 103

Es la peor de las pesadillas. Un cliente entra a la oficina, toma asiento, lo mira a uno fijamente a los

indagación de los requerimientos . . . . . . . . . . 108

ojos y dice: “Sé que cree que entiende lo que digo, pero lo que usted no entiende es que lo que digo

ingeniería de requerimientos . . . . . . . . . . 102

de que se han hecho compromisos con los plazos de entrega, que hay reputaciones en juego y mucho

modelo del análisis . . . . . . . 117 negociación . . . . . . . . . . . . . 121 participantes. . . . . . . . . . . . 106 patrones de análisis . . . . . . 120 productos del trabajo. . . . . . 112 puntos de vista . . . . . . . . . . 107 validación . . . . . . . . . . . . . . 105 validación de los requerimientos . . . . . . . . . . 122

no es lo que quiero decir.” Invariablemente, esto pasa cuando ya está avanzado el proyecto, después dinero invertido. Todos los que hemos trabajado en el negocio de los sistemas y del software durante algunos años hemos vivido la pesadilla descrita, pero pocos hemos aprendido a escapar. Batallamos cuando tratamos de obtener los requerimientos de nuestros clientes. Tenemos problemas para entender la información que obtenemos. Es frecuente que registremos los requerimientos de manera desorganizada y que dediquemos muy poco tiempo a verificar lo que registramos. Dejamos que el cambio nos controle en lugar de establecer mecanismos para controlarlo a él. En pocas palabras, fallamos en establecer un fundamento sólido para el sistema o software. Cada uno de los problemas es difícil. Cuando se combinan, el panorama es atemorizador aun para los gerentes y profesionales más experimentados. Pero hay solución.

UNA ¿Qué es? Antes de comenzar cualquier trabajo técnico es una buena idea aplicar un conjunto de tareas de ingeniería a los requerimientos. Éstas llevarán a la comprensión de cuál será el efecto que tendrá el software en el negocio, qué es lo que quiere el cliente y cómo interactuarán los usuarios finales con el software. ¿Quién lo hace? Los ingenieros de software (que en el mundo de las tecnologías de información a veces son llamados ingenieros de sistemas o analistas) y todos los demás participantes del proyecto (gerentes, clientes y usuarios) intervienen en la ingeniería de requerimientos. ¿Por qué es importante? Diseñar y construir un elegante programa de cómputo que resuelva el problema equivocado no satisface las necesidades de nadie. Por eso es importante entender lo que el cliente desea antes de comenzar a diseñar y a construir un sistema basado en computadora. ¿Cuáles son los pasos? La ingeniería de requerimientos comienza con la concepción, tarea que define el alcance y la naturaleza del problema que se va a resolver. Va seguida de la indagación, labor que ayuda a los participantes

MIRADA RÁPIDA

a definir lo que se requiere. Después sigue la elaboración, donde se refinan y modifican los requerimientos básicos. Cuando los participantes definen el problema, tiene lugar una negociación: ¿cuáles son las prioridades, qué es lo esencial, cuándo se requiere? Por último, se especifica el problema de algún modo y luego se revisa o valida para garantizar que hay coincidencia entre la comprensión que usted tiene del problema y la que tienen los participantes. ¿Cuál es el producto final? El objetivo de los requerimientos de ingeniería es proporcionar a todas las partes un entendimiento escrito del problema. Esto se logra por medio de varios productos del trabajo: escenarios de uso, listas de funciones y de características, modelos de requerimientos o especificaciones. ¿Cómo me aseguro de que lo hice bien? Se revisan con los participantes los productos del trabajo de la ingeniería de requerimientos a fin de asegurar que lo que se aprendió es lo que ellos quieren decir en realidad. Aquí cabe una advertencia: las cosas cambiarán aun después de que todas las partes estén de acuerdo, y seguirán cambiando durante todo el proyecto.

101


21/1/10 11:00:18

102

PAR T E DOS

MO D E LADO

Es razonable afirmar que las técnicas que se estudiarán en este capítulo no son una “solución” verdadera para los retos que se mencionaron, pero sí proveen de un enfoque sólido para enfrentarlos.

5. 1

INGENIERÍA

DE REQUERIMIENTOS

El diseño y construcción de software de computadora es difícil, creativo y sencillamente diver-

Cita: “La parte más difícil al construir un sistema de software es decidir qué construir. Ninguna parte del trabajo invalida tanto al sistema resultante si ésta se hace mal. Nada es más difícil de corregir después.” Fred Brooks

tido. En realidad, elaborar software es tan atractivo que muchos desarrolladores de software quieren ir directo a él antes de haber tenido el entendimiento claro de lo que se necesita. Argumentan que las cosas se aclararán a medida que lo elaboren, que los participantes en el proyecto podrán comprender sus necesidades sólo después de estudiar las primeras iteraciones del software, que las cosas cambian tan rápido que cualquier intento de entender los requerimientos en detalle es una pérdida de tiempo, que las utilidades salen de la producción de un programa que funcione y que todo lo demás es secundario. Lo que hace que estos argumentos sean tan seductores es que tienen algunos elementos de verdad.1 Pero todos son erróneos y pueden llevar un proyecto de software al fracaso. El espectro amplio de tareas y técnicas que llevan a entender los requerimientos se denomina ingeniería de requerimientos. Desde la perspectiva del proceso del software, la ingeniería de requerimientos es una de las acciones importantes de la ingeniería de software que comienza durante la actividad de comunicación y continúa en la de modelado. Debe adaptarse a las necesidades del proceso, del proyecto, del producto y de las personas que hacen el trabajo.

PU

La ingeniería de requerimientos tiende un puente para el diseño y la construcción. Pero,

NT

O

CLAVE

La ingeniería de requerimientos establece una base sólida para el diseño y la construcción. Sin ésta, el software resultante tiene alta probabilidad de no satisfacer las necesidades del cliente.

¿dónde se origina el puente? Podría argumentarse que principia en los pies de los participantes en el proyecto (por ejemplo, gerentes, clientes y usuarios), donde se definen las necesidades del negocio, se describen los escenarios de uso, se delinean las funciones y características y se identifican las restricciones del proyecto. Otros tal vez sugieran que empieza con una definición más amplia del sistema, donde el software no es más que un componente del dominio del sistema mayor. Pero sin importar el punto de arranque, el recorrido por el puente lo lleva a uno muy alto sobre el proyecto, lo que le permite examinar el contexto del trabajo de software que debe realizarse; las necesidades específicas que deben abordar el diseño y la construcción; las prioridades que guían el orden en el que se efectúa el trabajo, y la información, las funciones y

CONSEJO

Espere hacer un poco de diseño al recabar los requerimientos, y un poco de requerimientos durante el trabajo de diseño.

los comportamientos que tendrán un profundo efecto en el diseño resultante. La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que desea el cliente, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación y administrar los requerimientos a medida de que se transforman en un sistema funcional [Tha97]. Incluye siete tareas diferentes: concepción, indagación, elaboración, negociación, especificación, validación y administración. Es importante notar que algunas de estas tareas ocurren en paralelo y que todas

Cita: “Las semillas de los desastres enormes del software por lo general se vislumbran en los tres primeros meses del inicio del proyecto.” Coper Jones

se adaptan a las necesidades del proyecto. Concepción.

¿Cómo inicia un proyecto de software? ¿Existe un solo evento que se convierte

en el catalizador de un nuevo sistema o producto basado en computadora o la necesidad evoluciona en el tiempo? No hay respuestas definitivas a estas preguntas. En ciertos casos, una conversación casual es todo lo que se necesita para desencadenar un trabajo grande de ingeniería de software. Pero en general, la mayor parte de proyectos comienzan cuando se identifica una necesidad del negocio o se descubre un nuevo mercado o servicio potencial. Los partici-

1

Esto es cierto en particular para los proyectos pequeños (menos de un mes) y muy pequeños, que requieren relativamente poco esfuerzo de software sencillo. A medida que el software crece en tamaño y complejidad, estos argumentos comienzan a ser falsos.


21/1/10 11:00:19

C AP Í T UL O 5

COMPRENSIÓN DE LOS REQ U ERIMIENT OS

103

pantes de la comunidad del negocio (por ejemplo, los directivos, personal de mercadotecnia, gerentes de producto, etc.) definen un caso de negocios para la idea, tratan de identificar el ritmo y profundidad del mercado, hacen un análisis de gran visión de la factibilidad e identifican una descripción funcional del alcance del proyecto. Toda esta información está sujeta a cambio, pero es suficiente para desencadenar análisis con la organización de ingeniería de software.2 En la concepción del proyecto,3 se establece el entendimiento básico del problema, las personas que quieren una solución, la naturaleza de la solución que se desea, así como la eficacia de la comunicación y colaboración preliminares entre los otros participantes y el equipo de software. Indagación.

En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras

personas cuáles son los objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el sistema o producto en las operaciones cotidianas. Pero no es simple: es muy difícil. Christel y Kang [Cri92] identificaron cierto número de problemas que se encuentran cuando ocurre la indagación:

?

¿Por qué es difícil llegar al entendimiento claro de lo que quiere el cliente?

• Problemas de alcance. La frontera de los sistemas está mal definida o los clientes o usuarios finales especifican detalles técnicos innecesarios que confunden, más que clarifican, los objetivos generales del sistema.

• Problemas de entendimiento. Los clientes o usuarios no están completamente seguros de lo que se necesita, comprenden mal las capacidades y limitaciones de su ambiente de computación, no entienden todo el dominio del problema, tienen problemas para comunicar las necesidades al ingeniero de sistemas, omiten información que creen que es “obvia”, especifican requerimientos que están en conflicto con las necesidades de otros clientes o usuarios, o solicitan requerimientos ambiguos o que no pueden someterse a prueba.

• Problemas de volatilidad. Los requerimientos cambian con el tiempo. Para superar estos problemas, debe enfocarse la obtención de requerimientos en forma organizada. CONSEJO

La elaboración es algo bueno, pero hay que saber cuándo detenerse. La clave es describir el problema en forma que establezca una base firme para el diseño. Si se trabaja más allá de este punto, se está haciendo diseño.

Elaboración.

La información obtenida del cliente durante la concepción e indagación se ex-

pande y refina durante la elaboración. Esta tarea se centra en desarrollar un modelo refinado de los requerimientos (véanse los capítulos 6 y 7) que identifique distintos aspectos de la función del software, su comportamiento e información. La elaboración está motivada por la creación y mejora de escenarios de usuario que describan cómo interactuará el usuario final (y otros actores) con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases de análisis, que son entidades del dominio del negocio visibles para el usuario final. Se definen los atributos de cada clase de análisis y se identifican los servicios4 que requiere cada una de ellas. Se identifican las relaciones y colaboración entre clases, y se producen varios diagramas adicionales. Negociación.

No es raro que los clientes y usuarios pidan más de lo que puede lograrse dado

lo limitado de los recursos del negocio. También es relativamente común que distintos clientes

2

Si va a desarrollarse un sistema basado en computadora, los análisis comienzan en el contexto de un proceso de ingeniería de sistemas. Para más detalles de la ingeniería de sistemas, visite el sitio web de esta obra.

3

Recuerde que el proceso unificado (véase el capítulo 2) define una “fase de concepción” más amplia que incluye las fases de concepción, indagación y elaboración, que son estudiadas en dicho capítulo.

4

Un servicio manipula los datos agrupados por clase. También se utilizan los términos operación y método. Si no está familiarizado con conceptos de la orientación a objetos, consulte el apéndice 2, en el que se presenta una introducción básica.


21/1/10 11:00:19

104

PAR T E DOS

MO D E LADO

o usuarios propongan requerimientos conflictivos con el argumento de que su versión es “esen-

CONSEJO

cial para nuestras necesidades especiales”.

En una negociación eficaz no debe haber ganador ni perdedor. Ambos lados ganan porque un “trato” con el que ambas partes pueden vivir es algo sólido.

Estos conflictos deben reconciliarse por medio de un proceso de negociación. Se pide a clientes, usuarios y otros participantes que ordenen sus requerimientos según su prioridad y que después analicen los conflictos. Con el empleo de un enfoque iterativo que da prioridad a los requerimientos, se evalúa su costo y riesgo, y se enfrentan los conflictos internos; algunos requerimientos se eliminan, se combinan o se modifican de modo que cada parte logre cierto grado de satisfacción. Especificación.

En el contexto de los sistemas basados en computadora (y software), el tér-

mino especificación tiene diferentes significados para distintas personas. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos. PU

Algunos sugieren que para una especificación debe desarrollarse y utilizarse una “plantilla

NT

O

estándar” [Som97], con el argumento de que esto conduce a requerimientos presentados en

CLAVE

forma consistente y por ello más comprensible. Sin embargo, en ocasiones es necesario ser

La formalidad y el formato de una especificación varían con el tamaño y complejidad del software que se va a construir.

flexible cuando se desarrolla una especificación. Para sistemas grandes, el mejor enfoque puede ser un documento escrito que combine descripciones en un lenguaje natural con modelos gráficos. No obstante, para productos o sistemas pequeños que residan en ambientes bien entendidos, quizá todo lo que se requiera sea escenarios de uso.

I NFOR MACIÓN Formato de especificación de requerimientos de software Una especificación de requerimientos de software (ERS) es un documento que se crea cuando debe especificarse una descripción detallada de todos los aspectos del software que se va a elaborar, antes de que el proyecto comience. Es importante notar que una ERS formal no siempre está en forma escrita. En realidad, hay muchas circunstancias en las que el esfuerzo dedicado a la ERS estaría mejor aprovechado en otras actividades de la ingeniería de software. Sin embargo, se justifica la ERS cuando el software va a ser desarrollado por una tercera parte, cuando la falta de una especificación crearía problemas severos al negocio, si un sistema es complejo en extremo o si se trata de un negocio de importancia crítica. Karl Wiegers [Wie03], de la empresa Process Impact Inc., desarrolló un formato útil (disponible en www.processimpact.com/ process_assets/srs_template.doc) que sirve como guía para aquellos que deben crear una ERS completa. Su contenido normal es el siguiente: Tabla de contenido Revisión de la historia 1. Introducción 1.1 Propósito 1.2 Convenciones del documento 1.3 Audiencia objetivo y sugerencias de lectura 1.4 Alcance del proyecto 1.5 Referencias 2. Descripción general 2.1 Perspectiva del producto


2.2 2.3 2.4 2.5 2.6 2.7

Características del producto Clases y características del usuario Ambiente de operación Restricciones de diseño e implementación Documentación para el usuario Suposiciones y dependencias

3. Características del sistema 3.1 Característica 1 del sistema 3.2 Característica 2 del sistema (y así sucesivamente) 4. Requerimientos de la interfaz externa 4.1 Interfaces de usuario 4.2 Interfaces del hardware 4.3 Interfaces del software 4.4 Interfaces de las comunicaciones 5. Otros requerimientos no funcionales 5.1 Requerimientos de desempeño 5.2 Requerimientos de seguridad 5.3 Requerimientos de estabilidad 5.4 Atributos de calidad del software 6.

Otros requerimientos

Apéndice A: Glosario Apéndice B: Modelos de análisis Apéndice C: Lista de conceptos Puede obtenerse una descripción detallada de cada ERS si se descarga el formato desde la URL mencionada antes.

21/1/10 11:00:20

C AP Í T UL O 5

Validación.

105


La calidad de los productos del trabajo que se generan como consecuencia de la

ingeniería de los requerimientos se evalúa durante el paso de validación. La validación de los requerimientos analiza la especificación5 a fin de garantizar que todos ellos han sido enunciados sin ambigüedades; que se detectaron y corrigieron las inconsistencias, las omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares establecidos para el proceso, el proyecto y el producto.

CONSEJO

El mecanismo principal de validación de los requerimientos es la revisión técnica (véase el

Un aspecto clave durante la validación de los requerimientos es la consistencia. Utilice el modelo de análisis para asegurar que los requerimientos se han enunciado de manera consistente.

capítulo 15). El equipo de revisión que los valida incluye ingenieros de software, clientes, usuarios y otros participantes, que analizan la especificación en busca de errores de contenido o de interpretación, de aspectos en los que tal vez se requiera hacer aclaraciones, falta de información, inconsistencias (problema notable cuando se hace la ingeniería de productos o sistemas grandes) y requerimientos en conflicto o irreales (no asequibles).

I NFOR MACIÓN Lista de verificación para validar requerimientos

• •

Con frecuencia es útil analizar cada requerimiento en comparación con preguntas de verificación. A continuación se presentan algunas:

•

•

•

• • •

¿Los requerimientos están enunciados con claridad? ¿Podrían interpretarse mal? ¿Está identificada la fuente del requerimiento (por ejemplo, una persona, reglamento o documento)? ¿Se ha estudiado el planteamiento final del requerimiento en comparación con la fuente original? ¿El requerimiento está acotado en términos cuantitativos? ¿Qué otros requerimientos se relacionan con éste? ¿Están comparados con claridad por medio de una matriz de referencia cruzada u otro mecanismo?

• • •

¿El requerimiento viola algunas restricciones del dominio? ¿Puede someterse a prueba el requerimiento? Si es así, ¿es posible especificar las pruebas (en ocasiones se denominan criterios de validación) para ensayar el requerimiento? ¿Puede rastrearse el requerimiento hasta cualquier modelo del sistema que se haya creado? ¿Es posible seguir el requerimiento hasta los objetivos del sistema o producto? ¿La especificación está estructurada en forma que lleva a entenderlo con facilidad, con referencias y traducción fáciles a productos del trabajo más técnicos? ¿Se ha creado un índice para la especificación? ¿Están enunciadas con claridad las asociaciones de los requerimientos con las características de rendimiento, comportamiento y operación? ¿Cuáles requerimientos parecen ser implícitos?

Administración de los requerimientos.

Los requerimientos para sistemas basados en

computadora cambian, y el deseo de modificarlos persiste durante toda la vida del sistema. La administración de los requerimientos es el conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en cualquier momento del desarrollo del proyecto.6 Muchas de estas actividades son idénticas a las técnicas de administración de la configuración del software (TAS) que se estudian en el capítulo 22.

5

Recuerde que la naturaleza de la especificación variará con cada proyecto. En ciertos casos, la “especificación” no es más que un conjunto de escenarios de usuario. En otros, la especificación tal vez sea un documento que contiene escenarios, modelos y descripciones escritas.

6

La administración formal de los requerimientos sólo se practica para proyectos grandes que tienen cientos de requerimientos identificables. Para proyectos pequeños, esta actividad tiene considerablemente menos formalidad.


21/1/10 11:00:20

106

PAR T E DOS

MO D E LADO

H ERRAMIENTAS

DE SOFTWARE

Ingeniería de requerimientos Objetivo: Las herramientas de la ingeniería de los requerimientos ayudan a reunir éstos, a modelarlos, administrarlos y validarlos. Mecánica: La mecánica de las herramientas varía. En general, éstas elaboran varios modelos gráficos (por ejemplo, UML) que ilustran los aspectos de información, función y comportamiento de un sistema. Estos modelos constituyen la base de todas las demás actividades del proceso de software. Herramientas representativas:7 En el sitio de Volere Requirements, en www.volere.co.uk/tools. htm, se encuentra una lista razonablemente amplia (y actualizada) de herramientas para la ingeniería de requerimientos. En los capítulos 6 y 7 se estudian las herramientas que sirven para modelar aquéllos. Las que se mencionan a continuación se centran en su administración.

5. 2

ESTABLECER

EasyRM, desarrollada por Cybernetic Intelligence GmbH (www. easy-rm.com), construye un diccionario/glosario especial para proyectos, que contiene descripciones y atributos detallados de los requerimientos. Rational RequisitePro, elaborada por Rational Software (www-306. ibm.com/software/awdtools/reqpro/), permite a los usuarios construir una base de datos de requerimientos, representar relaciones entre ellos y organizarlos, indicar su prioridad y rastrearlos. En el sitio de Volere ya mencionado, se encuentran muchas herramientas adicionales para administrar requerimientos, así como en la dirección www.jiludwig.com/Requirements_ Management_Tools.html

LAS BASES

En el caso ideal, los participantes e ingenieros de software trabajan juntos en el mismo equipo.8 En esas condiciones, la ingeniería de requerimientos tan sólo consiste en sostener conversaciones significativas con colegas que sean miembros bien conocidos del equipo. Pero es frecuente que en la realidad esto sea muy diferente. Los clientes o usuarios finales tal vez se encuentren en ciudades o países diferentes, quizá sólo tengan una idea vaga de lo que se requiere, puede ser que tengan opiniones en conflicto sobre el sistema que se va a elaborar, que posean un conocimiento técnico limitado o que dispongan de poco tiempo para interactuar con el ingeniero que recabará los requerimientos. Ninguna de estas posibilidades es deseable, pero todas son muy comunes y es frecuente verse forzado a trabajar con las restricciones impuestas por esta situación. PU

NT

O

CLAVE

Un participante es cualquier persona que tenga interés directo o que se beneficie del sistema que se va a desarrollar.

En las secciones que siguen se estudian las etapas requeridas para establecer las bases que permiten entender los requerimientos de software a fin de que el proyecto comience en forma tal que se mantenga avanzando hacia una solución exitosa.

5.2.1

Identificación de los participantes

Sommerville y Sawyer [Som97] definen participante como “cualquier persona que se beneficie en forma directa o indirecta del sistema en desarrollo”. Ya se identificaron los candidatos habituales: gerentes de operaciones del negocio, gerentes de producto, personal de mercadotecnia, clientes internos y externos, usuarios finales, consultores, ingenieros de producto, ingenieros de software e ingenieros de apoyo y mantenimiento, entre otros. Cada participante tiene un punto de vista diferente respecto del sistema, obtiene distintos beneficios cuando éste se desarrolla con éxito y corre distintos riesgos si fracasa el esfuerzo de construcción.

7

Las herramientas mencionadas aquí no son obligatorias sino una muestra de las que hay en esta categoría. En la

8

Este enfoque es ampliamente recomendable para proyectos que adoptan la filosofía de desarrollo de soft-

mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores. ware ágil.


21/1/10 11:00:20

C AP Í T UL O 5

107


Durante la concepción, debe hacerse la lista de personas que harán aportes cuando se recaben los requerimientos (véase la sección 5.3). La lista inicial crecerá cuando se haga contacto con los participantes porque a cada uno se le hará la pregunta: “¿A quién más piensa que debe consultarse?”

5.2.2

Cita: “Ponga a tres participantes en un cuarto y pregúnteles qué clase de sistema quieren. Es probable que escuche cuatro o más opiniones diferentes.” Anónimo

Reconocer los múltiples puntos de vista

Debido a que existen muchos participantes distintos, los requerimientos del sistema se explorarán desde muchos puntos de vista diferentes. Por ejemplo, el grupo de mercadotecnia se interesa en funciones y características que estimularán el mercado potencial, lo que hará que el nuevo sistema sea fácil de vender. Los gerentes del negocio tienen interés en un conjunto de características para que se elabore dentro del presupuesto y que esté listo para ocupar nichos de mercado definidos. Los usuarios finales tal vez quieran características que les resulten familiares y que sean fáciles de aprender y usar. Los ingenieros de software quizá piensen en funciones invisibles para los participantes sin formación técnica, pero que permitan una infraestructura que dé apoyo a funciones y características más vendibles. Los ingenieros de apoyo tal vez se centren en la facilidad del software para recibir mantenimiento. Cada uno de estos integrantes (y otros más) aportará información al proceso de ingeniería de los requerimientos. A medida que se recaba información procedente de múltiples puntos de vista, los requerimientos que surjan tal vez sean inconsistentes o estén en conflicto uno con otro. Debe clasificarse toda la información de los participantes (incluso los requerimientos inconsistentes y conflictivos) en forma que permita a quienes toman las decisiones escoger para el sistema un conjunto de requerimientos que tenga coherencia interna.

5.2.3

Trabajar hacia la colaboración

Si en un proyecto de software hay involucrados cinco participantes, tal vez se tengan cinco (o más) diferentes opiniones acerca del conjunto apropiado de requerimientos. En los primeros capítulos se mencionó que, para obtener un sistema exitoso, los clientes (y otros participantes) debían colaborar entre sí (sin pelear por insignificancias) y con los profesionales de la ingeniería de software. Pero, ¿cómo se llega a esta colaboración? El trabajo del ingeniero de requerimientos es identificar las áreas de interés común (por ejemplo, requerimientos en los que todos los participantes estén de acuerdo) y las de conflicto o incongruencia (por ejemplo, requerimientos que desea un participante, pero que están en conflicto con las necesidades de otro). Es la última categoría la que, por supuesto, representa un reto.

I NFOR MACIÓN Uso de “puntos de prioridad” Una manera de resolver requerimientos conflictivos y, al mismo tiempo, mejorar la comprensión de la importancia relativa de todos, es usar un esquema de “votación” con base en puntos de prioridad. Se da a todos los participantes cierto número de puntos de prioridad que pueden “gastarse” en cualquier número de requerimientos. Se presenta una lista de éstos y cada participante indica la importancia relativa de cada uno (desde su punto de vista)

con la asignación de uno o más puntos de prioridad. Los puntos gastados ya no pueden utilizarse otra vez. Cuando un participante agota sus puntos de prioridad, ya no tiene la posibilidad de hacer algo con los requerimientos. El total de puntos asignados a cada requerimiento por los participantes da una indicación de la importancia general de cada requerimiento.

La colaboración no significa necesariamente que todos los requerimientos los defina un comité. En muchos casos, los participantes colaboran con la aportación de su punto de vista respecto de los requerimientos, pero un influyente “campeón del proyecto” (por ejemplo, el director


21/1/10 11:00:21

108

PAR T E DOS

MO D E LADO

del negocio o un tecnólogo experimentado) toma la decisión final sobre los requerimientos que lo integrarán.

5.2.4

Hacer las primeras preguntas

Las preguntas que se hacen en la concepción del proyecto deben estar “libres del contexto” [Gau89]. El primer conjunto de ellas se centran en el cliente y en otros participantes, en las metas y beneficios generales. Por ejemplo, tal vez se pregunte:

• ¿Quién está detrás de la solicitud de este trabajo? Cita:

• ¿Quién usará la solución?

“Es mejor conocer algunas preguntas que todas las respuestas.”

• ¿Cuál será el beneficio económico de una solución exitosa? • ¿Hay otro origen para la solución que se necesita? Estas preguntas ayudan a identificar a todos los participantes con interés en el software que se

James Thurber

va a elaborar. Además, las preguntas identifican el beneficio mensurable de una implementación exitosa y las posibles alternativas para el desarrollo de software personalizado. Las preguntas siguientes permiten entender mejor el problema y hacen que el cliente exprese sus percepciones respecto de la solución:

?

• ¿Cuál sería una “buena” salida generada por una solución exitosa?

¿Cuáles preguntas ayudarían a tener un entendimiento preliminar del problema?

• ¿Qué problemas resolvería esta solución? • ¿Puede mostrar (o describir) el ambiente de negocios en el que se usaría la solución? • ¿Hay aspectos especiales del desempeño o restricciones que afecten el modo en el que se enfoque la solución? Las preguntas finales se centran en la eficacia de la actividad de comunicación en sí. Gause y Weinberg [Gau89] las llaman “metapreguntas” y proponen la siguiente lista (abreviada):

• ¿Es usted la persona indicada para responder estas preguntas? ¿Sus respuestas son Cita:

“oficiales”?

• ¿Mis preguntas son relevantes para el problema que se tiene?

“El que hace una pregunta es tonto durante cinco minutos; el que no la hace será tonto para siempre.”

• ¿Estoy haciendo demasiadas preguntas? • ¿Puede otra persona dar información adicional? • ¿Debería yo preguntarle algo más?

Proverbio chino

Estas preguntas (y otras) ayudarán a “romper el hielo” y a iniciar la comunicación, que es esencial para una indagación exitosa. Pero una reunión de preguntas y respuestas no es un enfoque que haya tenido un éxito apabullante. En realidad, la sesión de preguntas y respuestas sólo debe usarse para el primer encuentro y luego ser reemplazada por un formato de indagación de requerimientos que combine elementos de solución de problemas, negociación y especificación. En la sección 5.3 se presenta un enfoque de este tipo.

5. 3

INDAGACIÓN

DE LOS REQUERIMIENTOS

La indagación de los requerimientos (actividad también llamada recabación de los requerimientos) combina elementos de la solución de problemas, elaboración, negociación y especificación. A fin de estimular un enfoque colaborativo y orientado al equipo, los participantes trabajan juntos para identificar el problema, proponer elementos de la solución, negociar distintas visiones y especificar un conjunto preliminar de requerimientos para la solución [Zah90].9

9


En ocasiones se denomina a este enfoque técnica facilitada de especificación de la aplicación (TFEA).

21/1/10 11:00:21

C AP Í T UL O 5

5.3.1

109


Recabación de los requerimientos en forma colaborativa

Se han propuesto muchos enfoques distintos para recabar los requerimientos en forma colaborativa. Cada uno utiliza un escenario un poco diferente, pero todos son variantes de los siguientes lineamientos básicos:

?

¿Cuáles son los lineamientos básicos para conducir una reunión a fin de recabar los requerimientos en forma colaborativa?

• Tanto ingenieros de software como otros participantes dirigen o intervienen en las reuniones.

• Se establecen reglas para la preparación y participación. • Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes, pero con la suficiente informalidad para que estimule el libre flujo de ideas.

• Un “facilitador” (cliente, desarrollador o participante externo) controla la reunión. • Se utiliza un “mecanismo de definición” (que pueden ser hojas de trabajo, tablas sueltas, etiquetas adhesivas, pizarrón electrónico, grupos de conversación o foro virtual). La meta es identificar el problema, proponer elementos de la solución, negociar distintos

Cita:

enfoques y especificar un conjunto preliminar de requerimientos de la solución en una atmós-

“Dedicamos mucho tiempo —la mayor parte de todo el esfuerzo del proyecto— no a implementar o hacer pruebas, sino a tratar de decidir qué construir.”

fera que favorezca el logro de la meta. Para entender mejor el flujo de eventos conforme ocu-

Brian Lawrence

blecen el alcance del problema y la percepción general de lo que constituye una solución. Fuera

rren, se presenta un escenario breve que bosqueja la secuencia de hechos que llevan a la reunión para obtener requerimientos, a lo que sucede durante ésta y a lo que sigue después de ella. Durante la concepción (véase la sección 5.2), hay preguntas y respuestas básicas que estade estas reuniones iniciales, el desarrollador y los clientes escriben una o dos páginas de “solicitud de producto”. Se selecciona un lugar, fecha y hora para la reunión, se escoge un facilitador y se invita a asistir a integrantes del equipo de software y de otras organizaciones participantes. Antes de la fecha de la reunión, se distribuye la solicitud de producto a todos los asistentes.

WebRef La solicitud conjunta de desarrollo (SCD) es una técnica popular para recabar requerimientos. En la dirección www.carolla.com/wp-jad.htm se encuentra una buena descripción de ella.

Por ejemplo,10 considere un extracto de una solicitud de producto escrita por una persona de mercadotecnia involucrada en el proyecto CasaSegura. Esta persona escribe la siguiente narración sobre la función de seguridad en el hogar que va a ser parte de CasaSegura: Nuestras investigaciones indican que el mercado para los sistemas de administración del hogar crece a razón de 40% anual. La primera función de CasaSegura que llevemos al mercado deberá ser la de seguridad del hogar. La mayoría de la gente está familiarizada con “sistemas de alarma”, por lo que ésta deberá ser fácil de vender. La función de seguridad del hogar protegería, o reconocería, varias “situaciones” indeseables,

CONSEJO

Si un sistema o producto servirá a muchos usuarios, asegúrese de que los requerimientos se obtengan de una franja representativa de ellos. Si sólo uno define todos los requerimientos, el riesgo de no aceptación es elevado.

como acceso ilegal, incendio y niveles de monóxido de carbono, entre otros. Emplearía sensores inalámbricos para detectar cada situación. Sería programada por el propietario y telefonearía en forma automática a una agencia de vigilancia cuando detectara una situación como las descritas.

En realidad, durante la reunión para recabar los requerimientos, otros contribuirían a esta narración y se dispondría de mucha más información. Pero aun con ésta habría ambigüedad, sería probable que existieran omisiones y ocurrieran errores. Por ahora bastará la “descripción funcional” anterior. Mientras se revisa la solicitud del producto antes de la reunión, se pide a cada asistente que elabore una lista de objetos que sean parte del ambiente que rodeará al sistema, los objetos

10 Este ejemplo (con extensiones y variantes) se usa para ilustrar métodos importantes de la ingeniería de software en muchos de los capítulos siguientes. Como ejercicio, sería provechoso que el lector realizara su propia reunión para recabar requerimientos y que desarrollara un conjunto de listas para ella.


21/1/10 11:00:21

110

PAR T E DOS

MO D E LADO

que producirá éste y los que usará para realizar sus funciones. Además, se solicita a cada asistente que haga otra lista de servicios (procesos o funciones) que manipulen o interactúen con los objetos. Por último, también se desarrollan listas de restricciones (por ejemplo, costo, tamaño, reglas del negocio, etc.) y criterios de desempeño (como velocidad y exactitud). Se informa a los asistentes que no se espera que las listas sean exhaustivas, pero sí que reflejen la percepción que cada persona tiene del sistema. Entre los objetos descritos por CasaSegura tal vez estén incluidos el panel de control, detec-

Cita: “Los hechos no dejan de existir porque se les ignore.” Aldous Huxley

tores de humo, sensores en ventanas y puertas, detectores de movimiento, alarma, un evento (activación de un sensor), una pantalla, una computadora, números telefónicos, una llamada telefónica, etc. La lista de servicios puede incluir configurar el sistema, preparar la alarma, vigilar los sensores, marcar el teléfono, programar el panel de control y leer la pantalla (observe que los servicios actúan sobre los objetos). En forma similar, cada asistente desarrollará una lista de restricciones (por ejemplo, el sistema debe reconocer cuando los sensores no estén operando, debe ser amistoso con el usuario, debe tener una interfaz directa con una línea telefónica estándar, etc.) y de criterios de desempeño (un evento en un sensor debe reconocerse antes de un segundo, debe implementarse un esquema de prioridad de eventos, etcétera).

CONSEJO

Evite el impulso de desechar alguna idea de un cliente con expresiones como “demasiado costosa” o “impráctica”. La intención aquí es negociar una lista aceptable para todos. Para lograrlo, debe tenerse la mente abierta.

Las listas de objetos pueden adherirse a las paredes del cuarto con el empleo de pliegos de papel grandes o con láminas adhesivas, o escribirse en un tablero. Alternativamente, las listas podrían plasmarse en un boletín electrónico, sitio web interno o en un ambiente de grupo de conversación para revisarlas antes de la reunión. Lo ideal es que cada entrada de las listas pueda manipularse por separado a fin de combinar las listas o modificar las entradas y agregar otras. En esta etapa, están estrictamente prohibidos las críticas y el debate. Una vez que se presentan las listas individuales acerca de un área temática, el grupo crea una lista, eliminando las entradas redundantes o agregando ideas nuevas que surjan durante el análisis, pero no se elimina ninguna. Después de crear listas combinadas para todas las áreas temáticas, sigue el análisis, coordinado por el facilitador. La lista combinada se acorta, se alarga o se modifica su redacción para que refleje de manera apropiada al producto o sistema que se va a desarrollar. El objetivo es llegar a un consenso sobre la lista de objetos, servicios, restricciones y desempeño del sistema que se va a construir. En muchos casos, un objeto o servicio descrito en la lista requerirá mayores explicaciones. Para lograr esto, los participantes desarrollan miniespecificaciones para las entradas en las listas.11 Cada miniespecificación es una elaboración de un objeto o servicio. Por ejemplo, la correspondiente al objeto Panel de control de CasaSegura sería así: El panel de control es una unidad montada en un muro, sus dimensiones aproximadas son de 9 por 5 pulgadas. Tiene conectividad inalámbrica con los sensores y con una PC. La interacción con el usuario tiene lugar por medio de un tablero que contiene 12 teclas. Una pantalla de cristal líquido de 3 por 3 pulgadas brinda retroalimentación al usuario. El software hace anuncios interactivos, como eco y funciones similares.

Las miniespecificaciones se presentan a todos los participantes para que sean analizadas. Se hacen adiciones, eliminaciones y otras modificaciones. En ciertos casos, el desarrollo de las miniespecificaciones descubrirá nuevos objetos, servicios o restricciones, o requerimientos de desempeño que se agregarán a las listas originales. Durante todos los análisis, el equipo debe posponer los aspectos que no puedan resolverse en la reunión. Se conserva una lista de aspectos para volver después a dichas ideas.

11 En vez de crear una miniespecificación, muchos equipos de software eligen desarrollar escenarios del usuario llamados casos de uso. Éstos se estudian en detalle en la sección 5.4 y en el capítulo 6.


21/1/10 11:00:22

C AP Í T UL O 5

111


C ASA S EGURA Conducción de una reunión para recabar los requerimientos La escena: Sala de juntas. Está en marcha la primera reunión para recabar los requerimientos. Participantes: Jamie Lazar, integrante del equipo de software; Vinod Raman, miembro del equipo de software; Ed Robbins, miembro del equipo de software; Doug Miller, gerente de ingeniería de software; tres trabajadores de mercadotecnia; un representante de ingeniería del producto, y un facilitador. La conversación: Facilitador (apunta en un pizarrón): De modo que ésa es la lista actual de objetos y servicios para la función de seguridad del hogar.

Jamie: Sí, tanto técnicas como legales. Representante del producto: ¿Qué significa eso? Jamie: 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. Mercadotecnia: Pero lo necesitamos así… sólo asegúrense de impedir que ingrese un extraño. Ed: Eso es más fácil de decir que de hacer.

Persona de mercadotecnia: Eso la cubre, desde nuestro punto de vista.

Facilitador (interrumpe): No quiero que debatamos esto ahora. Anotémoslo como un aspecto y continuemos.

Vinod: ¿No dijo alguien que quería que toda la funcionalidad de CasaSegura fuera accesible desde internet? Eso incluiría la función de seguridad, ¿o no?

(Doug, que es el secretario de la reunión, toma debida nota.)

Persona de mercadotecnia: Sí, así es… tendremos que añadir esa funcionalidad y los objetos apropiados.

(El grupo dedica los siguientes 20 minutos a mejorar y aumentar los detalles de la función de seguridad del hogar.)

5.3.2 PU

Facilitador: ¿Agrega eso algunas restricciones?

Facilitador: Tengo la sensación de que hay más por considerar aquí.

Despliegue de la función de calidad

El despliegue de la función de calidad (DFC) es una técnica de administración de la calidad que

NT

O

CLAVE

El DFC define los requerimientos de forma que maximicen la satisfacción del cliente.

CONSEJO

Todos desean implementar muchos requerimientos emocionantes, pero hay que tener cuidado. Así es como empiezan a “quedar lisiados los requerimientos”. Pero en contrapartida, los requerimientos emocionantes llevan a un avance enorme del producto…

traduce las necesidades del cliente en requerimientos técnicos para el software. El DFC “se concentra en maximizar la satisfacción del cliente a partir del proceso de ingeniería del software” [Zul92]. Para lograr esto, el DFC pone el énfasis en entender lo que resulta valioso para el cliente y luego despliega dichos valores en todo el proceso de ingeniería. El DFC identifica tres tipos de requerimientos [Zul92]: Requerimientos normales.

Objetivos y metas que se establecen para un producto o sis-

tema durante las reuniones con el cliente. Si estos requerimientos están presentes, el cliente queda satisfecho. Ejemplos de requerimientos normales son los tipos de gráficos pedidos para aparecer en la pantalla, funciones específicas del sistema y niveles de rendimiento definidos. Requerimientos esperados.

Están implícitos en el producto o sistema y quizá sean tan

importantes que el cliente no los mencione de manera explícita. Su ausencia causará mucha insatisfacción. Algunos ejemplos de requerimientos esperados son: fácil interacción humano/máquina, operación general correcta y confiable, y facilidad para instalar el software. Requerimientos emocionantes.

Estas características van más allá de las expectativas

del cliente y son muy satisfactorias si están presentes. Por ejemplo, el software para un nuevo teléfono móvil viene con características estándar, pero si incluye capacidades inesperadas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a todos los usuarios del producto. WebRef En la dirección www.qfdi.org se encuentra información útil sobre el DFC.


Aunque los conceptos del DFC son aplicables en todo el proceso del software [Par96a], hay técnicas específicas de aquél que pueden aplicarse a la actividad de indagación de los requerimientos. El DFC utiliza entrevistas con los clientes, observación, encuestas y estudio de datos históricos (por ejemplo, reportes de problemas) como materia prima para la actividad de recabación

21/1/10 11:00:22

112

PAR T E DOS

MO D E LADO

de los requerimientos. Después, estos datos se llevan a una tabla de requerimientos —llamada tabla de la voz del cliente— que se revisa con el cliente y con otros participantes. Luego se emplean varios diagramas, matrices y métodos de evaluación para extraer los requerimientos esperados y tratar de percibir requerimientos emocionantes [Aka04].

5.3.3

Escenarios de uso

A medida que se reúnen los requerimientos, comienza a materializarse la visión general de funciones y características del sistema. Sin embargo, es difícil avanzar hacia actividades más técnicas de la ingeniería de software hasta no entender cómo emplearán los usuarios finales dichas funciones y características. Para lograr esto, los desarrolladores y usuarios crean un conjunto de escenarios que identifican la naturaleza de los usos para el sistema que se va a construir. Los escenarios, que a menudo se llaman casos de uso [Jac92], proporcionan la descripción de la manera en la que se utilizará el sistema. Los casos de uso se estudian con más detalle en la sección 5.4.

C ASA S EGURA Desarrollo de un escenario preliminar de uso La escena: Una sala de juntas, donde continúa la primera reunión para recabar los requerimientos. Participantes: Jamie Lazar, integrante del equipo de software; Vinod Raman, miembro del equipo de software; Ed Robbins, miembro del equipo de software; Doug Miller, gerente de ingeniería de software; tres personas de mercadotecnia; un representante de ingeniería del producto, y un facilitador. La conversación:

Vinod (interrumpe): La página web tendría que ser segura, encriptada, para garantizar que estuviéramos seguros y… Facilitador (interrumpe): Ésa es buena información, Vinod, pero es técnica. Centrémonos en cómo 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.

Facilitador: Hemos estado hablando sobre la seguridad para el acceso a la funcionalidad 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: ¿Qué pasa si olvido mi clave?

Jamie: ¿Cómo?

Persona de mercadotecnia: Después de que introdujera las claves, aparecería una pantalla que representaría todas las funciones de CasaSegura. Seleccionaría la función de seguridad del hogar. El sistema pediría que verificara quién 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 ésa, pero no estoy seguro.

Facilitador: Podríamos hacerlo de dos maneras, pero de momento 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 reparaciones— que no tuviera el código de seguridad. Facilitador (sonríe): Ésa 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…

5.3.4

Facilitador (interrumpe): Buena observación, Jamie, pero no entraremos a ella por ahora. Lo anotaremos y la llamaremos una excepción. Estoy seguro de que habrá otras.

(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.)

Indagación de los productos del trabajo

Los productos del trabajo generados como consecuencia de la indagación de los requerimientos variarán en función del tamaño del sistema o producto que se va a construir. Para la mayoría de sistemas, los productos del trabajo incluyen los siguientes:


21/1/10 11:00:22

C AP Í T UL O 5

?

¿Qué información se produce como consecuencia de recabar los requerimientos?


113

• Un enunciado de la necesidad y su factibilidad. • Un enunciado acotado del alcance del sistema o producto. • Una lista de clientes, usuarios y otros participantes que intervienen en la indagación de los requerimientos.

• Una descripción del ambiente técnico del sistema. • Una lista de requerimientos (de preferencia organizados por función) y las restricciones del dominio que se aplican a cada uno.

• Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o producto en diferentes condiciones de operación.

• Cualesquiera prototipos desarrollados para definir requerimientos. Cada uno de estos productos del trabajo es revisado por todas las personas que participan en la indagación de los requerimientos.

5. 4

DESARROLLO

DE CASOS DE USO

En un libro que analiza cómo escribir casos de uso eficaces, Alistair Cockburn [Coc01b] afirma que “un caso de uso capta un contrato […] [que] describe el comportamiento del sistema en distintas condiciones en las que el sistema responde a una petición de alguno de sus participantes […]”. En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias específicas. La historia puede ser un texto narrativo, un lineamiento de tareas o interacciones, una descripción basada en un formato o una representación diagramática. Sin importar su forma, un caso de uso ilustra el software o sistema desde el punto de vista del usuario final. PU

El primer paso para escribir un caso de uso es definir un conjunto de “actores” que estarán

NT

O

CLAVE

Los casos de uso se definen desde el punto de vista de un actor. Un actor es un papel que desempeñan las personas (usuarios) o los dispositivos cuando interactúan con el software.

involucrados en la historia. Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el contexto de la función y comportamiento que va a describirse. Los actores representan los papeles que desempeñan las personas (o dispositivos) cuando opera el sistema. Con una definición más formal, un actor es cualquier cosa que se comunique con el sistema o producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando utiliza el sistema. Es importante notar que un actor y un usuario final no necesariamente son lo mismo. Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras que un actor representa una clase de entidades externas (gente, con frecuencia pero no siempre) que sólo tiene un papel en el contexto del caso de uso. Por ejemplo, considere al operador de una máquina (un usuario) que interactúa con la computadora de control de una celda de manufactura que contiene varios robots y máquinas de control numérico. Después de una revisión cuidadosa de los requerimientos, el software para la computadora de control requiere cuatro diferentes modos (papeles) para la interacción: modo de programación, modo de prueba, modo de vigilancia y modo de solución de problemas. Por tanto, es posible definir cuatro actores: programador, probador, vigilante y solucionador de problemas. En ciertos casos, el operador de la máquina desempeñará todos los papeles. En otros, distintas personas tendrán el papel de cada actor.

WebRef Un artículo excelente sobre casos de uso puede descargarse desde la dirección www.ibm.com/ developerworks/ webservices/library/ codesign7.html


Debido a que la indagación de los requerimientos es una actividad evolutiva, no todos los actores son identificados en la primera iteración. En ésta es posible identificar a los actores principales [Jac92], y a los secundarios cuando se sabe más del sistema. Los actores principales interactúan para lograr la función requerida del sistema y obtienen el beneficio previsto de éste. Trabajan con el software en forma directa y con frecuencia. Los actores secundarios dan apoyo al sistema, de modo que los primarios puedan hacer su trabajo.

21/1/10 11:00:23

114

PAR T E DOS

MO D E LADO

Una vez identificados los actores, es posible desarrollar casos de uso. Jacobson [Jac92] sugiere varias preguntas12 que debe responder un caso de uso:

?

¿Qué se necesita saber a fin de desarrollar un caso de uso eficaz?

• ¿Quién es el actor principal y quién(es) el(los) secundario(s)? • ¿Cuáles son los objetivos de los actores? • ¿Qué precondiciones deben existir antes de comenzar la historia? • ¿Qué tareas o funciones principales son realizadas por el actor? • ¿Qué excepciones deben considerarse al describir la historia? • ¿Cuáles variaciones son posibles en la interacción del actor? • ¿Qué información del sistema adquiere, produce o cambia el actor? • ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo? • ¿Qué información desea obtener el actor del sistema? • ¿Quiere el actor ser informado sobre cambios inesperados? En relación con los requerimientos básicos de CasaSegura, se definen cuatro actores: propietario de la casa (usuario), gerente de arranque (tal vez la misma persona que el propietario de la casa, pero en un papel diferente), sensores (dispositivos adjuntos al sistema) y subsistema de vigilancia y respuesta (estación central que vigila la función de seguridad de la casa de CasaSegura). Para fines de este ejemplo, consideraremos sólo al actor llamado propietario de la casa. Éste interactúa con la función de seguridad de la casa en varias formas distintas con el empleo del panel de control de la alarma o con una PC:

• Introduce una clave que permita todas las demás interacciones. • Pregunta sobre el estado de una zona de seguridad. • Interroga acerca del estado de un sensor. • En una emergencia, oprime el botón de pánico. • Activa o desactiva el sistema de seguridad. Considerando la situación en la que el propietario de la casa usa el panel de control, a continuación se plantea el caso de uso básico para la activación del sistema:13 1. El propietario observa el panel de control de CasaSegura (véase la figura 5.1) para determinar si el sistema está listo para recibir una entrada. Si el sistema no está listo, se muestra el mensaje no está listo en la pantalla de cristal líquido y el propietario debe cerrar físicamente ventanas o puertas de modo que desaparezca dicho mensaje [el mensaje no está listo implica que un sensor está abierto; por ejemplo, que una puerta o ventana está abierta]. 2. El propietario usa el teclado para introducir una clave de cuatro dígitos. La clave se compara con la que guarda el sistema como válida. Si la clave es incorrecta, el panel de control emitirá un sonido una vez y se reiniciará para recibir una entrada adicional. Si la clave es correcta, el panel de control espera otras acciones. 3. El propietario selecciona y teclea permanecer o fuera (véase la figura 5.1) para activar el sistema. La entrada permanecer activa sólo sensores perimetrales (se desactivan los sensores de detección de movimiento interior). La entrada fuera activa todos los sensores. 4. Cuando ocurre una activación, el propietario observa una luz roja de alarma.

12 Las preguntas de Jacobson se han ampliado para que den una visión más completa del contenido del caso de uso. 13 Observe que este caso de uso difiere de la situación en la que se accede al sistema a través de internet. En este caso, la interacción es por medio del panel de control y no con la interfaz de usuario gráfica (GUI) que se da cuando se emplea una PC.


21/1/10 11:00:23

C AP Í T UL O 5

115


FIGURA 5.1

CASASEGURA

Panel de control de CasaSegura

alarma de comprobación de incendio

apagar

fuera permanecer instantáneo desvío no está listo

fuera permanecer

1

2

3

max

probar

desvío

4

5

6

instantáneo código repicar

activada energía

7

8

9

0

#

listo

*

pánico

CONSEJO

Es frecuente que los casos de uso se escriban de manera informal. Sin embargo, utilice el formato que se presenta aquí para asegurar que se incluyen todos los aspectos clave.

El caso de uso básico presenta una historia de alto nivel que describe la interacción entre el actor y el sistema. En muchas circunstancias, los casos de uso son más elaborados a fin de que brinden muchos más detalles sobre la interacción. Por ejemplo, Cockburn [Coc01b] sugiere el formato siguiente para hacer descripciones detalladas de casos de uso: Caso de uso:

IniciarVigilancia

Actor principal:

Propietario.

Objetivo en contexto: Preparar el sistema para que vigile los sensores cuando el propietario salga de la casa o permanezca dentro. Precondiciones:

El sistema se ha programado para recibir una clave y reconocer distintos sensores.

Disparador:

El propietario decide “preparar” el sistema, por ejemplo, para que encienda las funciones de alarma.

Escenario: 1. Propietario: observa el panel de control 2. Propietario: introduce una clave 3. Propietario: selecciona “permanecer” o “fuera” 4. Propietario: observa una luz roja de alarma que indica que CasaSegura ha sido activada. Excepciones: 1. El panel de control no está listo: el propietario verifica todos los sensores para determinar cuáles están abiertos; los cierra. 2. La clave es incorrecta (el panel de control suena una vez): el propietario introduce la clave correcta. 3. La clave no es reconocida: debe contactarse el subsistema de vigilancia y respuesta para reprogramar la clave. 4. Se elige permanecer: el panel de control suena dos veces y se enciende un letrero luminoso que dice permanecer; se activan los sensores del perímetro. 5. Se selecciona fuera: el panel de control suena tres veces y se enciende un letrero luminoso que dice fuera; se activan todos los sensores.


21/1/10 11:00:23

116

PAR T E DOS

MO D E LADO

Prioridad:

Esencial, debe implementarse

Cuándo estará disponible:

En el primer incremento

Frecuencia de uso:

Muchas veces por día

Canal para el actor:

A través de la interfaz del panel de control

Actores secundarios:

Técnico de apoyo, sensores

Canales para los actores secundarios: Técnico de apoyo: línea telefónica Sensores: interfaces cableadas y frecuencia de radio Aspectos pendientes: 1. ¿Debe haber una forma de activar el sistema sin usar clave o con una clave abreviada? 2. ¿El panel de control debe mostrar mensajes de texto adicionales? 3. ¿De cuánto tiempo dispone el propietario para introducir la clave a partir del momento en el que se oprime la primera tecla? 4. ¿Hay una forma de desactivar el sistema antes de que se active en realidad?

Los casos de uso para otras interacciones de propietario se desarrollarían en una forma similar. Es importante revisar con cuidado cada caso de uso. Si algún elemento de la interacción es ambiguo, es probable que la revisión del caso de uso lo detecte.

C ASA S EGURA Desarrollo de un diagrama de caso de uso de alto nivel La escena: Sala de juntas, continúa la reunión para recabar los requerimientos.

el caso de uso…—; ¡ah! usé el cuadrado para representar un actor que no es persona… en este caso, sensores.

Participantes: Jamie Lazar, miembro del equipo de software; Vinod Roman, integrante del equipo de software; Ed Robbins, integrante del equipo de software; Doug Miller, gerente de ingeniería de software; tres miembros de mercadotecnia; un representante de ingeniería del producto; un facilitador.

Doug: ¿Es válido eso en UML?

La conversación:

Vinod: Está bien, entonces tenemos narraciones de casos de uso para cada óvalo. ¿Necesitamos desarrollarlas con base en los formatos sobre los que he leído?

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.14 Veo que la función de seguridad 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

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 adapté las cosas un poco. No pienso que genere problemas.

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.)

14 En el apéndice 1 se presenta un breve método de aprendizaje de UML para aquellos lectores que no estén familiarizados con dicha notación.


21/1/10 11:00:24

C AP Í T UL O 5

117


FIGURA 5.2 Sistema que activa o desactiva

Diagrama de caso de uso de UML para la función de seguridad del hogar de CasaSegura

Propietario

Accede al sistema por internet

Sensores

Responde a un evento de alarma

Administrador del sistema

Encuentra una condición de error Reconfigura sensores y características del sistema relacionadas

H ERRAMIENTAS Desarrollo de un caso de uso

DE SOFTWARE

Herramientas representativas15

Objetivo: Ayudar a desarrollar casos de uso proporcionando formatos y mecanismos automatizados para evaluar la claridad y consistencia.

La gran mayoría de herramientas de análisis del modelado basadas en UML dan apoyo tanto de texto como gráfico para el desarrollo y modelado de casos de uso.

Mecánica: La mecánica de las herramientas varía. En general, las herramientas para casos de uso dan formatos con espacios en blanco para ser llenados y crear así casos eficaces. La mayor parte de la funcionalidad de los casos de uso está incrustada en un conjunto más amplio de funciones de ingeniería de los requerimientos.

Objects by Design (www.objectsbydesign.com/tools/umltools_byCompany. html) proporciona vínculos exhaustivos con herramientas de este tipo.

5. 5

ELABORACIÓN

D E L M O D E L O D E L O S R E Q U E R I M I E N T O S 16

El objetivo del modelo del análisis es describir los dominios de información, función y comportamiento que se requieren para un sistema basado en computadora. El modelo cambia en forma dinámica a medida que se aprende más sobre el sistema por construir, y otros participantes comprenden más lo que en realidad requieren. Por esa razón, el modelo del análisis es una fotografía de los requerimientos en cualquier momento dado. Es de esperar que cambie. A medida que evoluciona el modelo de requerimientos, ciertos elementos se vuelven relativamente estables, lo que da un fundamento sólido para diseñar las tareas que sigan. Sin embargo, otros elementos del modelo son más volátiles, lo que indica que los participantes todavía no entienden bien los requerimientos para el sistema. En los capítulos 6 y 7 se presentan en

15 Las herramientas mencionadas aquí no son obligatorias, sino una muestra de las que hay en esta categoría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores. 16 En este libro se usan como sinónimos las expresiones modelar el análisis y modelar los requerimientos. Ambos se refieren a representaciones de los dominios de la información, funcional y de comportamiento que describen los requerimientos del problema.


21/1/10 11:00:24

118

PAR T E DOS

MO D E LADO

detalle el modelo del análisis y los métodos que se usan para construirlo. En las secciones siguientes se da un panorama breve.

5.5.1

Elementos del modelo de requerimientos

Hay muchas formas diferentes de concebir los requerimientos para un sistema basado en computadora. Algunos profesionales del software afirman que es mejor seleccionar un modo de representación (por ejemplo, el caso de uso) y aplicarlo hasta excluir a todos los demás. Otros piensan que es más benéfico usar cierto número de modos de representación distintos para ilustrar el modelo de requerimientos. Los modos diferentes de representación fuerzan a considerar los requerimientos desde distintos puntos de vista, enfoque que tiene una probabilidad mayor de detectar omisiones, inconsistencia y ambigüedades. Los elementos específicos del modelo de requerimientos están determinados por el método de análisis de modelado (véanse los capítulos 6 y 7) que se use. No obstante, la mayoría de modelos tiene en común un conjunto de elementos generales. Elementos basados en el escenario. CONSEJO

Siempre es buena idea involucrar a los participantes. Una de las mejores formas de lograrlo es hacer que cada uno escriba casos de uso que narren el modo en el que se utilizará el software.

El sistema se describe desde el punto de vista del

usuario con el empleo de un enfoque basado en el escenario. Por ejemplo, los casos de uso básico (véase la sección 5.4) y sus diagramas correspondientes de casos de uso (véase la figura 5.2) evolucionan hacia otros más elaborados que se basan en formatos. Los elementos del modelo de requerimientos basados en el escenario con frecuencia son la primera parte del modelo en desarrollo. Como tales, sirven como entrada para la creación de otros elementos de modelado. La figura 5.3 ilustra un diagrama de actividades UML17 para indagar los requerimientos y representarlos con el empleo de casos de uso. Se aprecian tres niveles de elaboración que culminan en una representación basada en el escenario.

CONSEJO

Una forma de aislar las clases es buscar sustantivos descriptivos en un caso de usuario expresado con texto. Al menos algunos de ellos serán candidatos cercanos. Sobre esto se habla más en el capítulo 8.

Elementos basados en clases.

Cada escenario de uso implica un conjunto de objetos que

se manipulan cuando un actor interactúa con el sistema. Estos objetos se clasifican en clases: conjunto de objetos que tienen atributos similares y comportamientos comunes. Por ejemplo, para ilustrar la clase Sensor de la función de seguridad de Casa Segura (véase la figura 5.4), puede utilizarse un diagrama de clase UML. Observe que el diagrama enlista los atributos de los sensores (por ejemplo, nombre, tipo, etc.) y las operaciones (por ejemplo, identificar y permitir) que se aplican para modificarlos. Además de los diagramas de clase, otros elementos de modelado del análisis ilustran la manera en la que las clases colaboran una con otra y las relaciones e interacciones entre ellas. Esto se analiza con más detalle en el capítulo 7. Elementos de comportamiento.

El comportamiento de un sistema basado en computadora

tiene un efecto profundo en el diseño que se elija y en el enfoque de implementación que se aplique. Por tanto, el modelo de requerimientos debe proveer elementos de modelado que ilustren el comportamiento. PU

El diagrama de estado es un método de representación del comportamiento de un sistema que

NT

O

CLAVE

Un estado es un modo de comportamiento observable desde el exterior. Los estímulos externos ocasionan transiciones entre los estados.

ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado. Un estado es cualquier modo de comportamiento observable desde el exterior. Además, el diagrama de estado indica acciones (como la activación de un proceso, por ejemplo) tomadas como consecuencia de un evento en particular. Para ilustrar el uso de un diagrama de estado, considere el software incrustado dentro del panel de control de CasaSegura que es responsable de leer las entradas que hace el usuario. En la figura 5.5 se presenta un diagrama de estado UML simplificado. Además de las representaciones de comportamiento del sistema como un todo, también es posible modelar clases individuales. Sobre esto se presentan más análisis en el capítulo 7.

17 En el apéndice 1 se presenta un instructivo breve sobre UML, para aquellos lectores que no estén familiarizados con dicha notación.


21/1/10 11:00:24

C AP Í T UL O 5

119


FIGURA 5.3 Diagramas de actividad del UML para indagar los requerimientos

Efectuar reuniones Elaborar listas de funciones y clases Hacer listas de restricciones, entre otras Indagación de los requerimientos

¿Se dan prioridades formales? No

Sí Usar el DFC para asignar prioridad a los requerimientos

Dar prioridad a los requerimientos de manera informal

Definir actores Hacer un diagrama del caso de uso

Crear casos de uso

Escribir el escenario Terminar el formato

FIGURA 5.4 Diagrama de clase para un sensor

Sensor Nombre Tipo Ubicación Área Características Identificar() Activar() Desactivar() Reconfigurar()

FIGURA 5.5 Notación UML del diagrama de estado

Comandos de lectura Estado del sistema = “Listo” Mensaje en la pantalla = “introducir comando” Estado de la pantalla = estable Entrar /subsistemas listos Hacer: panel de entradas del grupo de usuarios Hacer: lectura de la entrada del usuario Hacer: interpretación de la entrada del usuario


Nombre del estado Variables del estado

Actividades del estado

21/1/10 11:00:24

120

PAR T E DOS

MO D E LADO

C ASA S EGURA Modelado preliminar del comportamiento La escena: Sala de juntas, continúa la reunión de requerimientos.

Persona de mercadotecnia: Esto parece un poco técnico. No estoy seguro de ser de ayuda aquí.

Participantes: Jamie Lazar, integrante del equipo de software; Vinod Raman, miembro del equipo de software; Ed Robbins, integrante del equipo de software; Doug Miller, gerente de ingeniería de software; tres trabajadores de mercadotecnia; un representante de ingeniería del producto, y un facilitador.

Facilitador: Seguro que lo serás. ¿Qué comportamiento se observa desde el punto de vista de un usuario?

La conversación:

Facilitador: ¿Ves?, lo puedes hacer.

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.

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.

Persona de mercadotecnia: No entiendo lo que quiere decir con comportamiento.

Vinod: Sí, en realidad, configurar el sistema es un estado por derecho propio.

Ed (sonríe): Es cuando le das un “tiempo fuera” al producto si se porta mal.

Doug: Muchachos, lo hacen bien. Pensemos un poco más... ¿hay alguna forma de hacer un diagrama de todo esto?

Facilitador: No exactamente. Permítanme explicarlo.

Facilitador: Sí la hay, pero la dejaremos para la próxima reunión.

Persona de mercadotecnia: Mmm... bueno, el sistema estará vigilando los sensores. Leerá comandos del propietario. Mostrará su estado.

(El facilitador explica al equipo encargado de recabar los requerimientos y los fundamentos de modelado del comportamiento.)

Elementos orientados al flujo.

La información se transforma cuando fluye a través de un

sistema basado en computadora. El sistema acepta entradas en varias formas, aplica funciones para transformarla y produce salidas en distintos modos. La entrada puede ser una señal de control transmitida por un transductor, una serie de números escritos con el teclado por un operador humano, un paquete de información enviado por un enlace de red o un archivo grande de datos recuperado de un almacenamiento secundario. La transformación quizá incluya una sola comparación lógica, un algoritmo numérico complicado o un enfoque de regla de inferencia para un sistema experto. La salida quizá encienda un diodo emisor de luz o genere un informe de 200 páginas. En efecto, es posible crear un modelo del flujo para cualquier sistema basado en computadora, sin importar su tamaño y complejidad. En el capítulo 7 se hace un análisis más detallado del modelado del flujo.

5.5.2

Patrones de análisis

Cualquiera que haya hecho la ingeniería de los requerimientos en varios proyectos de software ha observado que ciertos problemas son recurrentes en todos ellos dentro de un dominio de aplicación específico.18 Estos patrones de análisis [Fow97] sugieren soluciones (por ejemplo, una clase, función o comportamiento) dentro del dominio de la aplicación que pueden volverse a utilizar cuando se modelen muchas aplicaciones. Geyer-Schulz y Hahsler [Gey01] sugieren dos beneficios asociados con el uso de patrones de análisis: En primer lugar, los patrones de análisis aceleran el desarrollo de los modelos de análisis abstracto que capturan los principales requerimientos del problema concreto, debido a que proveen modelos de análisis reutilizables con ejemplos, así como una descripción de sus ventajas y limitaciones. En se-

18 En ciertos casos, los problemas vuelven a suceder sin importar el dominio de la aplicación. Por ejemplo, son comunes las características y funciones usadas para resolver problemas de la interfaz de usuario sin importar el dominio de la aplicación en consideración.


21/1/10 11:00:25

C AP Í T UL O 5

121


gundo lugar, los patrones de análisis facilitan la transformación del modelo de análisis en un modelo del diseño, sugiriendo patrones de diseño y soluciones confiables para problemas comunes.

Los patrones de análisis se integran en el modelo del análisis, haciendo referencia al nombre del patrón. También se guardan en un medio de almacenamiento de modo que los ingenieros de requerimientos usen herramientas de búsqueda para encontrarlos y aplicarlos. La información sobre el patrón de análisis (y otros tipos de patrones) se presenta en un formato estándar [Gey01]19 que se estudia con más detalle en el capítulo 12. En el capítulo 7 se dan ejemplos de patrones de análisis y más detalles de este tema.

5. 6

REQUERIMIENTOS

DE LAS NEGOCIACIONES

En un contexto ideal de la ingeniería de los requerimientos, las tareas de concepción, indagación y elaboración determinan los requerimientos del cliente con suficiente detalle como para

Cita:

avanzar hacia las siguientes actividades de la ingeniería de software. Desafortunadamente, esto

“Un compromiso es el arte de dividir un pastel en forma tal que todos crean que tienen el trozo mayor.”

rara vez ocurre. En realidad, se tiene que entrar en negociaciones con uno o varios participantes. En la mayoría de los casos, se pide a éstos que evalúen la funcionalidad, desempeño y otras características del producto o sistema, en contraste con el costo y el tiempo para entrar al mercado. El objetivo de esta negociación es desarrollar un plan del proyecto que satisfaga las necesidades del participante y que al mismo tiempo refleje las restricciones del mundo real (por

Ludwig Erhard

ejemplo, tiempo, personas, presupuesto, etc.) que se hayan establecido al equipo del software. Las mejores negociaciones buscan un resultado “ganar-ganar”.20 Es decir, los participantes ganan porque obtienen el sistema o producto que satisface la mayoría de sus necesidades y

WebRef Un artículo breve sobre la negociación para los requerimientos de software puede descargarse desde la dirección www.alexander-egyed.com/ publications/Software_ Requirements_NegotiationSome_Lessons_Learned.html

usted (como miembro del equipo de software) gana porque trabaja con presupuestos y plazos realistas y asequibles. Boehm [Boe98] define un conjunto de actividades de negociación al principio de cada iteración del proceso de software. En lugar de una sola actividad de comunicación con el cliente, se definen las actividades siguientes: 1. Identificación de los participantes clave del sistema o subsistema. 2. Determinación de las “condiciones para ganar” de los participantes.

I NFOR MACIÓN El arte de la negociación Aprender a negociar con eficacia le servirá en su vida personal y técnica. Es útil considerar los lineamientos que siguen: 1.

2.

3.

4.

Reconocer que no es una competencia. Para tener éxito, ambas partes tienen que sentir que han ganado o logrado algo. Las dos tienen que llegar a un compromiso. Mapear una estrategia. Decidir qué es lo que le gustaría lograr; qué quiere obtener la otra parte y cómo hacer para que ocurran las dos cosas. Escuchar activamente. No trabaje en la formulación de su respuesta mientras la otra parte esté hablando. Escúchela. Es pro-

5. 6. 7.

bable que obtenga conocimientos que lo ayuden a negociar mejor su posición. Centrarse en los intereses de la otra parte. Si quiere evitar conflictos, no adopte posiciones inamovibles. No lo tome en forma personal. Céntrese en el problema que necesita resolverse. Sea creativo. Si están empantanados, no tenga miedo de pensar fuera de los moldes. Esté listo para comprometerse. Una vez que se llegue a un acuerdo, no titubee; comprométase con él y cúmplalo.

19 En la bibliografía existen varias propuestas de formatos para patrones. Si el lector tiene interés, consulte [Fow97], [Gam95], [Yac03] y [Bus07], entre muchas otras fuentes. 20 Se han escrito decenas de libros acerca de las aptitudes para negociar (por ejemplo [Lew06], [Rai06] y [Fis06]). Es una de las aptitudes más importantes que pueda aprender. Lea alguno.


21/1/10 11:00:25

122

PAR T E DOS

MO D E LADO

3. Negociación de las condiciones para ganar de los participantes a fin de reconciliarlas en un conjunto de condiciones ganar-ganar para todos los que intervienen (incluso el equipo de software). La realización exitosa de estos pasos iniciales lleva a un resultado ganar-ganar, que se convierte en el criterio clave para avanzar hacia las siguientes actividades de la ingeniería de software.

C ASA S EGURA El principio de una negociación La escena: 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. La conversación: Lisa: Pues escuché que la primera reunión salió realmente bien. Doug: En realidad, sí. Enviaste buenos representantes... contribuyeron de verdad. Lisa (sonríe): Sí; 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 aseguraré 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: Doug, es el acceso por internet lo que da a CasaSegura su “súper” atractivo. Toda nuestra campaña de publicidad va a girar alrededor de eso. Lo tenemos que tener… Doug: Entiendo la situación, de verdad. El 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 de seguridad del hogar y también para otras… éstas 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?

Lisa (con el ceño fruncido): Lo debemos tener para esa fecha, Doug. ¿De qué funcionalidad hablas? Doug: Supongo que podemos tener la funcionalidad completa en la fecha establecida, pero tendríamos que retrasar el acceso por internet hasta el segundo incremento.

5. 7

VA L I D A C I Ó N


A medida que se crea cada elemento del modelo de requerimientos, se estudia para detectar inconsistencias, omisiones y ambigüedades. Los participantes asignan prioridades a los requerimientos representados por el modelo y se agrupan en paquetes de requerimientos que se implementarán como incrementos del software. La revisión del modelo de requerimientos aborda las preguntas siguientes:

?

Cuando se revisan los requerimientos, ¿qué preguntas deben plantearse?

• ¿Es coherente cada requerimiento con los objetivos generales del sistema o producto? • ¿Se han especificado todos los requerimientos en el nivel apropiado de abstracción? Es decir, ¿algunos de ellos tienen un nivel de detalle técnico que resulta inapropiado en esta etapa?

• El requerimiento, ¿es realmente necesario o representa una característica agregada que tal vez no sea esencial para el objetivo del sistema?

• ¿Cada requerimiento está acotado y no es ambiguo? • ¿Tiene atribución cada requerimiento? Es decir, ¿hay una fuente (por lo general una individual y específica) clara para cada requerimiento?

• ¿Hay requerimientos en conflicto con otros?


21/1/10 11:00:25

C AP Í T UL O 5


123

• ¿Cada requerimiento es asequible en el ambiente técnico que albergará el sistema o producto?

• Una vez implementado cada requerimiento, ¿puede someterse a prueba? • El modelo de requerimientos, ¿refleja de manera apropiada la información, la función y el comportamiento del sistema que se va a construir?

• ¿Se ha “particionado” el modelo de requerimientos en forma que exponga información cada vez más detallada sobre el sistema?

• ¿Se ha usado el patrón de requerimientos para simplificar el modelo de éstos? ¿Se han validado todos los patrones de manera apropiada? ¿Son consistentes todos los patrones con los requerimientos del cliente? Éstas y otras preguntas deben plantearse y responderse para garantizar que el modelo de requerimientos es una reflexión correcta sobre las necesidades del participante y que provee un fundamento sólido para el diseño.

5. 8

RESUMEN Las tareas de la ingeniería de requerimientos se realizan para establecer un fundamento sólido para el diseño y la construcción. La ingeniería de requerimientos ocurre durante las actividades de comunicación y modelado que se hayan definido para el proceso general del software. Los miembros del equipo de software llevan a cabo siete funciones de ingeniería de requerimientos: concepción, indagación, elaboración, negociación, especificación, validación y administración. En la concepción del proyecto, los participantes establecen los requerimientos básicos del problema, definen las restricciones generales del proyecto, así como las características y funciones principales que debe presentar el sistema para cumplir sus objetivos. Esta información se mejora y amplía durante la indagación, actividad en la que se recaban los requerimientos y que hace uso de reuniones que lo facilitan, DFC y el desarrollo de escenarios de uso. La elaboración amplía aún más los requerimientos en un modelo: una colección de elementos basados en escenarios, clases y comportamiento, y orientados al flujo. El modelo hace referencia a patrones de análisis: soluciones para problemas de análisis que se ha observado que son recurrentes en diferentes aplicaciones. Conforme se identifican los requerimientos y se crea su modelo, el equipo de software y otros participantes negocian la prioridad, la disponibilidad y el costo relativo de cada requerimiento. Además, se valida cada requerimiento y su modelo como un todo comparado con las necesidades del cliente a fin de garantizar que va a construirse el sistema correcto.

PROBLEMAS


5.1. ¿Por qué muchos desarrolladores de software no ponen atención suficiente a la ingeniería de requerimientos? ¿Existen algunas circunstancias que puedan ignorarse? 5.2. El lector tiene la responsabilidad de indagar los requerimientos de un cliente que dice estar demasiado ocupado para tener una reunión. ¿Qué debe hacer? 5.3. Analice algunos de los problemas que ocurren cuando los requerimientos deben indagarse para tres o cuatro clientes distintos. 5.4. ¿Por qué se dice que el modelo de requerimientos representa una fotografía instantánea del sistema en el tiempo? 5.5. Suponga que ha convencido al cliente (es usted muy buen vendedor) para que esté de acuerdo con todas las demandas que usted hace como desarrollador. ¿Eso lo convierte en un gran negociador? ¿Por qué?


21/1/10 11:00:26

124

PAR T E DOS

MO D E LADO

5.6. Desarrolle al menos tres “preguntas libres de contexto” adicionales que podría plantear a un participante durante la concepción. 5.7. Desarrolle un “kit” para recabar requerimientos. Debe incluir un conjunto de lineamientos a fin de llevar a cabo la reunión para recabar requerimientos y los materiales que pueden emplearse para facilitar la creación de listas y otros objetos que ayuden a definir los requerimientos. 5.8. Su profesor formará grupos de cuatro a seis estudiantes. La mitad de ellos desempeñará el papel del departamento de mercadotecnia y la otra mitad adoptará el del equipo para la ingeniería de software. Su trabajo es definir los requerimientos para la función de seguridad de CasaSegura descrita en este capítulo. Efectúe una reunión para recabar los requerimientos con el uso de los lineamientos presentados en este capítulo. 5.9. Desarrolle un caso de uso completo para una de las actividades siguientes: a) b) c) d) e)

Hacer un retiro de efectivo en un cajero automático. Usar su tarjeta de crédito para pagar una comida en un restaurante. Comprar acciones en la cuenta en línea de una casa de bolsa. Buscar libros (sobre un tema específico) en una librería en línea. La actividad que especifique su profesor.

5.10. ¿Qué representan las “excepciones” en un caso de uso? 5.11. Describa con sus propias palabras lo que es un patrón de análisis. 5.12. Con el formato presentado en la sección 5.5.2, sugiera uno o varios patrones de análisis para los siguientes dominios de aplicación: a) b) c) d) e) f)

Software de contabilidad. Software de correo electrónico. Navegadores de internet. Software de procesamiento de texto. Software para crear un sitio web. El dominio de aplicación que diga su profesor.

5.13. ¿Qué significa ganar-ganar en el contexto de una negociación durante la actividad de ingeniería de los requerimientos? 5.14. ¿Qué piensa que pasa cuando la validación de los requerimientos detecta un error? ¿Quién está involucrado en su corrección?

LECTURAS


La ingeniería de requerimientos se estudia en muchos libros debido a su importancia crítica para la creación exitosa de cualquier sistema basado en computadoras. Hood et al. (Requirements Management, Springer, 2007) analizan varios aspectos de la ingeniería de los requerimientos que incluyen tanto la ingeniería de sistemas como la de software. Young (The Requirements Engineering Handbook, Artech House Publishers, 2007) presenta un análisis profundo de las tareas de la ingeniería de requerimientos. Wiegers (More About Software Requirements, Microsoft Press, 2006) menciona muchas técnicas prácticas para recabar y administrar los requerimientos. Hull et al. (Requirements Engineering, 2a. ed., Springer-Verlag, 2004), Bray (An Introduction to Requirements Engineering, Addison-Wesley, 2002), Arlow (Requirements Engineering, Addison-Wesley, 2001), Gilb (Requirements Engineering, Addison-Wesley, 2000), Graham (Requirements Engineering and Rapid Development, Addison-Wesley, 1999) y Sommerville y Kotonya (Requirement Engineering: Processes and Techniques, Wiley, 1998) son sólo algunos de los muchos libros dedicados al tema. Gottesdiener (Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002) proporciona una guía útil para quienes deben generar un ambiente de colaboración a fin de recabar los requerimientos con los participantes. Lauesen (Software Requirements: Styles and Techniques, Addison-Wesley, 2002) presenta una recopilación exhaustiva de los métodos y notación para el análisis de requerimientos. Weigers (Software Requirements, Microsoft Press, 1999) y Leffingwell et al. (Managing Software Requirements: A Use Case Approach, 2a. ed., Addison-Wesley, 2003) presentan una colección útil de las mejores prácticas respecto de los requerimientos y sugieren lineamientos prácticos para la mayoría de los aspectos del proceso de su ingeniería.


21/1/10 11:00:26

C AP Í T UL O 5


125

En Withall (Software Requirement Patterns, Microsoft Press, 2007) se describe la ingeniería de requerimientos desde un punto de vista basado en los patrones. Ploesch (Assertions, Scenarios and Prototypes, SpringerVerlag, 2003) analiza técnicas avanzadas para desarrollar requerimientos de software. Windle y Abreo (Software Requirements Using the Unified Process, Prentice-Hall, 2002) estudian la ingeniería de los requerimientos en el contexto del proceso unificado y la notación UML. Alexander y Steven (Writing Better Requirements, Addison-Wesley, 2002) presentan un conjunto abreviado de lineamientos para escribir requerimientos claros, representarlos como escenarios y revisar el resultado final. Es frecuente que el modelado de un caso de uso sea el detonante para crear todos los demás aspectos del modelo de análisis. El tema lo estudian mucho Rosenberg y Stephens (Use Case Driven Object Modeling with UML: Theory and Practice, Apress, 2007), Denny (Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley, 2005), Alexander y Maiden (eds.) (Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Wiley, 2004), Leffingwell et al. (Managing Software Requirements: A Use Case Approach, 2a. ed., Addison-Wesley, 2003) presentan una colección útil de las mejores prácticas sobre los requerimientos. Bittner y Spence (Use Case Modeling, Addison-Wesley, 2002), Cockburn [Coc01], Armour y Miller (Advanced Use Cases Modeling: Software Systems, Addison-Wesley, 2000) y Kulak et al. (Use Cases: Requirements in Context, Addison-Wesley, 2000) estudian la obtención de requerimientos con énfasis en el modelado del caso de uso. En internet hay una variedad amplia de fuentes de información acerca de la ingeniería y análisis de los requerimientos. En el sitio web del libro, www.mhhe.com/engcs/compsi/pressman/professional/ olc/ser.htm, se halla una lista actualizada de referencias en web que son relevantes para la ingeniería y análisis de los requerimientos.


21/1/10 11:00:26

CAPÍTULO

6 CONCEPTOS

MODELADO

DE LOS REQUERIMIENTOS :

ESCENARIOS , INFORMACIÓN Y CLASES DE ANÁLISIS

CLAVE

análisis del dominio . . . . . . . 129 análisis gramatical . . . . . . . 143 asociaciones . . . . . . . . . . . . 152

n el nivel técnico, la ingeniería de software comienza con una serie de tareas de modelado

E

que conducen a la especificación de los requerimientos y a la representación de un diseño del software que se va a elaborar. El modelo de requerimientos1 —un conjunto de mode-

los, en realidad— es la primera representación técnica de un sistema. En un libro fundamental sobre métodos para modelar los requerimientos, Tom DeMarco

casos de uso . . . . . . . . . . . . 132 clases de análisis. . . . . . . . . 143

[DeM79] describe el proceso de la manera siguiente:

diagrama de actividades . . . 137

Al mirar retrospectivamente los problemas y las fallas detectados en la fase de análisis, concluyo que

diagrama de canal . . . . . . . . 138

es necesario agregar lo siguiente al conjunto de objetivos de dicha fase. Debe ser muy fácil dar man-

modelado basado en clases . . . . . . . . . . . . . . 142

tenimiento a los productos del análisis. Esto se aplica en particular al Documento de Objetivos [espe-

modelado basado en escenarios . . . . . . . . . . . 131

empleo de un método eficaz para dividirlos. La especificación victoriana original resulta caduca. De-

cificación de los requerimientos del software]. Los problemas grandes deben ser enfrentados con el ben usarse gráficas, siempre que sea posible. Es necesario diferenciar las consideraciones lógicas

modelado CRC. . . . . . . . . . . 148

[esenciales] y las físicas [implementación]… Finalmente, se necesita… algo que ayude a dividir los

modelado de datos . . . . . . . 139

requerimientos y a documentar dicha partición antes de elaborar la especificación… algunos medios

modelado de requerimientos . . . . . . . . . . 130

para dar seguimiento a las interfaces y evaluarlas… nuevas herramientas para describir la lógica y la política, algo mejor que un texto narrativo.

modelos UML . . . . . . . . . . . 137 paquetes de análisis . . . . . . 154

UNA ¿Qué es? La palabra escrita es un vehículo maravilloso para la comunicación, pero no RÁPIDA necesariamente es la mejor forma de representar los requerimientos de software de computadora. El modelado de los requerimientos utiliza una combinación de texto y diagramas para ilustrarlos en forma que sea relativamente fácil de entender y, más importante, de revisar para corregir, completar y hacer congruente. ¿Quién lo hace? Un ingeniero de software (a veces llamado “analista”) construye el modelo con el uso de los requerimientos recabados del cliente. ¿Por qué es importante? Para validar los requerimientos del software se necesita estudiarlos desde varios puntos de vista diferentes. En este capítulo se considerará el modelado de los requerimientos desde tres perspectivas distintas: modelos basados en el escenario, modelos de datos (información) y modelos basados en la clase. Cada una representa a los requerimientos en una “dimensión” diferente, con lo que aumenta la probabilidad de detectar errores, de que afloren las inconsistencias y de que se revelen las omisiones. ¿Cuáles son los pasos? El modelado basado en escenarios es una representación del sistema desde el punto de

MIRADA

1

vista del usuario. El modelado basado en datos recrea el espacio de información e ilustra los objetos de datos que manipulará el software y las relaciones entre ellos. El modelado orientado a clases define objetos, atributos y relaciones. Una vez que se crean los modelos preliminares, se mejoran y analizan para evaluar si están claros y completos, y si son consistentes. En el capítulo 7 se amplían con representaciones adicionales las dimensiones del modelado descritas aquí, lo que da un punto de vista más sólido de los requerimientos. ¿Cuál es el producto final? Para construir el modelo de requerimientos, se escoge una amplia variedad de representaciones basadas en texto y en diagramas. Cada una de dichas representaciones da una perspectiva de uno o más de los elementos del modelo. ¿Cómo me aseguro de que lo hice bien? Los productos del trabajo para modelar los requerimientos deben revisarse para saber si son correctos, completos y consistentes. Deben reflejar las necesidades de todos los participantes y establecer el fundamento desde el que se realizará el diseño.

En ediciones anteriores de este libro, se usó el término modelo de análisis, en lugar de modelo de requerimientos. En esta edición, el autor decidió usar ambas expresiones para designar la actividad que define distintos aspectos del problema por resolver. Análisis es lo que ocurre cuando se obtienen los requerimientos.

126


14/1/10 14:29:14

C AP Í T UL O 6

127

MODELADO DE LOS REQ U ERIMIENT OS

Aunque DeMarco escribió hace más de un cuarto de siglo acerca de los atributos del modelado del análisis, sus comentarios aún son aplicables a los métodos y notación modernos del modelado de los requerimientos.

6. 1

ANÁLISIS


El análisis de los requerimientos da como resultado la especificación de las características operativas del software, indica la interfaz de éste y otros elementos del sistema, y establece las restricciones que limitan al software. El análisis de los requerimientos permite al profesional (sin importar si se llama ingeniero de software, analista o modelista) construir sobre los requerimientos básicos establecidos durante las tareas de concepción, indagación y negociación, que son parte de la ingeniería de los requerimientos (véase el capítulo 5). La acción de modelar los requerimientos da como resultado uno o más de los siguientes tipos

Cita: “Cualquier ‘vista’ de los requerimientos es insuficiente para entender o describir el comportamiento deseado de un sistema complejo.” Alan M. Davis

de modelo:

• Modelos basados en el escenario de los requerimientos desde el punto de vista de distintos “actores” del sistema.

• Modelos de datos, que ilustran el dominio de información del problema. • Modelos orientados a clases, que representan clases orientadas a objetos (atributos y operaciones) y la manera en la que las clases colaboran para cumplir con los requerimientos del sistema.

• Modelos orientados al flujo, que representan los elementos funcionales del sistema y la manera como transforman los datos a medida que se avanza a través del sistema.

• Modelos de comportamiento, que ilustran el modo en el que se comparte el software como consecuencia de “eventos” externos. PU

Estos modelos dan al diseñador del software la información que se traduce en diseños de arqui-

NT

O

CLAVE

El modelo de análisis y la especificación de requerimientos proporcionan un medio para evaluar la calidad una vez construido el software.

tectura, interfaz y componentes. Por último, el modelo de requerimientos (y la especificación de requerimientos de software) brinda al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software. Este capítulo se centra en el modelado basado en escenarios, técnica que cada vez es más popular entre la comunidad de la ingeniería de software; el modelado basado en datos, más especializado, apropiado en particular cuando debe crearse una aplicación o bien manipular un espacio complejo de información; y el modelado orientado a clases, representación de las clases orientada a objetos y a las colaboraciones resultantes que permiten que funcione el sistema. En

FIGURA 6.1 El modelo de requerimientos como puente entre la descripción del sistema y el modelo del diseño

Descripción del sistema

Modelo del análisis Modelo del diseño


14/1/10 14:29:15

128

PAR T E DOS

MO D E LADO

el capítulo 7 se analizan los modelos orientados al flujo, al comportamiento, basados en el patrón y en webapps.

6.1.1

Objetivos y filosofía general

Durante el modelado de los requerimientos, la atención se centra en qué, no en cómo. ¿Qué

Cita: “Los requerimientos no son arquitectura. No son diseño ni la interfaz de usuario. Los requerimientos son las necesidades.” Andrew Hunt y David Thomas

interacción del usuario ocurre en una circunstancia particular?, ¿qué objetos manipula el sistema?, ¿qué funciones debe realizar el sistema?, ¿qué comportamientos tiene el sistema?, ¿qué interfaces se definen? y ¿qué restricciones son aplicables?2 En los capítulos anteriores se dijo que en esta etapa tal vez no fuera posible tener la especificación completa de los requerimientos. El cliente quizá no esté seguro de qué es lo que requiere con precisión para ciertos aspectos del sistema. Puede ser que el desarrollador esté inseguro de que algún enfoque específico cumpla de manera apropiada la función y el desempeño. Estas realidades hablan a favor de un enfoque iterativo para el análisis y el modelado de los requerimientos. El analista debe modelar lo que se sabe y usar el modelo como base para el diseño del incremento del software.3

PU

El modelo de requerimientos debe lograr tres objetivos principales: 1) describir lo que re-

NT

O

CLAVE

El modelo de análisis debe describir lo que quiere el cliente, establecer una base para el diseño y un objetivo para la validación.

quiere el cliente, 2) establecer una base para la creación de un diseño de software y 3) definir un conjunto de requerimientos que puedan validarse una vez construido el software. El modelo de análisis es un puente entre la descripción en el nivel del sistema que se centra en éste en lo general o en la funcionalidad del negocio que se logra con la aplicación de software, hardware, datos, personas y otros elementos del sistema y un diseño de software (véanse los capítulos 8 a 13) que describa la arquitectura de la aplicación del software, la interfaz del usuario y la estructura en el nivel del componente. Esta relación se ilustra en la figura 6.1. Es importante observar que todos los elementos del modelo de requerimientos pueden rastrearse directamente hasta las partes del modelo del diseño. No siempre es posible la división clara entre las tareas del análisis y las del diseño en estas dos importantes actividades del modelado. Invariablemente, ocurre algo de diseño como parte del análisis y algo de análisis se lleva a cabo durante el diseño.

6.1.2

Reglas prácticas del análisis

Arlow y Neustadt [Arl02] sugieren cierto número de reglas prácticas útiles que deben seguirse cuando se crea el modelo del análisis:

?

• El modelo debe centrarse en los requerimientos que sean visibles dentro del problema o

¿Hay lineamientos básicos que nos ayuden a hacer el trabajo de análisis de los requerimientos?

dentro del dominio del negocio. El nivel de abstracción debe ser relativamente elevado. “No se empantane en los detalles” [Arl02] que traten de explicar cómo funciona el sistema.

• Cada elemento del modelo de requerimientos debe agregarse al entendimiento general de los requerimientos del software y dar una visión del dominio de la información, de la función y del comportamiento del sistema.

• Hay que retrasar las consideraciones de la infraestructura y otros modelos no funcionales hasta llegar a la etapa del diseño. Es decir, quizá se requiera una base de datos, pero las clases necesarias para implementarla, las funciones requeridas para acceder a ella y el comportamiento que tendrá cuando se use sólo deben considerarse después de que se haya terminado el análisis del dominio del problema.

2

Debe notarse que, a medida que los clientes tienen más conocimientos tecnológicos, hay una tendencia hacia la especificación del cómo tanto como del qué. Sin embargo, la atención debe centrarse en el qué.

3

En un esfuerzo por entender mejor los requerimientos para el sistema, el equipo del software tiene la alternativa de escoger la creación de un prototipo (véase el capítulo 2).


14/1/10 14:29:15

C AP Í T UL O 6

129


• Debe minimizarse el acoplamiento a través del sistema. Es importante representar las rela-

Cita:

ciones entre las clases y funciones. Sin embargo, si el nivel de “interconectividad” es extremadamente alto, deben hacerse esfuerzos para reducirlo.

“Los problemas que es benéfico atacar demuestran su beneficio con un contragolpe.”

• Es seguro que el modelo de requerimientos agrega valor para todos los participantes. Cada actor tiene su propio uso para el modelo. Por ejemplo, los participantes de negocios deben usar el modelo para validar los requerimientos; los diseñadores deben usarlo

Piet Hein

como pase para el diseño; el personal de aseguramiento de la calidad lo debe emplear como ayuda para planear las pruebas de aceptación.

• Mantener el modelo tan sencillo como se pueda. No genere diagramas adicionales si no agregan nueva información. No utilice notación compleja si basta una sencilla lista.

6.1.3 WebRef En la dirección www.iturls.com/ English/SoftwareEngineering/ SE_mod5.asp, existen muchos recursos útiles para el análisis del dominio.

Análisis del dominio

Al estudiar la ingeniería de requerimientos (en el capítulo 5), se dijo que es frecuente que haya patrones de análisis que se repiten en muchas aplicaciones dentro de un dominio de negocio específico. Si éstos se definen y clasifican en forma tal que puedan reconocerse y aplicarse para resolver problemas comunes, la creación del modelo del análisis es más expedita. Más importante aún es que la probabilidad de aplicar patrones de diseño y componentes de software ejecutable se incrementa mucho. Esto mejora el tiempo para llegar al mercado y reduce los costos de desarrollo. Pero, ¿cómo se reconocen por primera vez los patrones de análisis y clases? ¿Quién los define, clasifica y prepara para usarlos en los proyectos posteriores? La respuesta a estas preguntas está en el análisis del dominio. Firesmith [Fir93] lo describe del siguiente modo:

PU

El análisis del dominio del software es la identificación, análisis y especificación de los requerimientos

NT

O

comunes, a partir de un dominio de aplicación específica, normalmente para usarlo varias veces en

CLAVE

El análisis del dominio no busca en una aplicación específica, sino en el dominio en el que reside la aplicación. El objetivo es identificar elementos comunes para la solución de problemas, que sean útiles en todas las aplicaciones dentro del dominio.

múltiples proyectos dentro del dominio de la aplicación […] [El análisis del dominio orientado a objetos es] la identificación, análisis y especificación de capacidades comunes y reutilizables dentro de un dominio de aplicación específica en términos de objetos, clases, subensambles y estructuras comunes.

El “dominio de aplicación específica” se extiende desde el control electrónico de aviones hasta la banca, de los juegos de video en multimedios al software incrustado en equipos médicos. La meta del análisis del dominio es clara: encontrar o crear aquellas clases o patrones de análisis que sean aplicables en lo general, de modo que puedan volverse a usar.4 Con el empleo de la terminología que se introdujo antes en este libro, el análisis del dominio puede considerarse como una actividad sombrilla para el proceso del software. Esto significa que el análisis del dominio es una actividad de la ingeniería de software que no está conectada

FIGURA 6.2 Entradas y salidas para el análisis del dominio

Bibliografía técnica

Taxonomías de clase

Aplicaciones existentes Fuentes de conocimiento del dominio

Encuestas a clientes Consejo de expertos Requerimientos actuales y futuros

4

Estándares de reutilización

Análisis del dominio

Modelos funcionales Lenguajes del dominio

Modelo de análisis del dominio

Un punto de vista complementario del análisis del dominio “involucra el modelado de éste, de manera que los ingenieros del software y otros participantes aprendan más al respecto […] no todas las clases de dominio necesariamente dan como resultado el desarrollo de clases reutilizables […]” [Let03a].


14/1/10 14:29:16

130

PAR T E DOS

MO D E LADO

C ASA S EGURA Análisis del dominio La escena: Oficina de Doug Miller, después de una reunión con personal de mercadotecnia. Participantes: Doug Miller, gerente de ingeniería de software, y Vinod Raman, miembro del equipo de ingeniería de software. 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. Doug (con una sonrisa tenue): Lo sé, pero los plazos son tan breves que decidí comenzar ya la estrategia con mercadotecnia… de cualquier modo, revisaremos cualquier plan tentativo una vez que tengamos la información de todas las juntas que se efectuarán para recabar los requerimientos.

Vinod: 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 seguro 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 hiciéramos iguales… ¿por qué no las hacemos así? Doug: Ah… es grato tener gente que piense como lo haces tú. Ése 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, qué quieres?, ¿clases, patrones de análisis, patrones de diseño? Doug: Todo eso. Nada formal en este momento. Sólo quiero que comencemos despacio con nuestros trabajos de análisis interno y de diseño.

Vinod: Está bien, ¿entonces? ¿Qué quieres que haga?

Vinod: Iré a nuestra biblioteca de clases y veré qué tenemos. También usaré un formato de patrones que vi en un libro que leí hace unos meses.

Doug: ¿Sabes qué es el “análisis del dominio”?

Doug: Bien. Manos a la obra.

con ningún proyecto de software. En cierta forma, el papel del analista del dominio es similar al de un maestro herrero en un ambiente de manufactura pesada. El trabajo del herrero es diseñar y fabricar herramientas que utilicen muchas personas que hacen trabajos similares pero no necesariamente iguales. El papel del analista de dominio5 es descubrir y definir patrones de análisis, clases de análisis e información relacionada que pueda ser utilizada por mucha gente

Cita: “… el análisis es frustrante, está lleno de relaciones interpersonales complejas, indefinidas y difíciles. En una palabra, es fascinante. Una vez atrapado, los antiguos y fáciles placeres de la construcción de sistemas nunca más volverán a satisfacerte.” Tom DeMarco

que trabaje en aplicaciones similares, pero que no son necesariamente las mismas. La figura 6.2 [Ara89] ilustra entradas y salidas clave para el proceso de análisis del dominio. Las fuentes de conocimiento del dominio se mapean con el fin de identificar los objetos que pueden reutilizarse a través del dominio.

6.1.4

Enfoques del modelado de requerimientos

Un enfoque del modelado de requerimientos, llamado análisis estructurado, considera que los datos y los procesos que los transforman son entidades separadas. Los objetos de datos se modelan de modo que se definan sus atributos y relaciones. Los procesos que manipulan a los objetos de datos se modelan en forma que se muestre cómo transforman a los datos a medida que los objetos que se corresponden con ellos fluyen por el sistema.

5

No suponga que el ingeniero de software no necesita entender el dominio de la aplicación tan sólo porque hay un analista del dominio trabajando. Todo miembro del equipo del software debe entender algo del dominio en el que se va a colocar el software.


14/1/10 14:29:16

C AP Í T UL O 6

131


FIGURA 6.3 Modelos basados en el escenario por ejemplo, casos de uso historias de usuario

Elementos del modelo de análisis

?

Modelos de clase por ejemplo, diagramas de clase diagramas de colaboración

Requerimientos del software

¿Cuáles son los diferentes puntos de vista que se usan para describir el modelo de requerimientos?

Modelos de comportamiento por ejemplo, diagramas de estado diagramas de secuencia

Modelos de flujo por ejemplo, DFD modelos de datos

Un segundo enfoque del modelado del análisis, llamado análisis orientado a objetos, se centra en la definición de las clases y en la manera en la que colaboran uno con el otro para cumplir los requerimientos. El UML y el proceso unificado (véase el capítulo 2) están orientados a objetos, sobre todo. Aunque el modelo de requerimientos propuesto en este libro combina características de ambos enfoques, los equipos de software escogen con frecuencia uno y excluyen todas las repre-

Cita:

sentaciones del otro. La pregunta no es cuál es mejor, sino qué combinación de representacio-

“¿Por qué construimos modelos? ¿Por qué no construir sólo el sistema? La respuesta es que los construimos para que resalten o enfaticen ciertas características críticas de un sistema, al tiempo que ignoran otros aspectos del mismo.”

nes proporcionará a los participantes el mejor modelo de requerimientos del software y el

Ed Yourdon

nas jerárquicas) entre los objetos y las colaboraciones que ocurrirán entre las clases que se

puente más eficaz para el diseño del mismo. Cada elemento del modelo de requerimientos (véase la figura 6.3) presenta el problema desde diferentes puntos de vista. Los elementos basados en el escenario ilustran cómo interactúa el usuario con el sistema y la secuencia específica de actividades que ocurren cuando se utiliza el software. Los elementos basados en la clase modelan los objetos que el sistema manipulará, las operaciones que se aplicarán a ellos para realizar dicha manipulación, las relaciones (algudefinan. Los elementos del comportamiento ilustran la forma en la que los eventos externos cambian el estado del sistema o las clases que residen dentro de éste. Por último, los elementos orientados al flujo representan al sistema como una transformación de la información e ilustran la forma en la que se transforman los objetos de datos cuando fluyen a través de las distintas funciones del sistema. El modelado del análisis lleva a la obtención de cada uno de estos elementos de modelado. Sin embargo, el contenido específico de cada elemento (por ejemplo, los diagramas que se emplean para construir el elemento y el modelo) tal vez difiera de un proyecto a otro. Como se ha dicho varias veces en este libro, el equipo del software debe trabajar para mantenerlo sencillo. Sólo deben usarse elementos de modelado que agreguen valor al modelo.

6. 2

MODELADO

BASADO EN ESCENARIOS

Aunque el éxito de un sistema o producto basado en computadora se mide de muchas maneras, la satisfacción del usuario ocupa el primer lugar de la lista. Si se entiende cómo desean interactuar los usuarios finales (y otros actores) con un sistema, el equipo del software estará mejor preparado para caracterizar adecuadamente los requerimientos y hacer análisis significativos y


14/1/10 14:29:16

132

PAR T E DOS

MO D E LADO

modelos del diseño. Entonces, el modelado de los requerimientos con UML6 comienza con la creación de escenarios en forma de casos de uso, diagramas de actividades y diagramas tipo carril de natación.

6.2.1

Creación de un caso preliminar de uso

Alistair Cockburn caracteriza un caso de uso como un “contrato para el comportamiento”

Cita:

[Coc01b]. Como se dijo en el capítulo 5, el “contrato” define la forma en la que un actor7 utiliza

“[Los casos de uso] simplemente son una ayuda para definir lo que existe fuera del sistema (actores) y lo que debe realizar el sistema (casos de uso).”

un sistema basado en computadora para alcanzar algún objetivo. En esencia, un caso de uso

Ivar Jacobson

desde el punto de vista de un actor definido. Pero, ¿cómo se sabe sobre qué escribir, cuánto

capta las interacciones que ocurren entre los productores y consumidores de la información y el sistema en sí. En esta sección se estudiará la forma en la que se desarrollan los casos de uso como parte de los requerimientos de la actividad de modelado.8 En el capítulo 5 se dijo que un caso de uso describe en lenguaje claro un escenario específico escribir sobre ello, cuán detallada hacer la descripción y cómo organizarla? Son preguntas que deben responderse si los casos de uso han de tener algún valor como herramienta para modelar los requerimientos. ¿Sobre qué escribir?

CONSEJO

Las dos primeras tareas de la ingeniería de requerimientos —concep-

ción e indagación— dan la información que se necesita para comenzar a escribir casos de uso.

En ciertas situaciones, los casos de uso se convierten en el mecanismo dominante de la ingeniería de requerimientos. Sin embargo, esto no significa que deban descartarse otros métodos de modelado cuando resulten apropiados.

Las reuniones para recabar los requerimientos, el DEC, y otros mecanismos para obtenerlos se utilizan para identificar a los participantes, definir el alcance del problema, especificar los objetivos operativos generales, establecer prioridades, delinear todos los requerimientos funcionales conocidos y describir las cosas (objetos) que serán manipuladas por el sistema. Para comenzar a desarrollar un conjunto de casos de uso, se enlistan las funciones o actividades realizadas por un actor específico. Éstas se obtienen de una lista de las funciones requeridas del sistema, por medio de conversaciones con los participantes o con la evaluación de los diagramas de actividades (véase la sección 6.3.1) desarrollados como parte del modelado de los requerimientos.

C ASA S EGURA 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: 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: Sí... en cierto modo.

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.

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.

Jamie: ¿Quién juega el papel del actor aquí?

Ed: ¿Usaremos compresión para guardar el video?

6

En todo el libro se usará UML como notación para elaborar modelos. En el apéndice 1 se ofrece un método breve de enseñanza para aquellos lectores que no estén familiarizados con lo más básico de dicha notación.

7

Un actor no es una persona específica sino el rol que desempeña ésta (o un dispositivo) en un contexto específico. Un actor “llama al sistema para que entregue uno de sus servicios” [Coc01b].

8

Los casos de uso son una parte del modelado del análisis de importancia especial para las interfaces. El análisis de la interfaz se estudia en detalle en el capítulo 11.


14/1/10 14:29:17

C AP Í T UL O 6


Facilitador: Buena pregunta, Ed, pero por ahora pospondremos los aspectos de la implementación. ¿Meredith? Meredith: Bien, básicamente hay dos 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 centraré 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 en una PC y controlar el ángulo y acercamiento de una cámara en particular. Especificaría la

133

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…

La función (subsistema) de vigilancia de CasaSegura estudiada en el recuadro identifica las funciones siguientes (lista abreviada) que va a realizar el actor propietario:

• Seleccionar cámara para ver. • Pedir vistas reducidas de todas las cámaras. • Mostrar vistas de las cámaras en una ventana de PC. • Controlar el ángulo y acercamiento de una cámara específica. • Grabar la salida de cada cámara en forma selectiva. • Reproducir la salida de una cámara. • Acceder por internet a la vigilancia con cámaras. A medida que avanzan las conversaciones con el participante (quien juega el papel de propietario), el equipo que recaba los requerimientos desarrolla casos de uso para cada una de las funciones estudiadas. En general, los casos de uso se escriben primero en forma de narración informal. Si se requiere más formalidad, se reescribe el mismo caso con el empleo de un formato estructurado, similar al propuesto en el capítulo y que se reproduce en un recuadro más adelante, en esta sección. Para ilustrar esto, considere la función acceder a la vigilancia con cámaras por internet-mostrar vistas de cámaras (AVC-MVC). El participante que tenga el papel del actor llamado propietario escribiría una narración como la siguiente: Caso de uso: acceder a la vigilancia con cámaras por internet, mostrar vistas de cámaras (AVC-MVC) Actor: propietario Si estoy en una localidad alejada, puedo usar cualquier PC con un software de navegación apropiado para entrar al sitio web de Productos CasaSegura. Introduzco mi identificación de usuario y dos niveles de claves; una vez validadas, tengo acceso a toda la funcionalidad de mi sistema instalado. Para acceder a la vista de una cámara específica, selecciono “vigilancia” de los botones mostrados para las funciones principales. Luego selecciono “escoger una cámara” y aparece el plano de la casa. Después elijo la cámara que me interesa. Alternativamente, puedo ver la vista de todas las cámaras simultáneamente si selecciono “todas las cámaras”. Una vez que escojo una, selecciono “vista” y en la ventana que cubre la cámara aparece una vista con velocidad de un cuadro por segundo. Si quiero cambiar entre las cámaras, selecciono “escoger una cámara” y desaparece la vista original y de nuevo se muestra el plano de la casa. Después, selecciono la cámara que me interesa. Aparece una nueva ventana de vistas.


14/1/10 14:29:17

134

PAR T E DOS

MO D E LADO

Una variación de la narrativa del caso de uso presenta la interacción como una secuencia ordenada de acciones del usuario. Cada acción está representada como enunciado declarativo. Al visitar la función ACS-DCV, se escribiría lo siguiente: Caso de uso: acceder a la vigilancia con cámaras por internet, mostrar vistas de cámaras (AVC-MVC) Actor: propietario 1. El propietario accede al sitio web Productos CasaSegura.

Cita:

2. El propietario introduce su identificación de usuario.

“Los casos de uso se emplean en muchos procesos [de software]. Nuestro favorito es el que es iterativo y guiado por el riesgo.”

3. El propietario escribe dos claves (cada una de al menos ocho caracteres de longitud). 4. El sistema muestra los botones de todas las funciones principales. 5. El propietario selecciona “vigilancia” de los botones de las funciones principales.

Gerl Schneider y Jason Winters

6. El propietario elige “seleccionar una cámara”. 7. El sistema presenta el plano de la casa. 8. El propietario escoge el ícono de una cámara en el plano de la casa. 9. El propietario selecciona el botón “vista”. 10. El sistema presenta la ventana de vista identificada con la elección de la cámara. 11. El sistema muestra un video dentro de la ventana a velocidad de un cuadro por segundo.

Es importante observar que esta presentación en secuencia no considera interacciones alternativas (la narración fluye con más libertad y representa varias alternativas). Los casos de este tipo en ocasiones se denominan escenarios primarios [Sch98a].

6.2.2

Mejora de un caso de uso preliminar

Para entender por completo la función que describe un caso de uso, es esencial describir interacciones alternativas. Después se evalúa cada paso en el escenario primario, planteando las preguntas siguientes [Sch98a]:

?

Cuando desarrollo un caso de uso, ¿cómo examino los cursos alternativos de acción?

• ¿El actor puede emprender otra acción en este punto? • ¿Es posible que el actor encuentre alguna condición de error en este punto? Si así fuera, ¿cuál podría ser?

• En este punto, ¿es posible que el actor encuentre otro comportamiento (por ejemplo, alguno que sea invocado por cierto evento fuera del control del actor)? En ese caso, ¿cuál sería? Las respuestas a estas preguntas dan como resultado la creación de un conjunto de escenarios secundarios que forman parte del caso de uso original, pero que representan comportamientos alternativos. Por ejemplo, considere los pasos 6 y 7 del escenario primario ya descrito: 6. El propietario elige “seleccionar una cámara”. 7. El sistema presenta el plano de la casa.

¿El actor puede emprender otra acción en este punto? La respuesta es “sí”. Al analizar la narración de flujo libre, el actor puede escoger mirar vistas de todas las cámaras simultáneamente. Entonces, un escenario secundario sería “observar vistas instantáneas de todas las cámaras”. ¿Es posible que el actor encuentre alguna condición de error en este punto? Cualquier número de condiciones de error puede ocurrir cuando opera un sistema basado en computadora. En este contexto, sólo se consideran las condiciones que sean probables como resultado directo de la acción descrita en los pasos 6 o 7. De nuevo, la respuesta es “sí”. Tal vez nunca se haya configurado un plano con íconos de cámara. Entonces, elegir “seleccionar una cámara” da como


14/1/10 14:29:17

C AP Í T UL O 6


135

resultado una condición de error: “No hay plano configurado para esta casa.”9 Esta condición de error se convierte en un escenario secundario. En este punto, ¿es posible que el actor encuentre otro comportamiento (por ejemplo, alguno que sea invocado por cierto evento fuera del control del actor)? Otra vez, la respuesta es “sí”. A medida que ocurran los pasos 6 y 7, el sistema puede hallar una condición de alarma. Esto dará como resultado que el sistema desplegará una notificación especial de alarma (tipo, ubicación, acción del sistema) y proporcionará al actor varias opciones relevantes según la naturaleza de la alarma. Como este escenario secundario puede ocurrir en cualquier momento para prácticamente todas las interacciones, no se vuelve parte del caso de uso AVC-MVC. En vez de ello, se desarrollará un caso de uso diferente —Condición de alarma encontrada— al que se hará referencia desde otros casos según se requiera. Cada una de las situaciones descritas en los párrafos precedentes se caracteriza como una excepción al caso de uso. Una excepción describe una situación (ya sea condición de falla o alternativa elegida por el actor) que ocasiona que el sistema presente un comportamiento algo distinto. Cockburn [Coc01b] recomienda el uso de una sesión de “lluvia de ideas” para obtener un conjunto razonablemente complejo de excepciones para cada caso de uso. Además de las tres preguntas generales ya sugeridas en esta sección, también deben explorarse los siguientes aspectos:

• ¿Existen casos en los que ocurra alguna “función de validación” durante este caso de uso? Esto implica que la función de validación es invocada y podría ocurrir una potencial condición de error.

• ¿Hay casos en los que una función (o actor) de soporte falle en responder de manera apropiada? Por ejemplo, una acción de usuario espera una respuesta pero la función que ha de responder se cae.

• ¿El mal desempeño del sistema da como resultado acciones inesperadas o impropias? Por ejemplo, una interfaz con base en web responde con demasiada lentitud, lo que da como resultado que un usuario haga selecciones múltiples en un botón de procesamiento. Estas selecciones se forman de modo equivocado y, en última instancia, generan un error. La lista de extensiones desarrollada como consecuencia de preguntar y responder estas preguntas debe “racionalizarse” [Coc01b] con el uso de los siguientes criterios: una excepción debe describirse dentro del caso de uso si el software la puede detectar y debe manejarla una vez detectada. En ciertos casos, una excepción precipitará el desarrollo de otro caso de uso (el de manejar la condición descrita).

6.2.3

Escritura de un caso de uso formal

En ocasiones, para modelar los requerimientos es suficiente con los casos de uso informales presentados en la sección 6.2.1. Sin embargo, cuando un caso de uso involucra una actividad crítica o cuando describe un conjunto complejo de etapas con un número significativo de excepciones, es deseable un enfoque más formal. El caso de uso AVC-MVC mostrado en el recuadro de la página 136 sigue el guión común para los casos de uso formales. El objetivo en contexto identifica el alcance general del caso de

9

En este caso, otro actor, administrador del sistema, tendría que configurar el plano de la casa, instalar e inicializar todas las cámaras (por ejemplo, asignar una identificación a los equipos) y probar cada una para garantizar que se encuentren accesibles por el sistema y a través del plano de la casa.


14/1/10 14:29:17

136

PAR T E DOS

MO D E LADO

uso. La precondición describe lo que se sabe que es verdadero antes de que inicie el caso de uso. El disparador (o trigger) identifica el evento o condición que “hace que comience el caso de uso” [Coc01b]. El escenario enlista las acciones específicas que requiere el actor, y las respuestas apropiadas del sistema. Las excepciones identifican las situaciones detectadas cuando se mejora el caso de uso preliminar (véase la sección 6.2.2). Pueden incluirse o no encabezados adicionales y se explican por sí mismos en forma razonable.

C ASA S EGURA Formato de caso de uso para vigilancia Caso de uso: Acceder a la vigilancia con cámaras por internet, mostrar vistas de cámaras (AVCMVC). 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.

Escenario:

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). 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). 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.

1. El propietario se registra en el sitio web Productos CasaSegura.

Frecuencia de uso:

Frecuencia moderada.

2. El propietario introduce su identificación de usuario.

Canal al actor:

3. El propietario proporciona dos claves (cada una con longitud de al menos ocho caracteres).

A través de un navegador con base en PC y conexión a internet.

Actores secundarios:

Administrador del sistema, cámaras.

4. El sistema despliega todos los botones de las funciones principales. 5. El propietario selecciona “vigilancia” entre los botones de funciones principales.

Canales a los actores secundarios: 1. Administrador del sistema: sistema basado en PC. 2. Cámaras: conectividad inalámbrica.

6. El propietario escoge “seleccionar una cámara”.

Asuntos pendientes:

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.

WebRef ¿Cuándo se ha terminado de escribir casos de uso? Para un análisis benéfico de esto, consulte la dirección ootips.org/use-cases-done. html

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?

En muchos casos, no hay necesidad de crear una representación gráfica de un escenario de uso. Sin embargo, la representación con diagramas facilita la comprensión, en particular cuando el escenario es complejo. Como ya se dijo en este libro, UML cuenta con la capacidad de hacer diagramas de casos de uso. La figura 6.4 ilustra un diagrama de caso de uso preliminar para el producto CasaSegura. Cada caso de uso está representado por un óvalo. En esta sección sólo se estudia el caso de uso AVC-MVC.


14/1/10 14:29:18

C AP Í T UL O 6

137


FIGURA 6.4

CasaSegura

Diagrama de caso de uso preliminar para el sistema CasaSegura

Acceso por internet a las cámaras de vigilancia

Propietario

Cámaras

Configura los parámetros del sistema CasaSegura

Activa alarma

Toda notación de modelado tiene sus limitaciones, y la del caso de uso no es la excepción. Como cualquier otra forma de descripción escrita, un caso de uso es tan bueno como lo sea(n) su(s) autor(es). Si la descripción es poco clara, el caso de uso será confuso o ambiguo. Un caso de uso se centra en los requerimientos funcionales y de comportamiento, y por lo general es inapropiado para requerimientos disfuncionales. Para situaciones en las que el modelo de requerimientos deba tener detalle y precisión significativos (por ejemplo, sistemas críticos de seguridad), tal vez no sea suficiente un caso de uso. Sin embargo, el modelado basado en escenarios es apropiado para la gran mayoría de todas las situaciones que encontrará un ingeniero de software. Si se desarrolla bien, el caso de uso proporciona un beneficio sustancial como herramienta de modelado.

6. 3

MODELOS UML

QUE PROPORCIONAN EL CASO DE USO

Hay muchas situaciones de modelado de requerimientos en las que un modelo basado en texto —incluso uno tan sencillo como un caso de uso— tal vez no brinde información en forma clara y concisa. En tales casos, es posible elegir de entre una amplia variedad de modelos UML gráficos.

6.3.1 PU

Desarrollo de un diagrama de actividades

El diagrama de actividad UML enriquece el caso de uso al proporcionar una representación

NT

O

CLAVE

Un diagrama de actividades UML representa las acciones y decisiones que ocurren cuando se realiza cierta función.

gráfica del flujo de interacción dentro de un escenario específico. Un diagrama de actividades es similar a uno de flujo, y utiliza rectángulos redondeados para denotar una función específica del sistema, flechas para representar flujo a través de éste, rombos de decisión para ilustrar una ramificación de las decisiones (cada flecha que salga del rombo se etiqueta) y líneas continuas para indicar que están ocurriendo actividades en paralelo. En la figura 6.5 se presenta un diagrama de actividades para el caso de uso AVC-MVC. Debe observarse que el diagrama de actividades agrega detalles adicionales que no se mencionan directamente (pero que están implícitos) en el caso de uso. Por ejemplo, un usuario quizá sólo haga algunos intentos de introducir su identificación y password. Esto se representa por el rombo de decisión debajo de “Mensaje para que se repita la entrada”.


14/1/10 14:29:18

138

PAR T E DOS

MO D E LADO

FIGURA 6.5 Diagrama de actividades para la función Acceder a la vigilancia con cámaras por internet, mostrar vistas de cámaras.

Introducir password e identificación de usuario

Password e identificación válidas

También pueden seleccionarse otras funciones

Seleccionar una función principal

Mensaje para que se repita la entrada Hay intentos de entrada

Seleccionar vigilancia

Vistas reducidas

Passwords o identificación inválidas

No hay intentos de entrada

Seleccionar una cámara específica

Seleccionar una cámara específica, vista reducida

Seleccionar un ícono de cámara

Ver la salida de la cámara en una ventana etiquetada

Mensaje para otra vista Salir de esta función

6.3.2 PU

Ver otra cámara

Diagramas de canal (swimlane)

El diagrama de canal de UML es una variación útil del diagrama de actividades y permite repre-

NT

O

CLAVE

Un diagrama de canal (swimlane) representa el flujo de acciones y decisiones e indica qué actores efectúan cada una de ellas.

sentar el flujo de actividades descritas por el caso de uso; al mismo tiempo, indica qué actor (si hubiera muchos involucrados en un caso específico de uso) o clase de análisis (se estudia más adelante, en este capítulo) es responsable de la acción descrita por un rectángulo de actividad. Las responsabilidades se representan con segmentos paralelos que dividen el diagrama en forma vertical, como los canales o carriles de una alberca. Son tres las clases de análisis: Propietario, Cámara e Interfaz, que tienen responsabilidad directa o indirecta en el contexto del diagrama de actividades representado en la figura 6.5. En relación con la figura 6.6, el diagrama de actividades se reacomodó para que las actividades asociadas con una clase de análisis particular queden dentro del canal de dicha clase. Por ejemplo, la clase Interfaz representa la interfaz de usuario como la ve el propietario. El diagrama de actividades tiene dos mensajes que son responsabilidad de la interfaz: “mensaje para que se repita la entrada” y “mensaje para otra vista”. Estos mensajes y las decisiones asociadas con

Cita: “Un buen modelo guía el pensamiento; uno malo lo desvía.” Brian Marick


ellos caen dentro del canal Interfaz. Sin embargo, las flechas van de ese canal de regreso al de Propietario, donde ocurren las acciones de éste. Los casos de uso, junto con los diagramas de actividades y de canal, están orientados al procedimiento. Representan la manera en la que los distintos actores invocan funciones específicas (u otros pasos del procedimiento) para satisfacer los requerimientos del sistema. Pero

14/1/10 14:29:18

C AP Í T UL O 6

139


FIGURA 6.6 Propietario

Diagrama de canal para la función Acceder a la vigilancia con cámaras por internet, mostrar vistas de cámaras

Cámara

Interfaz

Introducir password e identificación de usuario

Passwords e identificación válidas Seleccionar una función principal

También pueden seleccionarse otras funciones Seleccionar vigilancia

Passwords o identificación inválidas Mensaje para que se repita la entrada Hay intentos de entrada No hay intentos de entrada

Seleccionar una cámara específica

Vistas reducidas

Seleccionar una cámara específica, vista reducida

Seleccionar un ícono de cámara

Generar salida de video Ver la salida de la cámara en una ventana etiquetada

Mensaje para otra vista Salir de esta función Ver otra cámara

una vista del procedimiento de los requerimientos representa una sola dimensión del sistema. En la sección 6.4 se estudia el espacio de información y la forma en la que se representan los datos de requerimientos.

6. 4 WebRef En la dirección www.datamodel. org, hay información útil sobre el modelado de datos.

CONCEPTOS

DE MODELADO DE DATOS

Si los requerimientos del software incluyen la necesidad de crear, ampliar o hacer interfaz con una base de datos, o si deben construirse y manipularse estructuras de datos complejas, el equipo del software tal vez elija crear un modelo de datos como parte del modelado general de los requerimientos. Un ingeniero o analista de software define todos los objetos de datos que se procesan dentro del sistema, la relación entre ellos y otro tipo de información que sea pertinente para las relaciones. El diagrama entidad-relación (DER) aborda dichos aspectos y representa todos los datos que se introducen, almacenan, transforman y generan dentro de una aplicación.

?

¿Cómo se manifiesta un objeto de datos en el contexto de una aplicación?


6.4.1

Objetos de datos

Un objeto de datos es una representación de información compuesta que debe ser entendida por el software. Información compuesta quiere decir algo que tiene varias propiedades o atributos

14/1/10 14:29:18

140

PAR T E DOS

MO D E LADO

diferentes. Por tanto, el ancho (un solo valor) no sería un objeto de datos válido, pero las dimensiones (que incorporan altura, ancho y profundidad) sí podrían definirse como un objeto. Un objeto de datos puede ser una entidad externa (por ejemplo, cualquier cosa que produzca o consuma información), una cosa (por ejemplo, un informe o pantalla), una ocurrencia (como una llamada telefónica) o evento (por ejemplo, una alarma), un rol (un vendedor), una unidad organizacional (por ejemplo, el departamento de contabilidad), un lugar (como una bodega) o estructura (como un archivo). Por ejemplo, una persona o un auto pueden considerarse como

PU

NT

O

CLAVE

Un objeto de datos es una representación de cualquier información compuesta que se procese en el software.

objetos de datos en tanto cada uno se define en términos de un conjunto de atributos. La descripción del objeto de datos incorpora a ésta todos sus atributos. Un objeto de datos contiene sólo datos —dentro de él no hay referencia a las operaciones que se apliquen sobre los datos—.10 Entonces, el objeto de datos puede representarse en forma de tabla, como la que se muestra en la figura 6.7. Los encabezados de la tabla reflejan atributos del objeto. En este caso, un auto se define en términos de fabricante, modelo, número de serie, tipo de carrocería, color y propietario. El cuerpo de la tabla representa instancias específicas del objeto de

datos. Por ejemplo, un Chevy Corvette es una instancia del objeto de datos auto.

6.4.2 PU

Atributos de los datos

Los atributos de los datos definen las propiedades de un objeto de datos y tienen una de tres di-

NT

O

CLAVE

Los atributos nombran a un objeto de datos, describen sus características y, en ciertos casos, hacen referencia a otro objeto.

ferentes características. Se usan para 1) nombrar una instancia del objeto de datos, 2) describir la instancia o 3) hacer referencia a otra instancia en otra tabla. Además, debe definirse como identificador uno o más de los atributos —es decir, el atributo identificador se convierte en una “llave” cuando se desea encontrar una instancia del objeto de datos—. En ciertos casos, los valores para el (los) identificador(es) son únicos, aunque esto no es una exigencia. En relación con el objeto de datos auto, un identificador razonable sería el número de serie.

WebRef Para aquellos que intentan hacer modelado de datos, es importante un concepto llamado “normalización”. En la dirección www.datamodel.org se encuentra una introducción útil.

El conjunto de atributos que es apropiado para un objeto de datos determinado se define entendiendo el contexto del problema. Los atributos para auto podrían servir bien para una aplicación que usara un departamento de vehículos motorizados, pero serían inútiles para una compañía automotriz que necesitara hacer software de control de manufactura. En este último caso, los atributos para auto quizá también incluyan número de serie, tipo de carrocería y color, pero tendrían que agregarse muchos otros (por ejemplo, código interior, tipo de tracción, indicador de paquete de recorte, tipo de transmisión, etc.) para hacer de auto un objeto significativo en el contexto

de control de manufactura.

FIGURA 6.7

Nombrar los atributos

Representación tabular de objetos de datos

Liga un objeto de datos con otro, en este caso el propietario

Identificador Fabricante Lexus Instancia Chevy BMW Ford

Modelo Número de serie LS400 AB123. . . Corvette X456. . . 750iL XZ765. . . Taurus Q12A45. . .

Atributos descriptivos Carrocería Sedán Deportivo Cupé Sedán

Atributos referenciales

Color Blanco Rojo Blanco Azul

Propietario RSP CCD LJL BLF

10 Esta distinción separa al objeto de datos de la clase u objeto definidos como parte del enfoque orientado a objetos (véase el apéndice 2).


14/1/10 14:29:18

C AP Í T UL O 6

141


I NFOR MACIÓN Objetos de datos y clases orientadas a objetos: ¿son lo mismo? Al analizar objetos de datos es común que surja una pregunta: ¿un objeto de datos es lo mismo que una clase orientada11 a objetos? La respuesta es “no”. Un objeto de datos define un aspecto de datos compuestos; es decir, incorpora un conjunto de características de datos individuales (atributos) y da al conjunto un nombre (el del objeto de datos). Una clase orientada a objetos encierra atributos de datos, pero también incorpora las operaciones (métodos) que los manipulan y

6.4.3 PU

que están determinadas por dichos atributos. Además, la definición de clases implica una infraestructura amplia que es parte del enfoque de la ingeniería de software orientada a objetos. Las clases se comunican entre sí por medio de mensajes, se organizan en jerarquías y tienen características hereditarias para los objetos que son una instancia de una clase.

Relaciones

Los objetos de datos están conectados entre sí de diferentes maneras. Considere dos objetos de

NT

O

CLAVE

Las relaciones indican la manera en la que los objetos de datos se conectan entre sí.

datos, persona y auto. Estos objetos se representan con la notación simple que se ilustra en la figura 6.8a). Se establece una conexión entre persona y auto porque ambos objetos están relacionados. Pero, ¿cuál es esa relación? Para determinarlo, debe entenderse el papel de las personas (propiedad, en este caso) y los autos dentro del contexto del software que se va a elaborar. Se establece un conjunto de parejas objeto/relación que definan las relaciones relevantes. Por ejemplo,

• Una persona posee un auto. • Una persona es asegurada para que maneje un auto. Las relaciones posee y es asegurada para que maneje definen las conexiones relevantes entre persona y auto. La figura 6.8b) ilustra estas parejas objeto-relación. Las flechas en esa figura dan información importante sobre la dirección de la relación y es frecuente que reduzcan las ambigüedades o interpretaciones erróneas.

FIGURA 6.8 Relaciones entre objetos de datos

persona

auto

a) conexión básica entre objetos de datos posee persona

asegurada para que maneje

auto

b) relaciones entre los objetos de datos

11 Los lectores que no estén familiarizados con los conceptos y terminología de la orientación a objetos deben consultar el breve instructivo que se presenta en el apéndice 2.


14/1/10 14:29:19

142

PAR T E DOS

MO D E LADO

I NFOR MACIÓN Diagramas entidad-relación La pareja objeto-relación es la piedra angular del modelo de datos. Estas parejas se representan gráficamente con el uso del diagrama entidad-relación (DER).12 El DER fue propuesto por primera vez por Peter Chen [Che77] para diseñar sistemas de bases de datos relacionales y ha sido ampliado por otras personas. Se identifica un conjunto de componentes primarios para el DER: objetos de datos, atributos, relaciones y distintos indicadores de tipo. El propósito principal del DER es representar objetos de datos y sus relaciones.

Ya se presentó la notación DER básica. Los objetos de datos se representan con un rectángulo etiquetado. Las relaciones se indican con una línea etiquetada que conecta objetos. En ciertas variantes del DER, la línea de conexión contiene un rombo con la leyenda de la relación. Las conexiones entre los objetos de datos y las relaciones se establecen con el empleo de varios símbolos especiales que indican cardinalidad y modalidad.13 Si el lector está interesado en obtener más información sobre el modelado de datos y el diagrama entidadrelación, consulte [Hob06] o [Sim05].

H ERRAMIENTAS

DE SOFTWARE

Modelado de datos Objetivo: Las herramientas de modelado de datos dan a un ingeniero de software la capacidad de representar objetos de datos, sus características y relaciones. Se usan sobre todo para aplicaciones de grandes bases de datos y otros proyectos de sistemas de información, y proveen medios automatizados para crear diagramas completos de entidad-relación, diccionarios de objetos de datos y modelos relacionados. Mecánica: Las herramientas de esta categoría permiten que el usuario describa objetos de datos y sus relaciones. En ciertos casos, utilizan notación DER. En otros, modelan relaciones con el empleo de un mecanismo diferente. Es frecuente que las herramientas en esta categoría se usen como parte del diseño de una base de datos y que permitan la creación de su modelo con la generación de un esquema para sistemas comunes de administración de bases de datos comunes (DBMS).

6. 5

MODELADO

Herramientas representativas:14 AllFusion ERWin, desarrollada por Computer Associates (www3. ca.com), ayuda en el diseño de objetos de datos, estructura apropiada y elementos clave para las bases de datos. ER/Studio, desarrollada por Embarcadero Software (www. embarcadero.com), da apoyo al modelado entidad-relación. Oracle Designer, desarrollada por Oracle Systems (www.oracle. com), “modela procesos de negocios, entidades y relaciones de datos [que] se transforman en diseños para los que se generan aplicaciones y bases de datos completas”. Visible Analyst, desarrollada por Visible Systems (www.visible. com), da apoyo a varias funciones de modelado del análisis, incluso modelado de datos.

BASADO EN CLASES

El modelado basado en clases representa los objetos que manipulará el sistema, las operaciones (también llamadas métodos o servicios) que se aplicarán a los objetos para efectuar la manipulación, las relaciones (algunas de ellas jerárquicas) entre los objetos y las colaboraciones que tienen lugar entre las clases definidas. Los elementos de un modelo basado en clases incluyen las clases y los objetos, atributos, operaciones, modelos clase-responsabilidad-colaborador (CRC), diagramas de colaboración y paquetes. En las secciones siguientes se presenta una serie de lineamientos informales que ayudarán a su identificación y representación.

12 Aunque algunas aplicaciones de diseño de bases de datos aún emplean el DER, ahora se utiliza la notación UML (véase el apéndice 1) para el diseño de datos. 13 La cardinalidad de una pareja objeto-relación especifica “el número de ocurrencias de uno [objeto] que se relaciona con el número de ocurrencias de otro [objeto]” [Til93]. La modalidad de una relación es 0 si no hay necesidad explícita para que ocurra la relación o si ésta es opcional. La modalidad es 1 si una ocurrencia de la relación es obligatoria. 14 Las herramientas mencionadas aquí no son obligatorias sino una muestra de las que hay en esta categoría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.


14/1/10 14:29:19

C AP Í T UL O 6

6.5.1

143


Identificación de las clases de análisis

Al mirar una habitación, se observa un conjunto de objetos físicos que se identifican, clasifican y

Cita:

definen fácilmente (en términos de atributos y operaciones). Pero cuando se “ve” el espacio del

“El problema realmente difícil es descubrir en primer lugar cuáles son los objetos correctos [clases].”

problema de una aplicación de software, las clases (y objetos) son más difíciles de concebir.

Carl Argila

se determinan subrayando cada sustantivo o frase que las incluya para introducirlo en una tabla

Se comienza por identificar las clases mediante el análisis de los escenarios de uso desarrollados como parte del modelo de requerimientos y la ejecución de un “análisis gramatical” [Abb83] sobre los casos de uso desarrollados para el sistema que se va a construir. Las clases simple. Deben anotarse los sinónimos. Si la clase (sustantivo) se requiere para implementar una solución, entonces forma parte del espacio de solución; de otro modo, si sólo es necesaria para describir la solución, es parte del espacio del problema. Pero, ¿qué debe buscarse una vez identificados todos los sustantivos? Las clases de análisis se manifiestan en uno de los modos siguientes:

?

¿Cómo se manifiestan las clases en tantos elementos del espacio de solución?

• Entidades externas (por ejemplo, otros sistemas, dispositivos y personas) que producen o consumen la información que usará un sistema basado en computadora.

• Cosas (reportes, pantallas, cartas, señales, etc.) que forman parte del dominio de información para el problema.

• Ocurrencias o eventos (como una transferencia de propiedad o la ejecución de una serie de movimientos de un robot) que suceden dentro del contexto de la operación del sistema.

• Roles (gerente, ingeniero, vendedor, etc.) que desempeñan las personas que interactúan con el sistema.

• Unidades organizacionales (división, grupo, equipo, etc.) que son relevantes para una aplicación.

• Lugares (piso de manufactura o plataforma de carga) que establecen el contexto del problema y la función general del sistema.

• Estructuras (sensores, vehículos de cuatro ruedas, computadoras, etc.) que definen una clase de objetos o clases relacionadas de éstos. Esta clasificación sólo es una de muchas propuestas en la bibliografía.15 Por ejemplo, Budd [Bud96] sugiere una taxonomía de clases que incluye productores (fuentes) y consumidores (sumideros) de datos, administradores de datos, vista, clases de observador y clases de auxiliares. También es importante darse cuenta de lo que no son las clases u objetos. En general, una clase nunca debe tener un “nombre de procedimiento imperativo” [Cas89]. Por ejemplo, si los desarrolladores del software de un sistema de imágenes médicas definieron un objeto con el nombre InvertirImagen o incluso InversióndeImagen, cometerían un error sutil. La Imagen obtenida del software podría ser, por supuesto, una clase (algo que es parte del dominio de la información). La inversión de la imagen es una operación que se aplica al objeto. Es probable que la inversión esté definida como una operación para el objeto Imagen, pero no lo estaría como clase separada con la connotación “inversión de imagen”. Como afirma Cashman [Cas89]: “el intento de la orientación a objetos es contener, pero mantener separados, los datos y las operaciones sobre ellos”. Para ilustrar cómo podrían definirse las clases del análisis durante las primeras etapas del modelado, considere un análisis gramatical (los sustantivos están subrayados, los verbos apa-

15 En la sección 6.5.4 se estudia otra clasificación importante que define las clases entidad, frontera y controladora.


14/1/10 14:29:19

144

PAR T E DOS

MO D E LADO

recen en cursivas) de una narración de procesamiento16 para la función de seguridad de CasaSegura. La función de seguridad CasaSegura permite que el propietario configure el sistema de seguridad cuando se instala, vigila todos los sensores conectados al sistema de seguridad e interactúa con el propietario a través de internet, una PC o panel de control. Durante la instalación, la PC de CasaSegura se utiliza para programar y configurar el sistema. Se asigna a cada sensor un número y tipo, se programa un password maestro para activar y desactivar el sistema y se introducen números telefónicos para marcar cuando ocurre un evento de sensor.

CONSEJO

El análisis gramatical no es a prueba de todo, pero da un impulso excelente para arrancar si se tienen dificultades para definir objetos de datos y las transformaciones que operan sobre ellos.

Cuando se reconoce un evento de sensor, el software invoca una alarma audible instalada en el sistema. Después de un tiempo de retraso que especifica el propietario durante las actividades de configuración del sistema, el software marca un número telefónico de un servicio de monitoreo, proporciona información acerca de la ubicación y reporta la naturaleza del evento detectado. El número telefónico se vuelve a marcar cada 20 segundos hasta que se obtiene la conexión telefónica. El propietario recibe información de seguridad a través de un panel de control, la PC o un navegador, lo que en conjunto se llama interfaz. La interfaz despliega mensajes de aviso e información del estado del sistema en el panel de control, la PC o la ventana del navegador. La interacción del propietario tiene la siguiente forma…

Con los sustantivos se proponen varias clases potenciales:

Clase potencial

Clasificación general

propietario

rol de entidad externa

sensor

entidad externa

panel de control

entidad externa

instalación

ocurrencia

sistema (alias sistema de seguridad)

cosa

número, tipo

no objetos, atributos de sensor

password maestro

cosa

número telefónico

cosa

evento de sensor

ocurrencia

alarma audible

entidad externa

servicio de monitoreo

unidad organizacional o entidad externa

La lista continuará hasta que se hayan considerado todos los sustantivos en la narrativa de procesamiento. Observe que cada entrada en la lista se llama objeto potencial. El lector debe considerar cada una antes de tomar la decisión final. Coad y Yourdon [Coa91] sugieren seis características de selección que deben usarse cuando se considere cada clase potencial para incluirla en el modelo de análisis:

?

¿Cómo determino si una clase potencial debe, en realidad, ser una clase de análisis?

1. Información retenida. La clase potencial será útil durante el análisis sólo si debe recordarse la información sobre ella para que el sistema pueda funcionar. 2. Servicios necesarios. La clase potencial debe tener un conjunto de operaciones identificables que cambien en cierta manera el valor de sus atributos.

16 Una narración de procesamiento es similar al caso de uso en su estilo, pero algo distinto en su propósito. La narración de procesamiento hace una descripción general de la función que se va a desarrollar. No es un escenario escrito desde el punto de vista de un actor. No obstante, es importante observar que el análisis gramatical también puede emplearse para todo caso de uso desarrollado como parte de la obtención de requerimientos (indagación).


14/1/10 14:29:20

C AP Í T UL O 6


145

3. Atributos múltiples. Durante el análisis de los requerimientos, la atención debe estar en la información “principal”; en realidad, una clase con un solo atributo puede ser útil durante el diseño, pero es probable que durante la actividad de análisis se represente mejor como un atributo de otra clase. 4. Atributos comunes. Para la clase potencial se define un conjunto de atributos y se aplican éstos a todas las instancias de la clase. 5. Operaciones comunes. Se define un conjunto de operaciones para la clase potencial y éstas se aplican a todas las instancias de la clase. 6. Requerimientos esenciales. Las entidades externas que aparezcan en el espacio del problema y que produzcan o consuman información esencial para la operación de cualquier solución para el sistema casi siempre se definirán como clases en el modelo de requerimientos. Para que se considere una clase legítima para su inclusión en el modelo de requerimientos,

Cita: “Las clases luchan, algunas triunfan, otras son eliminadas.” Mao Tse Tung

un objeto potencial debe satisfacer todas (o casi todas) las características anteriores. La decisión de incluir clases potenciales en el modelo de análisis es algo subjetiva, y una evaluación posterior tal vez haga que un objeto se descarte o se incluya de nuevo. Sin embargo, el primer paso del modelado basado en clases es la definición de éstas, y deben tomarse las medidas respectivas (aun las subjetivas). Con esto en mente, se aplicarán las características de selección a la lista de clases potenciales de CasaSegura: Clase potencial

Número de característica que se aplica

propietario

rechazada: 1 y 2 fallan, aunque la 6 aplica

sensor

aceptada: se aplican todas

panel de control


instalación

rechazada

sistema (alias sistema de seguridad)


número, tipo

rechazada: 3 fallan, atributos de sensores

password maestro

rechazada: 3 falla

número telefónico

rechazada: 3 falla

evento de sensor


alarma audible

aceptada: se aplican 2, 3, 4, 5 y 6

servicio de monitoreo

rechazada: 1 y 2 fallan aunque la 6 aplica

Debe notarse que: 1) la lista anterior no es exhaustiva; para completar el modelo tendrían que agregarse clases adicionales; 2) algunas de las clases potenciales rechazadas se convertirán en atributos para otras que sí fueron aceptadas (por ejemplo, número y tipo son atributos de Sensor, y password maestro y número telefónico pueden convertirse en atributos de Sistema); 3) diferentes enunciados del problema harían que se tomaran decisiones distintas para “aceptar o rechazar” (por ejemplo, si cada propietario tuviera una clave individual o se identificara con reconocimiento de voz, la clase Propietario satisfaría las características 1 y 2, y se aceptaría).

6.5.2

PU

NT

O

CLAVE

Los atributos son el conjunto de objetos de datos que definen por completo la clase en el contexto del problema.


Especificación de atributos

Los atributos describen una clase que ha sido seleccionada para incluirse en el modelo de requerimientos. En esencia, son los atributos los que definen la clase (esto aclara lo que significa la clase en el contexto del espacio del problema). Por ejemplo, si se fuera a construir un sistema que analiza estadísticas de jugadores de béisbol profesionales, los atributos de la clase Jugador serían muy distintos de los que tendría la misma clase cuando se usara en el contexto del sis-

14/1/10 14:29:20

146

PAR T E DOS

MO D E LADO

tema de pensiones de dicho deporte. En la primera, atributos tales como nombre, porcentaje de bateo, porcentaje de fildeo, años jugados y juegos jugados serían relevantes. Para la segunda, algunos de los

anteriores sí serían significativos, pero otros se sustituirían (o se crearían) por atributos tales como salario promedio, crédito hacia el retiro completo, opciones del plan de pensiones elegido, dirección de correo, etcétera.

Para desarrollar un conjunto de atributos significativos para una clase de análisis, debe estudiarse cada caso de uso y seleccionar aquellas “cosas” que “pertenezcan” razonablemente a la clase. Además, debe responderse la pregunta siguiente para cada clase: “¿qué aspectos de los datos (compuestos o elementales) definen por completo esta clase en el contexto del problema en cuestión?” Para ilustrarlo, se considera la clase Sistema definida para CasaSegura. El propietario configura la función de seguridad para que refleje la información de los sensores, la respuesta de la alarma, la activación o desactivación, la identificación, etc. Estos datos compuestos se representan del modo siguiente: información de identificación = identificación del sistema + número telefónico de verificación + estado del sistema información de respuesta de la alarma = tiempo de retraso + número telefónico información de activación o desactivación = password maestro + número de intentos permisibles + password temporal

Cada uno de los datos a la derecha del signo igual podría definirse más, hasta un nivel elemental, pero para nuestros propósitos constituye una lista razonable de atributos para la clase Sistema (parte sombreada de la figura 6.9). Los sensores forman parte del sistema general CasaSegura, pero no están enlistados como datos o atributos en la figura 6.9. Sensor ya se definió como clase, y se asociarán múltiples objetos Sensor con la clase Sistema. En general, se evita definir algo como atributo si más de uno va a asociarse con la clase.

6.5.3 CONSEJO

Cuando se definen operaciones para una clase de análisis, hay que centrarse en el comportamiento orientado al problema y no en los comportamientos requeridos para su implementación.

Definición de las operaciones

Las operaciones definen el comportamiento de un objeto. Aunque existen muchos tipos distintos de operaciones, por lo general se dividen en cuatro categorías principales: 1) operaciones que manipulan datos en cierta manera (por ejemplo, los agregan, eliminan, editan, seleccionan, etc.), 2) operaciones que realizan un cálculo, 3) operaciones que preguntan sobre el estado de un objeto y 4) operaciones que vigilan un objeto en cuanto a la ocurrencia de un evento de control. Estas funciones se llevan a cabo con operaciones sobre los atributos o sobre asociaciones de éstos (véase la sección 6.5.5). Por tanto, una operación debe tener “conocimiento” de la naturaleza de los atributos y de las asociaciones de la clase. Como primera iteración al obtener un conjunto de operaciones para una clase de análisis, se estudia otra vez una narración del procesamiento (o caso de uso) y se eligen aquellas que pertenezcan razonablemente a la clase. Para lograr esto, de nuevo se efectúa el análisis gramatical y se aíslan los verbos. Algunos de éstos serán operaciones legítimas y se conectarán con facilidad a una clase específica. Por ejemplo, de la narración del procesamiento de CasaSegura ya presentada en este capítulo, se observa que “se asigna a sensor un número y tipo” o “se programa un password maestro para activar y desactivar el sistema” indican cierto número de cosas:

• Que una operación asignar( ) es relevante para la clase Sensor. • Que se aplicará una operación programar( ) a la clase Sistema. • Que activar( ) y desactivar( ) son operaciones que se aplican a la clase Sistema.


14/1/10 14:29:20

C AP Í T UL O 6

147


FIGURA 6.9

Sistema

Diagrama de clase para la clase sistema

Identificación del sistema Verificación del número telefónico Estado del sistema Tiempo de retraso Número telefónico Password maestro Password temporal Número de intentos programa( ) pantalla( ) reiniciar( ) cola( ) activar( ) desactivar( )

Hasta no hacer más investigaciones, es probable que la operación programar( ) se divida en cierto número de suboperaciones específicas adicionales que se requieren para configurar el sistema. Por ejemplo, programar( ) implica la especificación de números telefónicos, la configuración de las características del sistema (por ejemplo, crear la tabla de sensores, introducir las características de la alarma, etc.) y la introducción de la(s) clave(s). Pero, de momento, programar( ) se especifica como una sola operación. Además del análisis gramatical, se obtiene más perspectiva sobre otras operaciones si se considera la comunicación que ocurre entre los objetos. Éstos se comunican con la transmisión de mensajes entre sí. Antes de continuar con la especificación de operaciones, se estudiará esto con más detalle.

C ASA S EGURA Modelos de clase La escena: 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 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: 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.

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.)

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?

Jamie: Entonces, Plano es un objeto que agrupa paredes, puertas, ventanas y cámaras. Eso significa esas líneas con leyendas, ¿verdad?

Ed: Buena pregunta, pero, como dijimos, ésa es una decisión de diseño, por lo que la voy a retrasar hasta...

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).

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.

Vinod: Es decir, el plano real está constituido por paredes que contienen en su interior cámaras y sensores. ¿Cómo sabe el plano dónde colocar estos objetos?


Jamie: Momento... Apuesto a que ya lo has imaginado.

Jamie: Me parece muy bien, pero tengo más preguntas.

14/1/10 14:29:20

148

PAR T E DOS

MO D E LADO

(Jamie hace preguntas que dan como resultado modificaciones menores.)

Ed: No estoy seguro de cómo hacerlas. Vinod: No es difícil y en verdad convienen. Te mostraré.

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.

6.5.4

Modelado clase-responsabilidad-colaborador (CRC)

El modelado clase-responsabilidad-colaborador (CRC) [Wir90] proporciona una manera sencilla

Cita: “Un propósito de las tarjetas CRC es que fallen pronto, con frecuencia y en forma barata. Es mucho más barato desechar tarjetas que reorganizar una gran cantidad de código fuente.” C. Horstman

de identificación y organización de las clases que son relevantes para los requerimientos de un sistema o producto. Ambler [Amb95] describe el modelado CRC en la siguiente forma: Un modelo CRC en realidad es un conjunto de tarjetas índice estándar que representan clases. Las tarjetas se dividen en tres secciones. En la parte superior de la tarjeta se escribe el nombre de la clase, en la parte izquierda del cuerpo se enlistan las responsabilidades de la clase y en la derecha, los colaboradores.

En realidad, el modelo CRC hace uso de tarjetas índice reales o virtuales. El objetivo es desarrollar una representación organizada de las clases. Las responsabilidades son los atributos y ope-

FIGURA 6.10 Plano

Diagrama de clase para Plano (véase el análisis en el recuadro)

tipo nombre DimensionesExteriores DeterminarTipo( ) PosicionarPlano( ) escala( ) cambiar color( )

Se coloca dentro Es parte de

Cámara

Pared

tipo identificación ubicación VistadeCampo ÁngulodeApertura FijarAcercamiento DeterminarTipo( ) TrasladarUbicación( ) DesplegarIdentificación( ) DesplegarVista( ) DesplegarAcercamiento( )


tipo DimensionesdePared

DeterminarTipo( ) CalcularDimensiones( )

Se usa para construir

Se usa para construir Se usa para construir

SegmentodePared

Ventana

Puerta

tipo CoordenadasdeInicio CoordenadasFinales SiguienteSegmentodePared

tipo CoordenadasdeInicio CoordenadasFinales SiguienteVentana

tipo CoordenadasdeInicio CoordenadasFinales SiguientePuerta

DeterminarTipo( ) dibujar( )



14/1/10 14:29:21

C AP Í T UL O 6

149


FIGURA 6.11 Modelo de tarjeta CRC índice

Class:

Class:

Des Class: De Clase: Plano D R e s Descripción

Responsabilidad:

Co lla a b o r at o r : Co o llab o r at o r : C o llab o r at o r :

Colaborador:

Define nombre y tipo del plano Administra el posicionamiento del plano Da escala al plano para mostrarlo en pantalla Incorpora paredes, puertas y ventanas

Pared

Muestra la posición de las cámaras de video

Cámara

raciones relevantes para la clase. En pocas palabras, una responsabilidad es “cualquier cosa que la clase sepa o haga” [Amb95]. Los colaboradores son aquellas clases que se requieren para dar a una clase la información necesaria a fin de completar una responsabilidad. En general, una colaboración implica una solicitud de información o de cierta acción. En la figura 6.11 se ilustra una tarjeta CRC índice sencilla para la clase Plano: la lista de responsabilidades en la tarjeta CRC es preliminar y está sujeta a agregados o modificaciones. Las clases Pared y Cámara se anotan frente a la responsabilidad que requerirá su colaboración. WebRef En la dirección www.theumlcafe. com/a0079.htm hay un análisis excelente de estos tipos de clase.

Clases. Al inicio de este capítulo se presentaron lineamientos básicos para identificar clases y objetos. La taxonomía de tipos de clase presentada en la sección 6.5.1 puede ampliarse con las siguientes categorías:

• Clases de entidad, también llamadas clases modelo o de negocio, se extraen directamente del enunciado del problema (por ejemplo, Plano y Sensor). Es común que estas clases

Cita: “Pueden clasificarse científicamente los objetos en tres grandes categorías: los que no funcionan, los que se descomponen y los que se pierden.” Rusell Baker

representen cosas almacenadas en una base de datos y que persistan mientras dure la aplicación (a menos que se eliminen en forma específica).

• Clases de frontera se utilizan para crear la interfaz (por ejemplo, pantallas interactivas o reportes impresos) que el usuario mira y con la que interactúa cuando utiliza el software. Los objetos de entidad contienen información que es importante para los usuarios, pero no se muestran por sí mismos. Las clases de frontera se diseñan con la responsabilidad de administrar la forma en la que se presentan a los usuarios los objetos de entidad. Por ejemplo, una clase de frontera llamada VentanadeCámara tendría la responsabilidad de desplegar la salida de una cámara de vigilancia para el sistema CasaSegura.

• Clases de controlador administran una “unidad de trabajo” [UML03] de principio a fin. Es decir, las clases de controlador están diseñadas para administrar 1) la creación o actualización de objetos de entidad, 2) las instancias de los objetos de frontera en tanto obtienen información de los objetos de entidad, 3) la comunicación compleja entre conjuntos de objetos y 4) la validación de datos comunicados entre objetos o entre el usuario y la aplicación. En general, las clases de controlador no se consideran hasta haber comenzado la actividad de diseño.

?

¿Qué lineamientos se aplican para asignar responsabilidades a las clases?


Responsabilidades.

En las secciones 6.5.2 y 6.5.3 se presentaron los lineamientos básicos

para identificar responsabilidades (atributos y operaciones). Wirfs-Brock et al. [Wir90] sugieren cinco lineamientos para asignar responsabilidades a las clases:

14/1/10 14:29:21

150

PAR T E DOS

MO D E LADO

1. La inteligencia del sistema debe estar distribuida entre las clases para enfrentar mejor las necesidades del problema. Toda aplicación contiene cierto grado de inteligencia, es decir, lo que el sistema sabe y lo que puede hacer. Esta inteligencia se distribuye entre las clases de diferentes maneras. Las clases “tontas” (aquellas que tienen pocas responsabilidades) pueden modelarse para que actúen como subordinadas de ciertas clases “inteligentes” (las que tienen muchas responsabilidades). Aunque este enfoque hace directo el flujo del control en un sistema, tiene algunas desventajas: concentra toda la inteligencia en pocas clases, lo que hace que sea más difícil hacer cambios, y tiende a que se requieran más clases y por ello más trabajo de desarrollo. Si la inteligencia del sistema tiene una distribución más pareja entre las clases de una aplicación, cada objeto sabe algo, sólo hace unas cuantas cosas (que por lo general están bien identificadas) y la cohesión del sistema mejora.17 Esto facilita el mantenimiento del software y reduce el efecto de los resultados colaterales del cambio. Para determinar si la inteligencia del sistema está distribuida en forma apropiada, deben evaluarse las responsabilidades anotadas en cada modelo de tarjeta CRC índice a fin de definir si alguna clase tiene una lista demasiado larga de responsabilidades. Esto indica una concentración de inteligencia.18 Además, las responsabilidades de cada clase deben tener el mismo nivel de abstracción. Por ejemplo, entre las operaciones enlistadas para una clase agregada llamada RevisarCuenta, un revisor anota dos responsabilidades: hacer el balance de la cuenta y eliminar comprobaciones concluidas. La primera operación (responsabilidad) implica un procedimiento matemático complejo y lógico. La segunda es una simple actividad de oficina. Como estas dos operaciones no están en el mismo nivel de abstracción, eliminar comprobaciones concluidas debe colocarse dentro de las responsabilidades de RevisarEntrada, clase que está incluida en la clase agregada RevisarCuenta. 2. Cada responsabilidad debe enunciarse del modo más general posible. Este lineamiento implica que las responsabilidades generales (tanto atributos como operaciones) deben residir en un nivel elevado de la jerarquía de clases (porque son generales y se aplicarán a todas las subclases). 3. La información y el comportamiento relacionado con ella deben residir dentro de la misma clase. Esto logra el principio orientado a objetos llamado encapsulamiento. Los datos y los procesos que los manipulan deben empacarse como una unidad cohesiva. 4. La información sobre una cosa debe localizarse con una sola clase, y no distribuirse a través de muchas. Una sola clase debe tener la responsabilidad de almacenar y manipular un tipo específico de información. En general, esta responsabilidad no debe ser compartida por varias clases. Si la información está distribuida, es más difícil dar mantenimiento al software y más complicado someterlo a prueba. 5. Cuando sea apropiado, las responsabilidades deben compartirse entre clases relacionadas. Hay muchos casos en los que varios objetos relacionados deben tener el mismo comportamiento al mismo tiempo. Por ejemplo, considere un juego de video que deba tener en la pantalla las clases siguientes: Jugador, CuerpodelJugador, BrazosdelJugador, PiernasdelJugador y CabezadelJugador. Cada una de estas clases tiene sus propios atributos (como posición, orientación, color y velocidad) y todas deben actualizarse y desplegarse a medida que el usuario manipula una palanca de juego. Las res-

17 La cohesión es un concepto de diseño que se estudia en el capítulo 8. 18 En tales casos, puede ser necesario dividir la clase en una multiplicidad de ellas o completar subsistemas con el objeto de distribuir la inteligencia de un modo más eficaz.


14/1/10 14:29:21

C AP Í T UL O 6

151


ponsabilidades actualizar( ) y desplegar( ) deben, por tanto, ser compartidas por cada uno de los objetos mencionados. Jugador sabe cuando algo ha cambiado y requiere actualizarse( ). Colabora con los demás objetos para obtener una nueva posición u orientación, pero cada objeto controla su propio despliegue en la pantalla. Colaboraciones.

Una clase cumple sus responsabilidades en una de dos formas: 1) usa sus

propias operaciones para manipular sus propios atributos, con lo que satisface una responsabilidad particular o 2) colabora con otras clases. Wirfs-Brock et al. [Wir90] definen las colaboraciones del modo siguiente: Las colaboraciones representan solicitudes que hace un cliente a un servidor para cumplir con sus responsabilidades. Una colaboración es la materialización del contrato entre el cliente y el servidor [...] Decimos que un objeto colabora con otro si, para cumplir una responsabilidad, necesita enviar al otro objeto cualesquiera mensajes. Una sola colaboración fluye en una dirección: representa una solicitud del cliente al servidor. Desde el punto de vista del cliente, cada una de sus colaboraciones está asociada con una responsabilidad particular implementada por el servidor.

Las colaboraciones se identifican determinando si una clase puede cumplir cada responsabilidad. Si no es así, entonces necesita interactuar con otra clase. Ésa es una colaboración. Como ejemplo, considere la función de seguridad de CasaSegura. Como parte del procedimiento de activación, el objeto PaneldeControl debe determinar si están abiertos algunos sensores. Se define una responsabilidad llamada determinar-estado-delsensor( ). Si los sensores están abiertos, PaneldeControl debe fijar el atributo estado como “no está listo”. La información del sensor se adquiere de cada objeto Sensor. Por tanto, la responsabilidad determinar-estadodelsensor( ) se cumple sólo si PaneldeControl trabaja en colaboración con Sensor. Para ayudar a identificar a los colaboradores, se estudian tres relaciones generales diferentes entre las clases [Wir90]: 1) la relación es-parte-de, 2) la relación tiene-conocimiento-de y 3) la relación depende-de. En los párrafos siguientes se analizan brevemente cada una de estas tres responsabilidades generales. Todas las clases que forman parte de una clase agregada se conectan a ésta por medio de una relación es-parte-de. Considere las clases definidas por el juego mencionado antes, la clase CuerpodelJugador es-parte-de Jugador, igual que BrazosdelJugador, PiernasdelJugador y CabezadelJugador. En UML, estas relaciones se representan como el agregado que se ilustra en la figura 6.12. Cuando una clase debe adquirir información de otra, se establece la relación tiene-conocimientode. La responsabilidad determinar-estado-delsensor( ) ya mencionada es un ejemplo de ello.

FIGURA 6.12 Jugador

Una clase agregada compuesta

CabezadelJugador


CuerpodelJugador

BrazosdelJugador

PiernasdelJugador

14/1/10 14:29:21

152

PAR T E DOS

MO D E LADO

La relación depende-de significa que dos clases tienen una dependencia que no se determina por tiene-conocimiento-de ni por es-parte-de. Por ejemplo, CabezadelJugador siempre debe estar conectada a CuerpodelJugador (a menos que el juego de video sea particularmente violento), pero cada objeto puede existir sin el conocimiento directo del otro. Un atributo del objeto CabezadelJugador, llamado posición-central, se determina a partir de la posición central de CuerpodelJugador. Esta información se obtiene por medio de un tercer objeto, Jugador, que la obtiene de CuerpodelJugador. Entonces, CabezadelJugador depende-de CuerpodelJugador. En todos los casos, el nombre de la clase colaboradora se registra en el modelo de tarjeta CRC índice, junto a la responsabilidad que produce la colaboración. Por tanto, la tarjeta índice contiene una lista de responsabilidades y las colaboraciones correspondientes que hacen que se cumplan (véase la figura 6.11). Cuando se ha desarrollado un modelo CRC completo, los participantes lo revisan con el empleo del enfoque siguiente [Amb95]: 1. Se da a todos los participantes que intervienen en la revisión (del modelo CRC) un subconjunto del modelo de tarjetas índice CRC. Deben separarse aquellas que colaboran (de modo que ningún revisor deba tener dos tarjetas que colaboren). 2. Todos los escenarios de casos de uso (y los diagramas correspondientes) deben organizarse en dos categorías. 3. El líder de la revisión lee el caso de uso en forma deliberada. Cuando llega a un objeto con nombre, entrega una ficha a la persona que tenga la tarjeta índice de la clase correspondiente. Por ejemplo, un caso de uso de CasaSegura contiene la narración siguiente: El propietario observa el panel de control de CasaSegura para determinar si el sistema está listo para recibir una entrada. Si el sistema no está listo, el propietario debe cerrar físicamente las puertas y ventanas de modo que el indicador listo aparezca [un indicador no está listo implica que un sensor se encuentra abierto, es decir, que una puerta o ventana está abierta].

Cuando en la narración del caso de uso el líder de la revisión llega a “panel de control”, entrega la ficha a la persona que tiene la tarjeta índice PaneldeControl. La frase “implica que un sensor está abierto” requiere que la tarjeta índice contenga una responsabilidad que validará esta implicación (esto lo logra la responsabilidad determinar-estado-delsensor( ). Junto a la responsabilidad, en la tarjeta índice se encuentra el Sensor colaborador. Entonces, la ficha pasa al objeto Sensor. 4. Cuando se pasa la ficha, se pide al poseedor de la tarjeta Sensor que describa las responsabilidades anotadas en la tarjeta. El grupo determina si una (o más) de las responsabilidades satisfacen el requerimiento del caso de uso. 5. Si las responsabilidades y colaboraciones anotadas en las tarjetas índice no se acomodan al caso de uso, éstas se modifican. Lo anterior tal vez incluya la definición de nuevas clases (y las tarjetas CRC índice correspondientes) o la especificación en las tarjetas existentes de responsabilidades o colaboraciones nuevas o revisadas. Este modo de operar continúa hasta terminar el caso de uso. Cuando se han revisado todos los casos de uso, continúa el modelado de los requerimientos. PU

NT

6.5.5

CLAVE

En muchos casos, dos clases de análisis se relacionan de cierto modo con otra, en forma muy

O

Una asociación define una relación entre clases. La multiplicidad define cuántas de una clase se relacionan con cuántas de otra clase.


Asociaciones y dependencias

parecida a como dos objetos de datos se relacionan entre sí (véase la sección 6.4.3). En UML, estas relaciones se llaman asociaciones. Al consultar la figura 6.10, la clase Plano se define con la identificación de un conjunto de asociaciones entre Plano y otras dos clases, Cámara y Pa-

14/1/10 14:29:22

C AP Í T UL O 6

153


C ASA S EGURA 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í.

red. La clase Pared está asociada con tres clases que permiten que se construya ésta, y que son SegmentodePared, Ventana y Puerta. En ciertos casos, una asociación puede definirse con más detalle si se indica multiplicidad. En relación con la figura 6.10, un objeto Pared se construye a partir de uno o más objetos SegmentodePared. Además, el objeto Pared puede contener 0 o más objetos Ventana y 0 o más objetos Puerta. Estas restricciones de multiplicidad se ilustran en la figura 6.13, donde “uno o


14/1/10 14:29:22

154

PAR T E DOS

MO D E LADO

FIGURA 6.13 Pared

Multiplicidad

1

1

1 Se usa para construir

Se usa para construir 1..* SegmentodePared

Se usa para 0..* 0..* construir Ventana Puerta

FIGURA 6.14 MostrarVentana

Dependencias

Cámara <> {password}

más” se representa con 1...*, y para “0 o más” se usa 0...*. En LMU, el asterisco indica una frontera ilimitada en ese rango.19

?

¿Qué es un estereotipo?

Sucede con frecuencia que entre dos clases de análisis existe una relación cliente-servidor. En tales casos, una clase cliente depende de algún modo de la clase servidor, y se establece una relación de dependencia. Las dependencias están definidas por un estereotipo. Un estereotipo es un “mecanismo extensible” [Arl02] dentro del UML que permite definir un elemento especial de modelado con semántica y especialización determinadas. En UML, los estereotipos se representan entre paréntesis dobles angulares (por ejemplo, <<estereotipo>>).

PU

Como ilustración de una dependencia simple dentro del sistema de vigilancia CasaSegura, un

NT

O

CLAVE

Un paquete se utiliza para ensamblar un conjunto de clases relacionadas

objeto Cámara (la clase servidora, en este caso) proporciona una imagen a un objeto MostrarVentana (la clase cliente). La relación entre estos dos objetos no es una asociación simple sino de dependencia. En el caso de uso escrito para la vigilancia (que no se presenta aquí), debe darse una clave especial a fin de observar ubicaciones específicas de las cámaras. Una forma de lograr esto es hacer que Cámara pida un password y luego asegure el permiso a MostrarVentana para que presente el video. Esto se representa en la figura 6.14, donde <> implica que el uso de la salida de cámara se controla con una clave especial.

6.5.6

Paquetes de análisis

Una parte importante del modelado del análisis es la categorización. Es decir, se clasifican distintos elementos del modelo de análisis (por ejemplo, casos de uso y clases de análisis) de ma-

19 Como parte de una asociación, pueden indicarse otras relaciones de multiplicidad: una a una, una a muchas, muchas a muchas, una a un rango específico con límites inferior y superior, y otras.


14/1/10 14:29:22

C AP Í T UL O 6


FIGURA 6.15

155

Nombre del paquete

Paquetes

Ambiente +Árbol +Paisaje +Carretera +Pared +Puente +Edificio +EfectoVisual +Escena

ReglasdelJuego +ReglasdeMovimiento +RestriccionesdelaAcción

Actores +Jugador +Protagonista +Antagonista +RoldeApoyo

nera que se agrupen en un paquete —llamado paquete de análisis— al que se da un nombre representativo. Para ilustrar el uso de los paquetes de análisis, considere el juego de video que se mencionó antes. A medida que se desarrolla el modelo de análisis para el juego de video, se obtiene un gran número de clases. Algunas se centran en el ambiente del juego —las escenas visuales que el usuario ve cuando lo usa—. En esta categoría quedan clases tales como Árbol, Paisaje, Carretera, Pared, Puente, Edificio y EfectoVisual. Otras se centran en los caracteres dentro del juego y describen sus características físicas, acciones y restricciones. Pueden definirse clases como Jugador (ya descrita), Protagonista, Antagonista y RolesdeApoyo. Otras más describen las reglas del juego —cómo se desplaza un jugador por el ambiente—. Candidatas para esto son clases como ReglasdeMovimiento y RestriccionesdelaAcción. Pueden existir muchas otras categorías. Estas clases se agrupan en los paquetes de análisis que se observan en la figura 6.15. El signo más (suma) que precede al nombre de la clase de análisis en cada paquete, indica que las clases tienen visibilidad pública, por lo que son accesibles desde otros paquetes. Aunque no se aprecia en la figura, hay otros símbolos que preceden a un elemento dentro de un paquete. El signo menos (resta) indica que un elemento queda oculto desde todos los demás paquetes. Y el símbolo # señala que un elemento es accesible sólo para los paquetes contenidos dentro de un paquete dado.

6. 6

RESUMEN El objetivo del modelado de los requerimientos es crear varias representaciones que describan lo que necesita el cliente, establecer una base para generar un diseño de software y definir un conjunto de requerimientos que puedan ser validados una vez construido el software. El modelo de requerimientos cruza la brecha entre la representación del sistema que describe el sistema en su conjunto y la funcionalidad del negocio, y un diseño de software que describe la arquitectura de la aplicación del software, la interfaz de usuario y la estructura de componentes. Los modelos basados en el escenario ilustran los requerimientos del software desde el punto de vista del usuario. El caso de uso —descripción, hecha con una narración o un formato, de una interacción entre un actor y el software— es el principal elemento del modelado. El caso de uso se obtiene durante la indagación de los requerimientos y define las etapas clave de una función o interacción específica. El grado de formalidad del caso de uso y su nivel de detalle varía, pero


14/1/10 14:29:23

156

PAR T E DOS

MO D E LADO

el resultado final da las entradas necesarias a todas las demás actividades del modelado. Los escenarios también pueden ser descritos con el uso de un diagrama de actividades —representación gráfica parecida a un diagrama de flujo que ilustra el flujo del procesamiento dentro de un escenario específico—. Los diagramas de canal (swimlane) ilustran la forma en la que se asigna el flujo del procesamiento a distintos actores o clases. El modelado de datos se utiliza para describir el espacio de información que será construido o manipulado por el software. El modelado de datos comienza con la representación de los objetos de datos —información compuesta que debe ser entendida por el software—. Se identifican los atributos de cada objeto de datos y se describen las relaciones entre estos objetos. El modelado basado en clases utiliza información obtenida de los elementos del modelado basado en el escenario y en datos, para identificar las clases de análisis. Se emplea un análisis gramatical para obtener candidatas a clase, atributos y operaciones, a partir de narraciones basadas en texto. Se definen criterios para definir una clase. Para definir las relaciones entre clases, se emplean tarjetas índice clase-responsabilidad-colaborador. Además, se aplican varios elementos de la notación UML para definir jerarquías, relaciones, asociaciones, agregaciones y dependencias entre clases. Se emplean paquetes de análisis para clasificar y agrupar clases, de manera que sean más manejables en sistemas grandes.

PROBLEMAS


6.1. ¿Es posible comenzar a codificar de inmediato después de haber creado un modelo de análisis? Explique su respuesta y luego defienda el punto de vista contrario. 6.2. Una regla práctica del análisis es que el modelo “debe centrarse en los requerimientos visibles dentro del dominio del problema o negocio”. ¿Qué tipos de requerimientos no son visibles en dichos dominios? Dé algunos ejemplos. 6.3. ¿Cuál es el propósito del análisis del dominio? ¿Cómo se relaciona con el concepto de patrones de requerimientos? 6.4. ¿Es posible desarrollar un modelo de análisis eficaz sin desarrollar los cuatro elementos que aparecen en la figura 6.3? Explique su respuesta. 6.5. Se pide al lector que construya uno de los siguientes sistemas: a) b) c) d)

Sistema de inscripción a la universidad basado en red. Sistema de procesamiento de órdenes basado en web para una tienda de computadoras. Sistema de facturación simple para un negocio pequeño. Libro de cocina basado en internet, construido en un horno eléctrico o de microondas.

Seleccione el sistema que le interese y desarrolle un diagrama entidad-relación que describa los objetos de datos, relaciones y atributos. 6.6. El departamento de obras públicas de una gran ciudad ha decidido desarrollar un sistema de seguimiento y reparación de baches, basado en web (SSRB). Cuando se reportan los baches, se registran en “sistema de reparación del departamento de obras públicas” y se les asigna un número de identificación, almacenado según la calle, tamaño (en una escala de 1 a 10), ubicación (en medio, cuneta, etc.), distrito (se determina con la dirección en la calle) y prioridad de reparación (determinada por el tamaño del bache). Los datos de la orden de trabajo se asocian con cada bache e incluyen su ubicación y tamaño, número de identificación del equipo de reparación, número de personas en dicho equipo, equipo asignado, horas dedicadas a la reparación, estado del bache (trabajo en proceso, reparado, reparación temporal, no reparado), cantidad de material de relleno utilizado y costo de la reparación (calculado a partir de las horas dedicadas, número de personas, materiales y equipo empleado). Por último, se crea un archivo de daños para mantener la información sobre daños reportados debido al bache, y se incluye el nombre y dirección del ciudadano, número telefónico, tipo de daño y cantidad de dinero por el daño. El SSRB es un sistema en línea, todas las solicitudes se harán en forma interactiva.


14/1/10 14:29:23

C AP Í T UL O 6


157

a) Dibuje un diagrama UML para el caso de uso del sistema SSRB. Tendrá que hacer algunas suposiciones sobre la manera en la que un usuario interactúa con el sistema. b) Desarrolle un modelo de clase para el sistema SSRB. 6.7. Escriba un caso de uso basado en formato para el sistema de administración del hogar CasaSegura descrito de manera informal en el recuadro de la sección 6.5.4. 6.8. Desarrolle un conjunto completo de tarjetas índice de modelo CRC, sobre el producto o sistema que elija como parte del problema 6.5. 6.9. Revise con sus compañeros las tarjetas índice CRC. ¿Cuántas clases, responsabilidades y colaboradores adicionales fueron agregados como consecuencia de la revisión? 6.10. ¿Qué es y cómo se usa un paquete de análisis?

LECTURAS


Los casos de uso son el fundamento de todos los enfoques del modelado de los requerimientos. El tema se analiza con amplitud en Rosenberg y Stephens (Use Case Driven Object Modeling with UML: Theory and Practice, Apress, 2007), Denny (Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley, 2005), Alexander y Maiden (eds.) (Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Wiley, 2004), Bittner y Spence (Use Case Modeling, Addison-Wesley, 2002), Cockburn [Coc01b] y en otras referencias mencionadas en los capítulos 5 y 6. El modelado de datos constituye un método útil para examinar el espacio de información. Los libros de Hoberman [Hob06] y Simsion y Witt [Sim05] hacen tratamientos razonablemente amplios. Además, Allen y Terry (Beginning Relational Data Modeling, 2a. ed., Apress, 2005), Allen (Data Modeling for Everyone, Word Press, 2002), Teorey et al. (Database Modeling and Design: Logical Design, 4a. ed., Morgan Kaufmann, 2005) y Carlis y Maguire (Mastering Data Modeling, Addison-Wesley, 2000) presentan métodos de aprendizaje detallados para crear modelos de datos de calidad industrial. Un libro interesante escrito por Hay (Data Modeling Patterns, Dorset House, 1995) presenta patrones comunes de modelos de datos que se encuentran en muchos negocios diferentes. Análisis de técnicas de modelado UML que pueden aplicarse tanto para el análisis como para el diseño se encuentran en O’Docherty (Object-Oriented Analysis and Design: Understanding System Development with UML 2.0, Wiley, 2005), Arlow y Neustadt (UML, 2 and the Unified Process, 2a. ed., Addison-Wesley, 2005), Roques (UML in Practice, Wiley, 2004), Dennis et al. (Systems Analysis and Design with UML Version 2.0, Wiley, 2004), Larman (Applying UML and Patterns, 2a. ed., Prentice-Hall, 2001) y Rosenberg y Scott (Use Case Driven Object Modeling with UML, Addison-Wesley, 1999). En internet existe una amplia variedad de fuentes de información sobre el modelado de requerimientos. En el sitio web del libro, en www.mhhe.com/engcs/comsci/pressman/professioal/olc/ser.htm, se halla una lista actualizada de referencias en web que son relevantes para el modelado del análisis.


14/1/10 14:29:23

CAPÍTULO

7 CONCEPTOS

MODELADO

DE LOS REQUERIMIENTOS : FLUJO ,

COMPORTAMIENTO , PATRONES Y WEBAPPS

CLAVE

diagramas de secuencia . . . . 168 especificación del proceso. . . 163 modelado de la navegación . . . . . . . . . . . . . 180 modelo de comportamiento . . . . . . . . . 165 modelo de configuración. . . . 179 modelo del contenido. . . . . . 176 modelo de flujo de control . . 162 modelo de flujo de datos . . . 159 modelo de interacción . . . . . 177 modelo funcional . . . . . . . . . 178 patrones de análisis . . . . . . 169

espués de estudiar en el capítulo 6 los casos de uso, modelado de datos y modelos ba-

D

sados en clase, es razonable preguntar: “¿no son suficientes representaciones del modelado de los requerimientos?”

La única respuesta razonable es: “depende”. Para ciertos tipos de software, el caso de uso puede ser la única representación para modelar

los requerimientos que se necesite. Para otros, se escoge un enfoque orientado a objetos y se desarrollan modelos basados en clase. Pero en otras situaciones, los requerimientos de las aplicaciones complejas demandan el estudio de la manera como se transforman los objetos de datos cuando se mueven a través del sistema; cómo se comporta una aplicación a consecuencia de eventos externos; si el conocimiento del dominio existente puede adaptarse al problema en cuestión; o, en el caso de sistemas y aplicaciones basados en web, cómo unificar el contenido y la funcionalidad para dar al usuario final la capacidad de navegar con éxito por una webapp a fin de lograr sus objetivos.

webapps . . . . . . . . . . . . . . 174

7. 1 R E Q U E R I M I E N T O S

QUE MODELAN LAS ESTRATEGIAS

Un punto de vista del modelado de los requerimientos, llamada análisis estructurado, considera como entidades separadas los datos y los procesos que los transforman. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Los procesos que manipulan objetos de datos se modelan de una forma que muestra cómo transforman los datos cuando los

UNA ¿Qué es? El modelo de requerimientos tiene muchas dimensiones diferentes. En este capítuRÁPIDA lo, el lector aprenderá acerca de modelos orientados al flujo, de modelos de comportamiento y de las consideraciones especiales del análisis de requerimientos que entran en juego cuando se desarrollan webapps. Cada una de estas representaciones de modelado complementa los casos de uso, modelos de datos y modelos basados en clases que se estudiaron en el capítulo 6. ¿Quién lo hace? Un ingeniero de software (a veces llamado analista) construye el modelo con el uso de los requerimientos recabados entre varios participantes. ¿Por qué es importante? La perspectiva de los requerimientos del software crece en proporción directa al número de dimensiones distintas del modelado de los requerimientos. Aunque quizá no se tenga el tiempo, los recursos o la inclinación para desarrollar cada representación sugerida en este capítulo y en el anterior, debe reconocerse que cada enfoque diferente de modelado proporciona una forma distinta de ver el problema. En consecuencia, el lector (y otros participantes) estará mejor preparado para evaluar si ha especificado en forma apropiada aquello que debe lograrse.

MIRADA

¿Cuáles son los pasos? El modelado orientado al flujo da una indicación de la forma en la que las funciones de procesamiento transforman los objetos de datos. El modelado del comportamiento ilustra los estados del sistema y sus clases, así como el efecto que tienen los eventos sobre dichos estados. El modelado basado en patrones utiliza el conocimiento del dominio existente para facilitar el análisis de los requerimientos. Los modelos de requerimientos con webapps están adaptados especialmente para representar requerimientos relacionados con contenido, interacción, función y configuración. ¿Cuál es el producto final? Para el modelado de los requerimientos, es posible escoger una gran variedad de formas basadas en texto y diagramas. Cada una de estas representaciones da una perspectiva de uno o más de los elementos del modelo. ¿Cómo me aseguro de que lo hice bien? Debe revisarse si los productos del trabajo del modelado de los requerimientos son correctos, completos y congruentes. Deben reflejar las necesidades de todos los participantes y establecer los fundamentos desde los que se llevará a cabo el diseño.

158


14/1/10 14:19:36

C AP Í T UL O 7

159


objetos de datos fluyen por el sistema. Un segundo enfoque del modelado de análisis, llamado análisis orientado a objetos, se centra en la definición de clases y en el modo en el que colaboran una con otra para cumplir con los requerimientos del cliente. Aunque el modelo de análisis que se propone en este libro combina características de ambos enfoques, es frecuente que los equipos del software elijan uno de ellos y excluyan las representaciones del otro. La pregunta no es cuál es mejor, sino qué combinación de representaciones dará a los participantes el mejor modelo de los requerimientos del software y cuál será el mejor puente para cruzar la brecha hacia el diseño del software.

7. 2

MODELADO

ORIENTADO AL FLUJO

Aunque algunos ingenieros de software perciben el modelado orientado al flujo como una técnica obsoleta, sigue siendo una de las notaciones más usadas actualmente para hacer el análisis de los requerimientos.1 Si bien el diagrama de flujo de datos (DFD) y la información relacionada no son una parte formal del UML, se utilizan para complementar los diagramas de éste y amplían la perspectiva de los requerimientos y del flujo del sistema. CONSEJO

Algunas personas afirman que los DFD son obsoletos y que no hay lugar para ellos en la práctica moderna. Ese punto de vista excluye un modo potencialmente útil de representación en el nivel del análisis. Si ayuda, use DFD.

El DFD adopta un punto de vista del tipo entrada-proceso-salida para el sistema. Es decir, los objetos de datos entran al sistema, son transformados por elementos de procesamiento y los objetos de datos que resultan de ello salen del software. Los objetos de datos se representan con flechas con leyendas y las transformaciones, con círculos (también llamados burbujas). El DFD se presenta en forma jerárquica. Es decir, el primer modelo de flujo de datos (en ocasiones llamado DFD de nivel 0 o diagrama de contexto) representa al sistema como un todo. Los diagramas posteriores de flujo de datos mejoran el diagrama de contexto y dan cada vez más detalles en los niveles siguientes.

7.2.1 Cita:

Creación de un modelo de flujo de datos

El diagrama de flujo de datos permite desarrollar modelos del dominio de la información y del

“El propósito de los diagramas de flujo de datos es proveer un puente semántico entre los usuarios y los desarrolladores de sistemas.”

dominio funcional. A medida que el DFD se mejora con mayores niveles de detalle, se efectúa

Kenneth Kozar

de flujo de los datos: 1) el nivel 0 del diagrama debe ilustrar el software o sistema como una sola

la descomposición funcional implícita del sistema. Al mismo tiempo, la mejora del DFD da como resultado el refinamiento de los datos conforme avanzan por los procesos que constituyen la aplicación. Unos cuantos lineamientos sencillos ayudan muchísimo durante la elaboración del diagrama

FIGURA 7.1 DFD en el nivel de contexto para la función de seguridad de CasaSegura

Panel de control

Comandos y datos del usuario

Información en pantalla

Software de CasaSegura

Sensores

1


Estado del sensor

Pantalla del panel de control

Tipo de alarma

Tonos del número telefónico

Alarma

Línea telefónica

El modelado del flujo de datos es una actividad fundamental del análisis estructurado.

14/1/10 14:19:37

160

PAR T E DOS

MO D E LADO

burbuja; 2) debe anotarse con cuidado las entradas y salidas principales; 3) la mejora debe comenzar por aislar procesos candidatos, objetos de datos y almacenamiento de éstos, para representarlos en el siguiente nivel; 4) todas las flechas y burbujas deben etiquetarse con nombres significativos; 5) de un nivel a otro, debe mantenerse la continuidad del flujo de información,2 y 6) debe mejorarse una burbuja a la vez. Existe la tendencia natural a complicar innecesariamente el diagrama de flujo de los datos. Esto sucede cuando se trata de ilustrar demasiados detalles en una etapa muy temprana o representar aspectos de procedimiento del software en lugar del flujo de la información. PU

Para ilustrar el uso del DFD y la notación relacionada, consideremos de nuevo la función de

NT

O

CLAVE

Conforme se mejora cada nivel del DFD, debe mantenerse la continuidad del flujo de la información. Esto significa que las entradas y salidas en cierto nivel deben ser las mismas en un nivel mejorado.

seguridad de CasaSegura. En la figura 7.1 se muestra un DFD de nivel 0 para dicha función. Las entidades externas principales (cuadrados) producen información para uso del sistema y consumen información generada por éste. Las flechas con leyendas representan objetos de datos o jerarquías de éstos. Por ejemplo, los comandos y datos del usuario agrupan todos los comandos de configuración, todos los comandos de activación/desactivación, todas las diferentes interacciones y todos los datos que se introducen para calificar o expandir un comando. Ahora debe expandirse el DFD de nivel 0 a un modelo de flujo de datos de nivel 1. Pero, ¿cómo hacerlo? Según el enfoque sugerido en el capítulo 6, debe aplicarse un “análisis gramatical” [Abb83] a la narración del caso de uso que describe la burbuja en el nivel del contexto. Es decir, se aíslan todos los sustantivos (y frases sustantivadas) y verbos (y frases verbales) en la narración del procesamiento de CasaSegura obtenida durante la primera reunión realizada para recabar los requerimientos. Recordemos el análisis gramatical del texto que narra el procesamiento presentado en la sección 6.5.1: La función de seguridad CasaSegura permite que el propietario configure el sistema de seguridad

CONSEJO

cuando se instala, vigila todos los sensores conectados al sistema de seguridad e interactúa con el propietario a través de internet, una PC o un panel de control.

El análisis gramatical no es a prueba de todo, pero da un impulso excelente para arrancar si se tienen dificultades para definir objetos de datos y las transformaciones que operan sobre ellos.

Durante la instalación, la PC de CasaSegura se utiliza para programar y configurar el sistema. Se asigna a cada sensor un número y un tipo, se programa una clave maestra para activar y desactivar el sistema, y se introducen números telefónicos para marcar cuando ocurre un evento de sensor. Cuando se reconoce un evento de sensor, el software invoca una alarma audible instalada en el sistema. Después de un tiempo de retraso que especifica el propietario durante las actividades de configuración del sistema, el software marca un número telefónico de un servicio de monitoreo, proporciona información acerca de la ubicación y reporta la naturaleza del evento detectado. El número telefónico vuelve a marcarse cada 20 segundos hasta que se obtiene la conexión telefónica. El propietario recibe información de seguridad a través de un panel de control, la PC o un navegador, lo que en conjunto se llama interfaz. La interfaz despliega en el panel de control, en la PC o en la ventana del navegador mensajes de aviso e información del estado del sistema. La interacción del propietario tiene la siguiente forma...

CONSEJO

Asegúrese de que la narración del procesamiento que se va a analizar gramaticalmente está escrita con el mismo nivel de abstracción.

En relación con el análisis gramatical, los verbos son los procesos de CasaSegura y se representarán como burbujas en un DFD posterior. Los sustantivos son entidades externas (cuadros), datos u objetos de control (flechas) o almacenamiento de datos (líneas dobles). De lo estudiado en el capítulo 6 se recuerda que los sustantivos y verbos se asocian entre sí (por ejemplo, a cada sensor se asigna un número y tipo; entonces, número y tipo son atributos del objeto de datos sensor). De modo que al realizar un análisis gramatical de la narración de procesamiento en cualquier nivel del DFD, se genera mucha información útil sobre la manera de proceder para la mejora del nivel siguiente. En la figura 7.2 se presenta un DFD de nivel 1 con el empleo de esta información. El proceso en el nivel de contexto que se ilustra en la figura 7.1 ha sido expandido

2

Es decir, los objetos de datos que entran al sistema o a cualquier transformación en cierto nivel deben ser los mismos objetos de datos (o sus partes constitutivas) que entran a la transformación en un nivel mejorado.


14/1/10 14:19:37

C AP Í T UL O 7

161


FIGURA 7.2 DFD de nivel 1 para la función de seguridad de CasaSegura

Panel de control Configurar el sistema

Comandos y datos del usuario

Configurar solicitud

Interactuar con el usuario Password

Iniciar Detener

Procesar password

Sensores

Configuración de datos Configuración de la información

Activar o desactivar el sistema

Mensaje de identificación válida Configuración de datos

Estado del sensor

Configuración Mensaje de datos de activar o desactivar Muestra mensajes y estado

Muestra información

Información de los sensores

Pantalla del panel de control Alarma

Tipo de alarma

Vigilar sensores

Línea telefónica


a seis procesos derivados del estudio del análisis gramatical. De manera similar, el flujo de información entre procesos del nivel 1 ha surgido de dicho análisis. Además, entre los niveles 0 y 1 se mantiene la continuidad del flujo de información. Los procesos representados en el nivel 1 del DFD pueden mejorarse más hacia niveles inferiores. Por ejemplo, el proceso vigilar sensores se mejora en el DFD de nivel 2, como se aprecia en la figura 7.3. De nuevo, observe que entre los niveles se ha mantenido la continuidad del flujo de información. La mejoría de los DFD continúa hasta que cada burbuja realiza una función simple. Es decir, hasta que el proceso representado por la burbuja ejecuta una función que se implementaría fácilmente como componente de un programa. En el capítulo 8 se estudia un concepto llamado

FIGURA 7.3 DFD de nivel 2 que mejora el proceso vigilar sensores

Formato para desplegar Tipo de Información de configuración identificación del sensor, ubicación Datos de configuración Evalúa contra la preparación

Leer sensores Estado del sensor


Tipo de identificación del sensor

Información del sensor

Genera señal de alarma

Tipo de alarma

Datos de la alarma Número telefónico Marcar número Tonos del número telefónico

14/1/10 14:19:38

162

PAR T E DOS

MO D E LADO

cohesión, que se utiliza para evaluar el objeto del procesamiento de una función dada. Por ahora, se trata de mejorar los DFD hasta que cada burbuja tenga “un solo pensamiento”.

7.2.2

Creación de un modelo de flujo de control

Para ciertos tipos de aplicaciones, el modelo de datos y el diagrama de flujo de datos es todo lo que se necesita para obtener una visión significativa de los requerimientos del software. Sin embargo, como ya se dijo, un gran número de aplicaciones son “motivadas” por eventos y no por datos, producen información de control en lugar de reportes o pantallas, y procesan información con mucha atención en el tiempo y el desempeño. Tales aplicaciones requieren el uso del modelado del flujo de control, además de modelar el flujo de datos. Se dijo que un evento o aspecto del control se implementa como valor booleano (por ejemplo, verdadero o falso, encendido o apagado, 1 o 0) o como una lista discreta de condiciones (vacío, bloqueado, lleno, etc.). Se sugieren los lineamientos siguientes para seleccionar eventos candidatos potenciales:

?

• Enlistar todos los sensores que son “leídos” por el software.

¿Cómo seleccionar los eventos potenciales para un diagrama de flujo de control, de estado o CSPEC?

• Enlistar todas las condiciones de interrupción. • Enlistar todos los “interruptores” que son activados por un operador. • Enlistar todas las condiciones de los datos. • Revisar todos los “aspectos de control” como posibles entradas o salidas de especificación del control, según el análisis gramatical de sustantivos y verbos que se aplicó a la narración del procesamiento.

• Describir el comportamiento de un sistema con la identificación de sus estados, identificar cómo se llega a cada estado y definir las transiciones entre estados.

• Centrarse en las posibles omisiones, error muy común al especificar el control; por ejemplo, se debe preguntar: “¿hay otro modo de llegar a este estado o de salir de él?” Entre los muchos eventos y aspectos del control que forman parte del software de CasaSegura, se encuentran evento de sensor (por ejemplo, un sensor se descompone), bandera de cambio (señal para que la pantalla cambie) e interruptor iniciar/detener (señal para encender o apagar el sistema).

7.2.3

La especificación de control

Una especificación de control (CSPEC) representa de dos maneras distintas el comportamiento del sistema (en el nivel desde el que se hizo referencia a él).3 La CSPEC contiene un diagrama de estado que es una especificación secuencial del comportamiento. También puede contener una tabla de activación del programa, especificación combinatoria del comportamiento. La figura 7.4 ilustra un diagrama de estado preliminar4 para el nivel 1 del modelo de flujo de control para CasaSegura. El diagrama indica cómo responde el sistema a eventos conforme pasa por los cuatro estados definidos en este nivel. Con la revisión del diagrama de estado se determina el comportamiento del sistema, y, lo que es más importante, se investiga si existen “agujeros” en el comportamiento especificado. Por ejemplo, el diagrama de estado (véase la figura 7.4) indica que las transiciones del estado Ocioso ocurren si el sistema se reinicia, se activa o se apaga. Si el sistema se activa (por ejem-

3 4

En la sección 7.3 se presenta notación adicional de modelado por comportamiento. La notación del diagrama de estado que se emplea aquí sigue la del UML. En el análisis estructurado se dispone de un “diagrama de transición de estado”, pero el formato UML es mejor en contenido y representación de la información.


14/1/10 14:19:38

C AP Í T UL O 7

FIGURA 7.4

163


Diagrama de estado para la función de seguridad de CasaSegura

Reiniciar Entrar/fijar EstadodelSistema en “inactivo” Interruptor de iniciar/detenerse, Entrar/mostrar en la pantalla el mensaje 1, “Iniciando sistema” Entrar/mostrar en la pantalla el mensaje 2, “Por favor espere” encendido Entrar/fijar EstadodePantalla en ParpadearDespacio Hacer: activar diagnóstico

FallaDetectada/mostrar en la pantalla el mensaje 2 “contacte al proveedor” VigilanciadelEstadodelSistema Entrar/fijar EstadodelSistema en “vigilancia” Entrar/mostrar en la pantalla el mensaje 1 “Activada” Entrar/mostrar en la pantalla el mensaje 2 “” Entrar/fijar en la pantalla EstadodePantalla Hacer: VigilaryControlarelSistema

Ocioso

Sistema bien Reiniciar

Entrar/fijar EstadodelSistema en “inactivo” Entrar/mostrar en la pantalla el mensaje 1 “Listo” Entrar/mostrar en la pantalla el mensaje 2 “” Entrar/fijar en la pantalla EstadodePantalla OprimirTecla/ManipularTecla

Activar Desactivar password

FalsaAlarma

Apagar/Interruptor Apagado Desactivar password ActivarAlarma

Entrar/fijar EstadodelSistema en “VigilaryAlarma” Entrar/mostrar en la pantalla el mensaje 1 “ALARMA” Entrar/mostrar en la pantalla el mensaje 2 DispararSensor Entrar/fijar EstadodePantalla en ParpadearRápido Hacer: SonarAlarma SensorDisparado/ Hacer: NotificaraResponsablesdeAlarma ComienzaCronómetro OprimirTecla/ManipularTecla TiempoTerminado

SensorDisparado/ ReiniciarCronómetro

plo, se enciende el sistema de alarma), ocurre una transición al estado VigilanciadelEstadodelSistema, los mensajes en la pantalla cambian como se muestra y se invoca el proceso SistemadeVigilanciayControl. Fuera del estado SistemadeVigilanciayControl ocurren dos transiciones: 1) cuando se desactiva el sistema hay una transición de regreso al estado Ocioso; 2) cuando se dispara un sensor en el estado ActivarAlarma. Durante la revisión se consideran todas las transiciones y el contenido de todos los estados. La tabla de activación del proceso (TAP) es un modo algo distinto de representar el comportamiento. La TAP representa la información contenida en el diagrama de estado en el contexto de los procesos, no de los estados. Es decir, la tabla indica cuáles procesos (burbujas) serán invocados en el modelo del flujo cuando ocurra un evento. La TAP se usa como guía para un diseñador que debe construir una ejecución que controle los procesos representados en este nivel. En la figura 7.5 se aprecia una TAP para el nivel 1 del modelo de flujo del software de CasaSegura. La CSPEC describe el comportamiento del sistema, pero no da información acerca del funcionamiento interno de los procesos que se activan como resultado de dicho comportamiento. En la sección 7.2.4 se estudia la notación de modelación que da esta información.

7.2.4

La especificación del proceso

La especificación del proceso (PSPEC) se utiliza para describir todos los procesos del modelo del flujo que aparecen en el nivel final de la mejora. El contenido de la especificación del proceso incluye el texto narrativo, una descripción del lenguaje de diseño del programa5 del algoritmo del proceso, ecuaciones matemáticas, tablas o diagramas de actividad UML. Si se da una PSPEC

5

El lenguaje de diseño del programa (LDP) mezcla la sintaxis del lenguaje de programación con el texto narrativo a fin de dar detalles del diseño del procedimiento. En el capítulo 10 se analiza el LDP.


14/1/10 14:19:38

164

PAR T E DOS

MO D E LADO

FIGURA 7.5 eventos de entrada

Tabla de activación del proceso para la función de seguridad de CasaSegura

evento de sensor bandera de parpadeo interruptor de iniciar o detener estado de la acción en pantalla terminado en marcha tiempo terminado

0 0 0 0 0 0

0 0 1 0 0 0

0 1 0 0 1 0

0 1 0 1 0 0

1 0 0 0 0 0

0 0 0 0 0 1

0

0

0

0

1

0

0 0 1 1

1 1 0 0

0 0 1 0

0 0 1 1

1 0 1 0

1 0 1 1

salida señal de alarma activación del proceso vigilar y controlar el sistema activar o desactivar el sistema mostrar mensajes y estado interactuar con el usuario

PU

que acompañe a cada burbuja del modelo del flujo, se crea una “miniespecificación” que sirve

NT

O

como guía para diseñar la componente del software que implementará la burbuja.

CLAVE

La PSPEC es una “miniespecificación” de cada transformación en el nivel más bajo de mejora de un DFD.

Para ilustrar el uso de la PSPEC, considere la transformación procesar password representada en el modelo de flujo de la figura 7.2. La PSPEC de esta función adopta la forma siguiente: PSPEC: procesar password (en el panel de control). La transformación procesar password realiza la validación en el panel de control para la función de seguridad de CasaSegura. Procesar password recibe un password de cuatro dígitos de la función interactuar con usuario. Primero, el password se compara con el password maestro almacenado dentro del sistema. Si el password maestro coincide, se pasa <mensaje de identificación válida = verdadero> a la función mostrar mensaje y estado. Si el

C ASA S EGURA 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 E-P-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.)

14/1/10 14:19:38

C AP Í T UL O 7

165


password maestro no coincide, los cuatro dígitos se comparan con una tabla de passwords secundarios (que deben asignarse para recibir invitados o trabajadores que necesiten entrar a la casa cuando el propietario no esté presente). Si el password coincide con una entrada de la tabla, se pasa <mensaje de identificación válida = verdadero> a la función mostrar mensaje y estado. Si no coinciden, se pasa <mensaje de identificación válida = falso> a la función de mostrar mensaje y estado.

Si en esta etapa se desean detalles algorítmicos adicionales, también puede incluirse una representación del lenguaje de diseño del programa (LDP) como parte de la PSPEC. Sin embargo, muchos profesionales piensan que la versión LDP debe posponerse hasta comenzar el diseño de los componentes.

H ERRAMIENTAS

DE SOFTWARE

Análisis estructurado Objetivo: Las herramientas de análisis estructurado permiten que un ingeniero de software cree modelos de datos, de flujo y de comportamiento en una forma que permite la consistencia y continuidad con facilidad para hacer la revisión, edición y ampliación. Los modelos creados con estas herramientas dan al ingeniero de software la perspectiva de la representación del análisis y lo ayudan a eliminar errores antes de que éstos se propaguen al diseño o, lo que sería peor, a la implementación. Mecánica: Las herramientas de esta categoría son un “diccionario de datos”, como la base de datos central para describir todos los objetos de datos. Una vez definidas las entradas del diccionario, se crean diagramas entidad-relación y se desarrollan las jerarquías de los objetos. Las características de los diagramas de flujo de datos permiten que sea fácil crear este modelo gráfico y también proveen de características para generar PSPEC y CSPEC. Asimismo, las herra-

7. 3

?

¿Cómo se modela la reacción del software ante algún evento externo?

CREACIÓN

mientas de análisis permiten que el ingeniero de software produzca modelos de comportamiento con el empleo del diagrama de estado como notación operativa. Herramientas representativas.6 MacA&D, WinA&D, desarrolladas por software Excel (www. excelsoftware.com), brinda un conjunto de herramientas de análisis y diseño sencillas y baratas para computadoras Mac y Windows. MetaCASE Workbench, desarrollada por MetaCase Consulting (www.metacase.com), es una metaherramienta utilizada para definir un método de análisis o diseño (incluso análisis estructurado) y sus conceptos, reglas, notaciones y generadores. System Architect, desarrollado por Popkin Software (www.popkin. com), da una amplia variedad de herramientas de análisis y diseño, incluso para modelar datos y hacer análisis estructurado.

DE UN MODELO DE COMPORTAMIENTO

La notación de modelado que hemos estudiado hasta el momento representa elementos estáticos del modelo de requerimientos. Es hora de hacer la transición al comportamiento dinámico del sistema o producto. Para hacerlo, dicho comportamiento se representa como función de eventos y tiempo específicos. El modelo de comportamiento indica la forma en la que responderá el software a eventos o estímulos externos. Para generar el modelo deben seguirse los pasos siguientes: 1. Evaluar todos los casos de uso para entender por completo la secuencia de interacción dentro del sistema. 2. Identificar los eventos que conducen la secuencia de interacción y que entienden el modo en el que éstos se relacionan con objetos específicos. 3. Crear una secuencia para cada caso de uso. 4. Construir un diagrama de estado para el sistema. 5. Revisar el modelo de comportamiento para verificar la exactitud y consistencia. En las secciones siguientes se estudia cada uno de estos pasos.

6

Las herramientas mencionadas aquí no son obligatorias sino una muestra de las que hay en esta categoría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores.


14/1/10 14:19:39

166

PAR T E DOS

7.3.1

MO D E LADO

Identificar los eventos con el caso de uso

En el capítulo 6 se aprendió que el caso de uso representa una secuencia de actividades que involucra a los actores y al sistema. En general, un evento ocurre siempre que el sistema y un actor intercambian información. En la sección 7.2.3 se dijo que un evento no es la información que se intercambia, sino el hecho de que se intercambió la información. Un caso de uso se estudia para efectos del intercambio de información. Para ilustrarlo, volvamos al caso de uso de una parte de la función de seguridad de CasaSegura. El propietario utiliza el teclado para escribir un password de cuatro dígitos. El password se compara con el password válido guardado en el sistema. Si el password es incorrecto, el panel de control emitirá un sonido una vez y se reiniciará para recibir entradas adicionales. Si el password es correcto, el panel de control queda en espera de otras acciones.

Las partes subrayadas del escenario del caso de uso indican eventos. Debe identificarse un actor para cada evento, anotarse la información que se intercambia y enlistarse cualesquiera condiciones o restricciones. Como ejemplo de evento común considere la frase subrayada en el caso de uso “el propietario utiliza el teclado para escribir un password de cuatro dígitos”. En el contexto del modelo de los requerimientos, el objeto PropietariodeCasa7 transmite un evento al objeto PaneldeControl. El evento tal vez se llame password introducido. La información que se transfiere son los cuatro dígitos que constituyen el password, pero ésta no es una parte esencial del modelo de comportamiento. Es importante observar que ciertos eventos tienen un efecto explícito en el flujo del control del caso de uso, mientras que otros no lo tienen. Por ejemplo, el evento password introducido no cambia explícitamente el flujo del control del caso de uso, pero los resultados del evento password comparado (derivado de la interacción el “password se compara con el password válido guardado en el sistema”) tendrán un efecto explícito en el flujo de información y control del software CasaSegura. Una vez identificados todos los eventos, se asignan a los objetos involucrados. Los objetos son responsables de la generación de eventos (por ejemplo, Propietario genera el evento password introducido) o de reconocer los eventos que hayan ocurrido en cualquier lugar (PaneldeControl reconoce el resultado binario del evento password comparado).

7.3.2

Representaciones de estado

En el contexto del modelado del comportamiento deben considerarse dos caracterizaciones diferentes de los estados: 1) el estado de cada clase cuando el sistema ejecuta su función y 2) el estado del sistema según se observa desde el exterior cuando realiza su función.8 PU

El estado de una clase tiene características tanto pasivas como activas [Cha93]. Un estado

NT

O

CLAVE

El sistema tiene estados que representan un comportamiento específico observable desde el exterior; una clase tiene estados que representan su comportamiento cuando el sistema realiza sus funciones.

pasivo es sencillamente el estado actual de todos los atributos de un objeto. Por ejemplo, el estado pasivo de la clase Jugador (en la aplicación de juego de video que se vio en el capítulo 6) incluiría los atributos actuales posición y orientación de Jugador, así como otras características de éste que sean relevantes para el juego (por ejemplo, un atributo que incluya deseos mágicos restantes). El estado activo de un objeto indica el estado actual del objeto conforme pasa por una transformación o procesamiento continuos. La clase Jugador tal vez tenga los siguientes estados activos: moverse, en descanso, herido, en curación, atrapado, perdido, etc. Debe ocurrir un evento (en ocasiones llamado disparador o trigger) para forzar a un objeto a hacer una transición de un estado activo a otro. 7

En este ejemplo se supone que cada usuario (propietario) que interactúe con CasaSegura tiene un password de identificación, por lo que es un objeto legítimo.

8

Los diagramas de estado presentados en el capítulo 6 y en la sección 7.3.2 ilustran el estado del sistema. En esta sección, nuestro análisis se centrará en el estado de cada clase dentro del modelo del análisis.


14/1/10 14:19:39

C AP Í T UL O 7

167


FIGURA 7.6

Cronómetro ≤ TiempoBloqueado

Diagrama de estado para la clase PaneldeControl

Bloqueado

Cronómetro > TiempoBloqueado Password = incorrecto y NúmerodeIntentos < MáximodeIntentos Oprimir tecla

Comparación

Lectura Password introducido

Hacer: ValidarPassword

NúmerodeIntentos > MáximodeIntentos

Password = correcto Selección

Activación exitosa

En los párrafos que siguen se analizan dos representaciones distintas del comportamiento. La primera indica la manera en la que una clase individual cambia su estado con base en eventos externos, y la segunda muestra el comportamiento del software como una función del tiempo. Diagramas de estado para clases de análisis.

Un componente de modelo de comporta-

miento es un diagrama de estado UML9 que representa estados activos para cada clase y los eventos (disparadores) que causan cambios en dichos estados activos. La figura 7.6 ilustra un diagrama de estado para el objeto PaneldeControl en la función de seguridad de CasaSegura. Cada flecha que aparece en la figura 7.6 representa una transición de un estado activo de un objeto a otro. Las leyendas en cada flecha representan el evento que dispara la transición. Aunque el modelo de estado activo da una perspectiva útil de la “historia de la vida” de un objeto, es posible especificar información adicional para llegar a más profundidad en la comprensión del comportamiento de un objeto. Además de especificar el evento que hace que la transición ocurra, puede especificarse una guardia y una acción [Cha93]. Una guardia es una condición booleana que debe satisfacerse para que tenga lugar una transición. Por ejemplo, la guardia para la transición del estado de “lectura” al de “comparación” en la figura 7.6 se determina con el análisis del caso de uso:

Si (password de entrada = 4 dígitos) entonces comparar con el password guardado

En general, la guardia para una transición depende del valor de uno o más atributos de un objeto. En otras palabras, depende del estado pasivo del objeto. Una acción sucede en forma concurrente con la transición de estado o como consecuencia de ella, y por lo general involucra una o más operaciones (responsabilidades) del objeto. Por

9

Si el lector no está familiarizado con UML, puede consultar en el apéndice 1 una breve introducción a esta importante notación de modelación.


14/1/10 14:19:39

168

PAR T E DOS

MO D E LADO

FIGURA 7.7 Diagrama de secuencia (parcial) para la función CasaSegura

Sistema listo

A

Sensores

Sistema

Panel de control

Propietario

Lectura

Password introducido Comparación

Solicitud de observación Resultado Password = correcto

NúmerodeIntentos > MáximodeIntentos A

Bloqueado

Solicitud de activación

Cronómetro > TiempoBloqueado Selección

Activación exitosa

Activación exitosa

ejemplo, la acción conectada con el evento password introducido (véase la figura 7.6) es una operación llamada ValidarPassword ( ) que accede a un objeto password y realiza una comparación dígito por dígito para validar el password introducido. Diagramas de secuencia. El segundo tipo de representación del comportamiento, llamado diagrama de secuencia en UML, indica la forma en la que los eventos provocan transiciones de un objeto a otro. Una vez identificados los objetos por medio del análisis del caso de uso, el modelador crea un diagrama de secuencia: representación del modo en el que los eventos causan el flujo de uno a otro como función del tiempo. En esencia, el diagrama de secuencia es una versión taquigráfica del caso de uso. Representa las clases password y los eventos que hacen que el comportamiento avance de una clase a otra. PU

La figura 7.7 ilustra un diagrama parcial de secuencia para la función de seguridad de Casa-

NT

O

CLAVE

A diferencia de un diagrama de estado que representa el comportamiento sin fijarse en las clases involucradas, un diagrama de secuencia representa el comportamiento, describiendo la forma en la que las clases pasan de un estado a otro.

Segura. Cada flecha representa un evento (derivado de un caso de uso) e indica la forma en la que éste canaliza el comportamiento entre los objetos de CasaSegura. El tiempo se mide en la dirección vertical (hacia abajo) y los rectángulos verticales angostos representan el que toma el procesamiento de una actividad. Los estados se presentan a lo largo de una línea de tiempo vertical. El primer evento, sistema listo, se deriva del ambiente externo y canaliza el comportamiento al objeto Propietario. El propietario introduce un password. El evento solicitud de observación pasa al Sistema, que observa el password en una base de datos sencilla y devuelve un resultado (encontrada o no encontrada) a PaneldeControl (ahora en el estado de comparación). Un password válido da como resultado el evento password = correcto hacia Sistema, lo que activa a Sensores con un evento de solicitud de activación. Por último, el control pasa de nuevo al propietario con el evento activación exitosa. Una vez que se ha desarrollado un diagrama de secuencia completo, todos los eventos que causan transiciones entre objetos del sistema se recopilan en un conjunto de eventos de entrada y de salida (desde un objeto). Esta información es útil en la generación de un diseño eficaz para el sistema que se va a construir.


14/1/10 14:19:40

C AP Í T UL O 7

169


H ERRAMIENTAS

DE SOFTWARE

Modelación de análisis generalizado en UML Objetivo: Las herramientas de modelado del análisis dan la capacidad de desarrollar modelos basados en el escenario, en la clase y en el comportamiento con el uso de notación UML. Mecánica: Las herramientas en esta categoría dan apoyo a toda la variedad de diagramas UML requeridos para construir un modelo del análisis (estas herramientas también apoyan el modelado del diseño). Además de los diagramas, las herramientas en esta categoría 1) hacen revisiones respecto de la consistencia y corrección para todos los diagramas UML, 2) proveen vínculos para producir el diseño y generar el código, y 3) construyen una base de datos que permite administrar y evaluar modelos UML grandes requeridos en sistemas complejos. Herramientas representativas:10 Las herramientas siguientes apoyan toda la variedad de diagramas UML que se requieren para modelar el análisis:

7. 4

PATRONES

ArgoUML es una herramienta de fuente abierta disponible en argouml.tigris.org. Enterprise Architect, desarrollada por Sparx Systems (www. sparxsystems.com.au). PowerDesigner, desarrollada por Sybase (www.sybase.com). Rational Rose, desarrollada por IBM (Rational) (www01.ibm. com/software/rational/). System Architect, desarrollada por Popkin Software (www.popkin. com). UML Studio, desarrollada por Pragsoft Corporation (www. pragsoft.com). Visio, desarrollada por Microsoft (www.microsoft.com). Visual UML, desarrollada por Visual Object Modelers (www. visualuml.com).

PARA EL MODELADO DE REQUERIMIENTOS

Los patrones de software son un mecanismo para capturar conocimiento del dominio, en forma que permita que vuelva a aplicarse cuando se encuentre un problema nuevo. En ciertos casos, el conocimiento del dominio se aplica a un nuevo problema dentro del mismo dominio de la aplicación. En otros, el conocimiento del dominio capturado por un patrón puede aplicarse por analogía a otro dominio de una aplicación diferente por completo. El autor original de un patrón de análisis no “crea” el patrón, sino que lo descubre a medida que se realiza el trabajo de ingeniería de requerimientos. Una vez descubierto el patrón, se documenta describiendo “explícitamente el problema general al que es aplicable el patrón, la solución prescrita, las suposiciones y restricciones del uso del patrón en la práctica y, con frecuencia, alguna otra información sobre éste, como la motivación y las fuerzas que impulsan el empleo del patrón, el análisis de las ventajas y desventajas del mismo y referencias a algunos ejemplos conocidos de su empleo en aplicaciones prácticas” [Dev01]. En el capítulo 5 se presentó el concepto de patrones de análisis y se indicó que éstos representan una solución que con frecuencia incorpora una clase, función o comportamiento dentro del dominio de aplicación. El patrón vuelve a utilizarse cuando se hace el modelado de los requerimientos para una aplicación dentro del dominio.11 Los patrones de análisis se guardan en un depósito para que los miembros del equipo de software usen herramientas de búsqueda para encontrarlos y volverlos a emplear. Una vez seleccionado un patrón apropiado, se integra en el modelo de requerimientos, haciendo referencia a su nombre.

7.4.1

Descubrimiento de patrones de análisis

El modelo de requerimientos está formado por una amplia variedad de elementos: basados en el escenario (casos de uso), orientados a datos (el modelo de datos), basados en clases, orientados al flujo y del comportamiento. Cada uno de estos elementos estudia el problema desde

10 Las herramientas mencionadas aquí no son obligatorias sino una muestra de las que hay en esta categoría. En la mayoría de casos, los nombres de las herramientas son marcas registradas por sus respectivos desarrolladores. 11 En el capítulo 12 se presenta un análisis a profundidad del uso de patrones durante el diseño del software.


14/1/10 14:19:40

170

PAR T E DOS

MO D E LADO

una perspectiva diferente y da la oportunidad de descubrir patrones que tal vez suceden en un dominio de aplicación o por analogía en distintos dominios de aplicación. El elemento más fundamental en la descripción de un modelo de requerimientos es el caso de uso. En el contexto de este análisis, un conjunto coherente de casos de uso sirve como base para descubrir uno o más patrones de análisis. Un patrón de análisis semántico (PAS) “es un patrón que describe un conjunto pequeño de casos de uso coherentes que describen a su vez una aplicación general” [Fer00]. Considere el siguiente caso de uso preliminar para el software que se requiere a fin de controlar y vigilar una cámara de visión real y un sensor de proximidad para un automóvil: Caso de uso: Vigilar el movimiento en reversa Descripción: Cuando se coloca el vehículo en reversa, el software de control permite que se transmita un video a una pantalla que está en el tablero, desde una cámara colocada en la parte posterior. El software superpone varias líneas de orientación y distancia en la pantalla a fin de que el operador del auto mantenga la orientación cuando éste se mueve en reversa. El software de control también vigila un sensor de proximidad con el fin de determinar si un objeto se encuentra dentro de una distancia de 10 pies desde la parte trasera del carro. Esto frenará al vehículo de manera automática si el sensor de proximidad indica que hay un objeto a x pies de la defensa trasera, donde x se determina con base en la velocidad del automóvil.

Este caso de uso implica varias funciones que se mejorarían y elaborarían (en un conjunto coherente de casos de uso) durante la reunión para recabar y modelar los requerimientos. Sin importar cuánta elaboración se logre, los casos de uso sugieren un PAS sencillo pero con amplias aplicaciones (la vigilancia y control de sensores y actuadores de un sistema físico con base en software). En este caso, los “sensores” dan información en video sobre la proximidad. El “actuador” es el sistema de frenado del vehículo (que se invoca si hay un objeto muy cerca de éste). Pero en un caso más general, se descubre un patrón de aplicación muy amplio. En muchos dominios distintos de aplicación, se requiere software para vigilar sensores y controlar actuadores físicos. Se concluye que podría usarse mucho un patrón de análisis que describa los requerimientos generales para esta capacidad. El patrón, llamado Actuador-Sensor, se aplicaría como parte del modelo de requerimientos para CasaSegura y se analiza en la sección 7.4.2, a continuación.

7.4.2

Ejemplo de patrón de requerimientos: Actuador-Sensor12

Uno de los requerimientos de la función de seguridad de CasaSegura es la capacidad de vigilar sensores de seguridad (por ejemplo, sensores de frenado, de incendio, de humo o contenido de CO, de agua, etc.). Las extensiones basadas en internet para CasaSegura requerirán la capacidad de controlar el movimiento (por ejemplo, apertura, acercamiento, etc.) de una cámara de seguridad dentro de una residencia. La implicación es que el software de CasaSegura debe manejar varios sensores y “actuadores” (como los mecanismos de control de las cámaras). Konrad y Cheng [Kon02] sugieren un patrón llamado Actuador-Sensor que da una guía útil para modelar este requerimiento dentro del software de CasaSegura. A continuación se presenta una versión abreviada del patrón Actuador-Sensor, desarrollada originalmente para aplicaciones automotrices. Nombre del patrón.

Actuador-Sensor

Objetivo. Especifica distintas clases de sensores y actuadores en un sistema incrustado. Motivación. Por lo general, los sistemas incrustados tienen varias clases de sensores y actuadores, conectados en forma directa o indirecta con una unidad de control. Aunque muchos de

12 Esta sección se adaptó de [Kon02] con permiso de los autores.


14/1/10 14:19:40

C AP Í T UL O 7

171


los sensores y actuadores se ven muy distintos, su comportamiento es lo bastante similar como para estructurarlos en un patrón. Éste ilustra la forma de especificar los sensores y actuadores para un sistema, incluso los atributos y operaciones. El patrón Actuador-Sensor usa un mecanismo para jalar (solicitud explícita de información) SensoresPasivos y otro mecanismo para empujar (emisión de información) los SensoresActivos. Restricciones

• Cada sensor pasivo debe tener algún método para leer la entrada de un sensor y los atributos que representan al valor del sensor.

• Cada sensor activo debe tener capacidades para emitir mensajes actualizados cuando su valor cambie.

• Cada sensor activo debe enviar un latido de vida, mensaje de estado que se emite cada cierto tiempo para detectar fallas.

• Cada actuador debe tener un método para invocar la respuesta apropiada determinada por el CálculodeComponente.

• Cada sensor y actuador deben tener una función implementada para revisar su propio estado de operación.

• Cada sensor y actuador debe ser capaz de someter a prueba la validez de los valores recibidos o enviados y fijar su estado de operación si los valores se encuentran fuera de las especificaciones. Aplicabilidad. Estructura.

Es útil en cualquier sistema en el que haya varios sensores y actuadores.

En la figura 7.8 se presenta un diagrama de clase UML para el patrón Actuador-

Sensor. Actuador, SensorPasivo y SensorActivo son clases abstractas y están escritas con letra cursiva. En este patrón hay cuatro tipos diferentes de sensores y actuadores. Las clases Booleano, Entero y Real representan los tipos más comunes de sensores y actuadores. Las clases complejas de éstos son aquellas que usan valores que no se representan con facilidad en términos de tipos de datos primitivos, tales como los de un radar. No obstante, estos equipos

FIGURA 7.8 Diagrama de secuencia UML para el patrón Actuador-Sensor. Fuente: Adaptado de [Kon02], con permiso.

Cálculo del componente

Sensor pasivo

Sensor booleano pasivo

Actuador

Sensor real pasivo

Actuador booleano

Actuador real

Actuador entero

Actuador complejo

Sensor activo Sensor entero pasivo


Sensor complejo pasivo

Sensor booleano activo

Sensor real activo

Sensor entero activo

Sensor complejo activo

14/1/10 14:19:40

172

PAR T E DOS

FIGURA 7.9

MO D E LADO

Diagrama de clase UML para el patrón Actuador-Sensor. Fuente: Reimpreso de [Kon02], con permiso.

ManejadorFavorito

Sensor de posición

Panel de control

Actuador ControldeApertura

Sensor DispositivodeEntrada Sensor de posición

Actuador DispositivodeSalida ControldeApertura

Obtiene estado de operación Obtiene valor Obtiene valor físico

(Sensor de posición. EstadodeOperación = 1)

Obtiene estado de operación Establece valor Establece valor físico

Obtiene estado de operación Guarda error

(Sensor de Posición. EstadodeOperación = 0)

deben heredar la interfaz de las clases abstractas, ya que deben tener funciones básicas, tales como consultar los estados de operación. Comportamiento: La figura 7.9 presenta un diagrama de secuencia UML para un ejemplo de patrón Actuador-Sensor según podría aplicarse a la función de CasaSegura que controla el posicionamiento (como la apertura y el acercamiento) de una cámara de seguridad. Aquí, el PaneldeControl13 consulta un sensor (uno de posición pasiva) y un actuador (control de apertura) para comprobar el estado de operación con fines de diagnóstico antes de leer o establecer un valor. Los mensajes Establecer un Valor Físico y Obtener un Valor Físico no son mensajes entre objetos. En vez de ello, describen la interacción entre los dispositivos físicos del sistema y sus contrapartes de software. En la parte inferior del diagrama, bajo la línea horizontal, el SensordePosición reporta que el estado de operación es igual a cero. Entonces, el CálculodeComponente (representado como PaneldeControl) envía el código de error para una falla de posición de un sensor al ManejadordeFallas, que decidirá cómo afecta este error al sistema y qué acciones se requieren. Obtiene los datos de los sensores y calcula la respuesta requerida por parte de los actuadores. Participantes. Esta sección de la descripción de patrones “clasifica las clases u objetos incluidos en el patrón de requerimientos” [Kon02] y describe las responsabilidades de cada clase u objeto (véase la figura 7.8). A continuación se presenta una lista abreviada:

• Resumen de SensorPasivo: Define una interfaz para los sensores pasivos. • SensorBooleanoPasivo: Define los sensores booleanos pasivos. • SensorEnteroPasivo: Define los sensores enteros pasivos.

13 El patrón original usa la frase general CálculodeComponente.


14/1/10 14:19:41

C AP Í T UL O 7

173


• SensorRealPasivo: Define los sensores reales pasivos. • Resumen de SensorActivo: Define una interfaz para los sensores activos. • SensorBooleanoActivo: Define los sensores booleanos activos. • SensorEnteroActivo: Define los sensores enteros activos. • SensorRealActivo: Define los sensores reales activos. • Resumen de actuador: Define una interfaz para los actuadores. • ActuadorBooleano: Define los actuadores booleanos. • ActuadorEntero: Define los actuadores enteros. • ActuadorReal: Define los actuadores reales. • CálculodeComponente: Parte central del controlador; obtiene los datos de los sensores y calcula la respuesta requerida para los actuadores.

• SensorComplejoActivo: Los sensores complejos activos tienen la funcionalidad básica de la clase SensorActivo, pero es necesario especificar métodos y atributos adicionales más elaborados.

• SensorComplejoPasivo: Los sensores complejos pasivos tienen la funcionalidad básica de la clase abstracta SensorPasivo, pero se necesita especificar métodos y atributos adicionales más elaborados.

• ActuadorComplejo: Los actuadores complejos también tienen la funcionalidad básica de la clase abstracta Actuador, pero se requiere especificar métodos y atributos adicionales más elaborados. Colaboraciones.

Esta sección describe cómo interactúan los objetos y clases entre sí, y cómo

efectúa cada uno sus responsabilidades.

• Cuando CálculodeComponente necesita actualizar el valor de un SensorPasivo, consulta a los sensores y solicita el valor enviando el mensaje apropiado.

• Los SensoresActivos no son consultados. Inician la transmisión de los valores del sensor a la unidad de cálculo, con el uso del método apropiado para establecer el valor en CálculodeComponente. Durante un tiempo especificado, envían un latido de vida al menos una vez con el fin de actualizar sus parámetros de tiempo con el reloj del sistema.

• Cuando CálculodeComponente necesita establecer el valor de un actuador, envía el valor a éste.

• CálculodeComponente consulta y establece el estado de operación de los sensores y actuadores por medio de los métodos apropiados. Si un estado de operación es cero, entonces se envía el error al ManejadordeFallas, clase que contiene métodos para manejar mensajes de error, tales como reiniciar un mecanismo más elaborado de recuperación o un dispositivo de respaldo. Si no es posible la recuperación, entonces el sistema sólo usa el último valor conocido para el sensor o uno preestablecido.

• Los SensoresActivos ofrecen métodos para agregar o retirar los evaluadores o evalúan rangos de los componentes que quieren que reciban los mensajes en caso de un cambio de valor. Consecuencias 1. Las clases sensor y actuador tienen una interfaz común. 2. Sólo puede accederse a los atributos de clase a través de mensajes y la clase decide si se aceptan o no. Por ejemplo, si se establece el valor de un actuador por arriba del


14/1/10 14:19:41

174

PAR T E DOS

MO D E LADO

máximo, entonces la clase actuador tal vez no acepte el mensaje, o quizá emplee un valor máximo preestablecido. 3. La complejidad del sistema es potencialmente reducida debido a la uniformidad de las interfaces para los actuadores y sensores. La descripción del patrón de requerimientos también da referencias acerca de otros requerimientos y patrones de diseño relacionados.

7. 5

MODELADO

D E R E Q U E R I M I E N T O S P A R A W E B A P P S 14

Es frecuente que los desarrolladores de web manifiesten escepticismo cuando se plantea la idea del análisis de los requerimientos para webapps. Acostumbran decir: “después de todo, el proceso de desarrollo en web debe ser ágil y el análisis toma tiempo. Nos hará ser lentos justo cuando necesitemos diseñar y construir la webapp”. El análisis de los requerimientos lleva tiempo, pero resolver el problema equivocado toma aún más tiempo. La pregunta que debe responder todo desarrollador en web es sencilla: ¿estás seguro de que entiendes los requerimientos del problema? Si la respuesta es un “sí” inequívoco, entonces tal vez sea posible omitir el modelado de los requerimientos, pero si la respuesta es “no”, entonces ésta debe llevarse a cabo.

7.5.1

¿Cuánto análisis es suficiente?

El grado en el que se profundice en el modelado de los requerimientos para las webapps depende de los factores siguientes:

• Tamaño y complejidad del incremento de la webapp. • Número de participantes (el análisis ayuda a identificar los requerimientos conflictivos que provienen de distintas fuentes).

• Tamaño del equipo de la webapp. • Grado en el que los miembros del equipo han trabajado juntos antes (el análisis ayuda a desarrollar una comprensión común del proyecto).

• Medida en la que el éxito de la organización depende directamente del éxito de la webapp. El inverso de los puntos anteriores es que a medida que el proyecto se hace más chico, que el número de participantes disminuye, que el equipo de desarrollo es más cohesivo y que la aplicación es menos crítica, es razonable aplicar un enfoque más ligero para el análisis. Aunque es una buena idea analizar el problema antes de que comience el diseño, no es verdad que todo el análisis deba preceder a todo el diseño. En realidad, el diseño de una parte específica de la webapp sólo demanda un análisis de los requerimientos que afectan a sólo esa parte de la webapp. Como un ejemplo proveniente de CasaSegura, podría diseñarse con validez la estética general del sitio web (formatos, colores, etc.) sin tener que analizar los requerimientos funcionales de las capacidades de comercio electrónico. Sólo se necesita analizar aquella parte del problema que sea relevante para el trabajo de diseño del incremento que se va a entregar.

7.5.2

Entrada del modelado de los requerimientos

En el capítulo 2 se analizó una versión ágil del proceso de software general que puede aplicarse cuando se hace la ingeniería de las webapps. El proceso incorpora una actividad de comunica-

14 Esta sección se adaptó de Pressman y Lowe [Pre08], con permiso.


14/1/10 14:19:41

C AP Í T UL O 7


175

ción que identifica a los participantes y las categorías de usuario, el contexto del negocio, las metas definidas de información y aplicación, requerimientos generales de webapps y los escenarios de uso, información que se convierte en la entrada del modelado de los requerimientos. Esta información se representa en forma de descripciones hechas en lenguaje natural, a grandes rasgos, en bosquejos y otras representaciones no formales. El análisis toma esta información, la estructura con el empleo de un esquema de representación definido formalmente (donde sea apropiado) y luego produce como salida modelos más rigurosos. El modelo de requerimientos brinda una indicación detallada de la verdadera estructura del problema y da una perspectiva de la forma de la solución. En el capítulo 6 se introdujo la función AVC-MVC (vigilancia con cámaras). En ese momento, esta función parecía relativamente clara y se describió con cierto detalle como parte del caso de uso (véase la sección 6.2.1). Sin embargo, la revisión del caso de uso quizá revele información oculta, ambigua o poco clara. Algunos aspectos de esta información faltante emergerían de manera natural durante el diseño. Los ejemplos quizá incluyan el formato específico de los botones de función, su aspecto y percepción estética, el tamaño de las vistas instantáneas, la colocación del ángulo de las cámaras y el plano de la casa, o incluso minucias tales como las longitudes máxima y mínima de las claves. Algunos de estos aspectos son decisiones de diseño (como el aspecto de los botones) y otros son requerimientos (como la longitud de las claves) que no influyen de manera fundamental en los primeros trabajos de diseño. Pero cierta información faltante sí podría influir en el diseño general y se relaciona más con la comprensión real de los requerimientos. Por ejemplo: P1: ¿Cuál es la resolución del video de salida que dan las cámaras de CasaSegura? P2: ¿Qué ocurre si se encuentra una condición de alarma mientras la cámara está siendo vigilada? P3: ¿Cómo maneja el sistema las cámaras con vistas panorámicas y de acercamiento? P4: ¿Qué información debe darse junto con la vista de la cámara (por ejemplo, ubicación, fecha y hora, último acceso, etcétera)? Ninguna de estas preguntas fue identificada o considerada en el desarrollo inicial del caso de uso; no obstante, las respuestas podrían tener un efecto significativo en los diferentes aspectos del diseño. Por tanto, es razonable concluir que aunque la actividad de comunicación provea un buen fundamento para entender, el análisis de los requerimientos mejora este entendimiento al dar una interpretación adicional. Como la estructura del problema se delinea como parte del modelo de requerimientos, invariablemente surgen preguntas. Son éstas las que llenan los huecos y, en ciertos casos, en realidad ayudan a encontrarlos. En resumen, la información obtenida durante la actividad de comunicación será la entrada del modelo de los requerimientos, cualquiera que sea, desde un correo electrónico informal hasta un proyecto detallado con escenarios de uso exhaustivos y especificaciones del producto.

7.5.3

Salida del modelado de los requerimientos

El análisis de los requerimientos provee un mecanismo disciplinado para representar y evaluar el contenido y funcionamiento de las webapp, los modos de interacción que hallarán los usuarios y el ambiente e infraestructura en las que reside la webapp. Cada una de estas características se representa como un conjunto de modelos que permiten que los requerimientos de la webapp sean analizados en forma estructurada. Si bien los modelos específicos dependen en gran medida de la naturaleza de la webapp, hay cinco clases principales de ellos:


14/1/10 14:19:41

176

PAR T E DOS

MO D E LADO

• Modelo de contenido: identifica el espectro completo de contenido que dará la webapp. El contenido incluye datos de texto, gráficos e imágenes, video y sonido.

• Modelo de interacción: describe la manera en que los usuarios interactúan con la webapp.

• Modelo funcional: define las operaciones que se aplicarán al contenido de la webapp y describe otras funciones de procesamiento que son independientes del contenido pero necesarias para el usuario final.

• Modelo de navegación: define la estrategia general de navegación para la webapp. • Modelo de configuración: describe el ambiente e infraestructura en la que reside la webapp. Es posible desarrollar cada uno de estos modelos con el empleo de un esquema de representación (llamado con frecuencia “lenguaje”) que permite que su objetivo y estructura se comuniquen y evalúen con facilidad entre los miembros del equipo de ingeniería de web y otros participantes. En consecuencia, se identifica una lista de aspectos clave (como errores, omisiones, inconsistencias, sugerencias de mejora o modificaciones, puntos de aclaración, etc.) para trabajar sobre ellos.

7.5.4

Modelo del contenido de las webapps

El modelo de contenido incluye elementos estructurales que dan un punto de vista importante de los requerimientos del contenido de una webapp. Estos elementos estructurales agrupan los objetos del contenido y todas las clases de análisis, entidades visibles para el usuario que se crean o manipulan cuando éste interactúa con la webapp.15 El contenido puede desarrollarse antes de la implementación de la webapp, mientras ésta se construye o cuando ya opera. En cualquier caso, se incorpora por referencia de navegación en la estructura general de la webapp. Un objeto de contenido es una descripción de un producto en forma de texto, un artículo que describe un evento deportivo, una fotografía tomada en éste, la respuesta de un usuario en un foro de análisis, una representación animada de un logotipo corporativo, una película corta de un discurso o una grabación en audio para una presentación con diapositivas. Los objetos de contenido pueden almacenarse como archivos separados, incrustarse directamente en páginas web u obtenerse en forma dinámica de una base de datos. En otras palabras, un objeto de contenido es cualquier aspecto de información cohesiva que se presente al usuario final. Los objetos de contenido se determinan directamente a partir de casos de uso, estudiando la descripción del escenario respecto de referencias directas e indirectas al contenido. Por ejemplo, se establece en CasaSeguraAsegurada.com una webapp que da apoyo a CasaSegura. Un caso de uso, Comprar componentes seleccionados de CasaSegura, describe el escenario que se requiere para comprar un componente de CasaSegura y que contiene la siguiente oración: Podré obtener información descriptiva y de precios de cada componente del producto.

El modelo de contenido debe ser capaz de describir el objeto de contenido Componente. En muchas circunstancias, para definir los requerimientos para el contenido que debe diseñarse e implementarse, es suficiente una lista sencilla de los objetos de contenido, junto con la descripción breve de cada uno. Sin embargo, en ciertos casos, el modelo de contenido se beneficia de un análisis más rico que ilustre en forma gráfica las relaciones entre los objetos de contenido y la jerarquía que mantiene una webapp. Por ejemplo, tome en cuenta el árbol de datos [Sri01] creado por el componente CasaSeguraAsegurada.com que aparece en la figura 7.10. El árbol representa una jerarquía de informa-

15 Las clases de análisis se estudiaron en el capítulo 6.


14/1/10 14:19:41

C AP Í T UL O 7

177


FIGURA 7.10 Descripción de mercadotecnia

Árbol de datos para el componente CasaSeguraAsegurada.com

Componente

Número de parte

Fotografía

Nombre de la parte

Descripción técnica

Tipo de parte

Esquema

Descripción

Video

Precio

Precio al mayoreo Precio al menudeo

ción que se utiliza para describir un componente. Los aspectos de datos simples o compuestos (uno o más valores de los datos) se representan con rectángulos sin sombra. Los objetos de contenido se representan con rectángulos con sombra. En la figura, descripción está definida por cinco objetos (los rectángulos sombreados). En ciertos casos, uno o más de estos objetos se mejorará más conforme se expanda el árbol de datos. Es posible crear un árbol de datos para cualquier contenido que se componga de múltiples objetos de contenido y aspectos de datos. El árbol de datos se desarrolla como un esfuerzo para definir relaciones jerárquicas entre los objetos de contenido y para dar un medio de revisión del contenido a fin de que se descubran las omisiones e inconsistencias antes de que comience el diseño. Además, el árbol de datos sirve como base para diseñar el contenido.

7.5.5

Modelo de la interacción para webapps

La gran mayoría de webapps permiten una “conversación” entre un usuario final y funcionalidad, contenido y comportamiento de la aplicación. Esta conversación se describe con el uso de un modelo de interacción que se compone de uno o más de los elementos siguientes: 1) casos de uso, 2) diagramas de secuencia, 3) diagramas de estado16 y 4) prototipos de la interfaz de usuario. En muchas instancias, basta un conjunto de casos de uso para describir la interacción en el nivel del análisis (durante el diseño se introducirán más mejoras y detalles). Sin embargo, cuando la secuencia de interacción es compleja e involucra múltiples clases de análisis o muchas tareas, es conveniente ilustrarla de forma más rigurosa mediante un diagrama. El formato de la interfaz de usuario, el contenido que presenta, los mecanismos de interacción que implementa y la estética general de las conexiones entre el usuario y la webapp tienen mucho que ver con la satisfacción de éste y con el éxito conjunto del software. Aunque se afirme que la creación de un prototipo de interfaz de usuario es una actividad de diseño, es una buena idea llevarla a cabo durante la creación del modelo de análisis. Entre más pronto se revise la representación física de la interfaz de usuario, más probable es que los consumidores finales obtengan lo que desean. En el capítulo 11 se estudia con detalle el diseño de interfaces de usuario.

16 Los diagramas de secuencia y los de estado se modelan con el empleo de notación UML. Los diagramas de estado se describen en la sección 7.3. Para mayores detalles, consulte el apéndice 1.


14/1/10 14:19:42

178

PAR T E DOS

MO D E LADO

Como hay muchas herramientas para construir webapps baratas y poderosas en sus funciones, es mejor crear el prototipo de la interfaz con el empleo de ellas. El prototipo debe implementar los vínculos de navegación principales y representar la pantalla general en forma muy parecida a la que se construirá. Por ejemplo, si van a ponerse a disposición del usuario final cinco funciones principales del sistema, el prototipo debe representarlas tal como las verá cuando entre por primera vez a la webapp. ¿Se darán vínculos gráficos? ¿Dónde se desplegará el menú de navegación? ¿Qué otra información verá el usuario? Preguntas como éstas son las que debe responder el prototipo.

7.5.6

Modelo funcional para las webapps

Muchas webapps proporcionan una amplia variedad de funciones de computación y manipulación que se asocian directamente con el contenido (porque lo utilizan o porque lo producen) y es frecuente que sean un objetivo importante de la interacción entre el usuario y la webapp. Por esta razón, deben analizarse los requerimientos funcionales y modelarlos cuando sea necesario. El modelo funcional enfrenta dos elementos de procesamiento de la webapp, cada uno de los cuales representa un nivel distinto de abstracción del procedimiento: 1) funciones observables por los usuarios que entrega la webapp a éstos y 2) las operaciones contenidas en las clases de análisis que implementan comportamientos asociados con la clase. La funcionalidad observable por el usuario agrupa cualesquiera funciones de procesamiento que inicie directamente el usuario. Por ejemplo, una webapp financiera tal vez implemente varias funciones de finanzas (como una calculadora de ahorros para una colegiatura universitaria o un fondo para el retiro). Estas funciones en realidad se implementan con el uso de operaciones dentro de clases de análisis, pero desde el punto de vista del usuario final; el resultado visible es la función (más correctamente, los datos que provee la función). En un nivel más bajo de abstracción del procedimiento, el modelo de requerimientos describe el procesamiento que se realizará por medio de operaciones de clase de análisis. Estas operaciones manipulan los atributos de clase y se involucran como clases que colaboran entre sí para lograr algún comportamiento que se desea. Sin que importe el nivel de abstracción del procedimiento, el diagrama de actividades UML se utiliza para representar detalles de éste. En el nivel de análisis, los diagramas de actividades deben usarse sólo donde la funcionalidad sea relativamente compleja. Gran parte de la complejidad de muchas webapps ocurre no en las funciones que proveen, sino en la naturaleza de la información a que se accede y en las formas en las que se manipula. Un ejemplo de complejidad relativa de la funcionalidad para CasaSeguraAsegurada.com se aborda en un caso de uso llamado Obtener recomendaciones para la distribución de sensores en mi espacio. El usuario ya ha desarrollado la distribución del espacio que se vigilará y en este caso de uso selecciona dicha distribución y solicita ubicaciones recomendables para los sensores dentro de ella. CasaSeguraAsegurada.com responde con la representación gráfica de la distribución por medio de información adicional acerca de la ubicación recomendable para los sensores. La interacción es muy sencilla, el contenido es algo más complejo, pero la funcionalidad subyacente es muy sofisticada. El sistema debe realizar un análisis relativamente complejo de la planta del piso para determinar el conjunto óptimo de sensores. Debe examinar las dimensiones de la habitación, la ubicación de puertas y ventanas, y coordinar éstas con la capacidad y especificaciones de los sensores. ¡No es una tarea fácil! Para describir el procesamiento de este caso de uso se utiliza un conjunto de diagramas de actividades. El segundo ejemplo es el caso de uso Controlar cámaras. En éste, la interacción es relativamente sencilla, pero existe el potencial de una funcionalidad compleja, dado que dicha operación “sencilla” requiere una comunicación compleja con dispositivos ubicados en posiciones remotas y a los que se accede por internet. Una complicación adicional se relaciona con la ne-


14/1/10 14:19:42

C AP Í T UL O 7

179


FIGURA 7.11 Diagrama de actividades para la operación TomarControl deCámara( )

La cámara no está en uso

La cámara está en uso

SolicitarBloqueo deCámara( )

Bloqueo disponible

ObtenerUsuarioActual deCámara( )

Bloqueo no disponible

Reporta que la cámara ha sido bloqueada por el usuario

Reporta que la cámara no está disponible

Reporta que la cámara está en uso y da el nombre del usuario

gociación del control cuando varias personas autorizadas tratan de vigilar o controlar un mismo sensor al mismo tiempo. La figura 7.11 ilustra el diagrama de actividades para la operación TomarControldeCámara que forma parte de la clase de análisis Cámara usada dentro del caso de uso Controlar cámaras. Debe observarse que con el flujo de procedimiento se invocan dos operaciones adicionales: SolicitarBloqueodeCámara ( ), que trata de bloquear la cámara para este usuario, y ObtenerUsuarioActualdeCámara ( ), que recupera el nombre del usuario que controla en ese momento la cámara. Los detalles de construcción indican cómo se invocan estas operaciones, y los de la interfaz para cada operación no se señalan hasta que comienza el diseño de la webapp.

7.5.7

Modelos de configuración para las webapps

En ciertos casos, el modelo de configuración no es sino una lista de atributos del lado del servidor y del lado del cliente. Sin embargo, para webapps más complejas, son varias las dificultades de configuración (por ejemplo, distribuir la carga entre servidores múltiples, arquitecturas caché, bases de datos remotas, distintos servidores que atienden a varios objetos en la misma página web, etc.) que afectan el análisis y diseño. El diagrama de despliegue UML se utiliza en situaciones en las que deben considerarse arquitecturas de configuración compleja. Para CasaSeguraAsegurada.com, deben especificarse el contenido y funcionalidad públicos a fin de que sean accesibles a través de todos los clientes principales de web (como aquéllos con 1 por ciento o más de participación en el mercado).17 A la inversa, es aceptable restringir las funciones más complejas de control y vigilancia (que sólo es accesible para los usuarios tipo Propietario) a un conjunto más pequeño de clientes. El modelo de configuración para CasaSeguraAsegurada.com también especificará la operación cruzada con las bases de datos de productos y aplicaciones de vigilancia.

17 La determinación de la participación en el mercado para los navegadores es notoriamente problemática y varía en función de cuál fuente se utilice. No obstante, en el momento de escribir este libro, Internet Explorer y Firefox eran los únicos que sobrepasaban 30 por ciento, y Mozilla, Opera y Safari los únicos que superaban de manera consistente 1 por ciento.


14/1/10 14:19:42

180

PAR T E DOS

7.5.8

MO D E LADO

Modelado de la navegación

Para modelar la navegación se considera cómo navegará cada categoría de usuario de un elemento de la webapp (como un objeto de contenido) a otro. La mecánica de navegación se define como parte del diseño. En esa etapa debe centrarse la atención en los requerimientos generales de navegación. Deben considerarse las preguntas siguientes:

• ¿Ciertos elementos deben ser más fáciles de alcanzar (requieren menos pasos de navegación) que otros? ¿Cuál es la prioridad de presentación?

• ¿Debe ponerse el énfasis en ciertos elementos para forzar a los usuarios a navegar en esa dirección?

• ¿Cómo deben manejarse los errores en la navegación? • ¿Debe darse prioridad a la navegación hacia grupos de elementos relacionados y no hacia un elemento específico?

• ¿La navegación debe hacerse por medio de vínculos, acceso basado en búsquedas o por otros medios?

• ¿Debe presentarse a los usuarios ciertos elementos con base en el contexto de acciones de navegación previas?

• ¿Debe mantenerse un registro de usuarios de la navegación? • ¿Debe estar disponible un mapa completo de la navegación (en oposición a un solo vínculo para “regresar” o un apuntador dirigido) en cada punto de la interacción del usuario?

• ¿El diseño de la navegación debe estar motivado por los comportamientos del usuario más comunes y esperados o por la importancia percibida de los elementos definidos de la webapp?

• ¿Un usuario puede “guardar” su navegación previa a través de la webapp para hacer expedito el uso futuro?

• ¿Para qué categoría de usuario debe diseñarse la navegación óptima? • ¿Cómo deben manejarse los vínculos externos hacia la webapp? ¿Con la superposición de la ventana del navegador existente? ¿Como nueva ventana del navegador? ¿En un marco separado? Estas preguntas y muchas otras deben plantearse y responderse como parte del análisis de la navegación. Usted y otros participantes también deben determinar los requerimientos generales para la navegación. Por ejemplo, ¿se dará a los usuarios un “mapa del sitio” y un panorama de toda la estructura de la webapp? ¿Un usuario puede hacer una “visita guiada” que resalte los elementos más importantes (objetos y funciones de contenido) con que se disponga? ¿Podrá acceder un usuario a los objetos o funciones de contenido con base en atributos definidos de dichos elementos (por ejemplo, un usuario tal vez desee acceder a todas las fotografías de un edificio específico o a todas las funciones que permiten calcular el peso)?

7. 6

RESUMEN Los modelos orientados al flujo se centran en el flujo de objetos de datos a medida que son transformados por las funciones de procesamiento. Derivados del análisis estructurado, los modelos orientados al flujo usan el diagrama de flujo de datos, notación de modelación que ilustra la manera en la que se transforma la entrada en salida cuando los objetos de datos se mueven a través del sistema. Cada función del software que transforme datos es descrita por la


14/1/10 14:19:42

C AP Í T UL O 7


181

especificación o narrativa de un proceso. Además del flujo de datos, este elemento de modelación también muestra el flujo del control, representación que ilustra cómo afectan los eventos al comportamiento de un sistema. El modelado del comportamiento ilustra el comportamiento dinámico. El modelo de comportamiento utiliza una entrada basada en el escenario, orientada al flujo y elementos basados en clases para representar los estados de las clases de análisis y al sistema como un todo. Para lograr esto, se identifican los estados y se definen los eventos que hacen que una clase (o el sistema) haga una transición de un estado a otro, así como las acciones que ocurren cuando se efectúa dicha transición. Los diagramas de estado y de secuencia son la notación que se emplea para modelar el comportamiento. Los patrones de análisis permiten a un ingeniero de software utilizar el conocimiento del dominio existente para facilitar la creación de un modelo de requerimientos. Un patrón de análisis describe una característica o función específica del software que puede describirse con un conjunto coherente de casos de uso. Especifica el objetivo del patrón, la motivación para su uso, las restricciones que limitan éste, su aplicabilidad en distintos dominios de problemas, la estructura general del patrón, su comportamiento y colaboraciones, así como información suplementaria. El modelado de los requerimientos para las webapps utiliza la mayoría, si no es que todos, los elementos de modelado que se estudian en el libro. Sin embargo, dichos elementos se aplican dentro de un conjunto de modelos especializados que se abocan al contenido, interacción, función, navegación y configuración cliente-servidor en la que reside la webapp.

PROBLEMAS


7.1. ¿Cuál es la diferencia fundamental entre el análisis estructurado y las estrategias orientadas a objetos para hacer el análisis de los requerimientos? 7.2. En un diagrama de flujo de datos, ¿una flecha representa un flujo del control u otra cosa? 7.3. ¿Qué es la “continuidad del flujo de información” y cómo se aplica cuando se mejora el diagrama de flujo de datos? 7.4. ¿Cómo se utiliza el análisis gramatical en la creación de un DFD? 7.5. ¿Qué es una especificación del control? 7.6. ¿Son lo mismo una PSPEC y un caso de uso? Si no es así, explique las diferencias. 7.7. Hay dos tipos diferentes de “estados” que los modelos del comportamiento pueden representar. ¿Cuáles son? 7.8. ¿En qué difiere un diagrama de secuencia de un diagrama de estado? ¿En qué se parecen? 7.9. Sugiera tres patrones de requerimientos para un teléfono inalámbrico moderno y escriba una descripción breve de cada uno. ¿Estos patrones podrían usarse para otros equipos? Dé un ejemplo. 7.10. Seleccione uno de los patrones desarrollados en el problema 7.9 y desarrolle una descripción del patrón razonablemente completa, similar en contenido y estilo a la que se presentó en la sección 7.4.2. 7.11. ¿Cuánto modelado del análisis piensa que se requeriría para CasaSeguraAsegurada.com? ¿Se necesitaría cada uno de los tipos de modelo descritos en la sección 7.5.3? 7.12. ¿Cuál es el propósito del modelo de interacción para una webapp? 7.13. Un modelo funcional de webapp debe retrasarse hasta el diseño. Diga los pros y contras de este argumento. 7.14. ¿Cuál es el propósito de un modelo de configuración? 7.15. ¿En qué difiere el modelo de navegación del modelo de interacción?


14/1/10 14:19:42

182

PAR T E DOS

MO D E LADO

LECTURAS


Se han publicado decenas de libros sobre el análisis estructurado. Todos cubren el tema de manera adecuada, pero algunos son excelentes. DeMarco y Plauger escribieron un clásico (Structured Analysis and System Specification, Pearson, 1985) que sigue siendo una buena introducción a la notación básica. Los libros escritos por Kendall y Kendall (Systems Analysis and Design, 5a. ed., Prentice-Hall, 2002), Hoffer et al. (Modern Systems Analysis and Design, Addison-Wesley, 3a. ed., 2001), Davis y Yen (The Information System Consultant’s Handbook: Systems Analysis and Design, CRC Press, 1998) y Modell (A Professional’s Guide to Systems Analysis, 2a. ed., McGraw-Hill, 1996) son buenas referencias. El escrito por Yourdon (Modern Structured Analysis, Yourdon-Press, 1989) sobre el tema está entre las fuentes más exhaustivas publicadas hasta la fecha. El modelado del comportamiento presenta un punto de vista dinámico e importante del comportamiento de un sistema. Los libros de Wagner et al. (Modeling Software with Finite State Machines: A Practical Approach, Auerbach, 2006) y Boerger y Staerk (Abstract State Machines, Springer, 2003) presentan un análisis completo de los diagramas de estado y de otras representaciones del comportamiento. La mayoría de textos escritos sobre patrones de software se centran en el diseño de éste. Sin embargo, los libros de Evans (Domain-Driven Design, Addison-Wesley, 2003) y Fowler ([Fow03] y ([Fow97]) abordan específicamente los patrones de análisis. Pressman y Lowe presentan un tratamiento profundo del modelado del análisis para webapps [Pre08]. Los artículos contenidos dentro de una antología editada por Murugesan y Desphande (Web Engineering: Managing Diversity and Complexity of Web Application Development, Springer, 2001) analizan distintos aspectos de los requerimientos para las webapps. Además, la edición anual de Proceedings of the International Conference on Web Engineering analiza en forma regular aspectos del modelado de los requerimientos. En internet hay una amplia variedad de fuentes de información sobre modelado de los requerimientos. En el sitio web del libro, www.mhhe.com/engcs/compsci/pressman/professional/olc/ser.htm, se encuentra una lista actualizada de referencias que hay en la red mundial, relevantes para el modelado del análisis.


14/1/10 14:19:42

CAPÍTULO

CONCEPTOS CONCEPTOS

CLAVE

abstracción . . . . . . . . . . . . . 189 arquitectura . . . . . . . . . . . . 190

DE DISEÑO

8

l diseño de software agrupa el conjunto de principios, conceptos y prácticas que llevan al

E

desarrollo de un sistema o producto de alta calidad. Los principios de diseño establecen una filosofía general que guía el trabajo de diseño que debe ejecutarse. Deben entenderse

aspectos. . . . . . . . . . . . . . . 194

los conceptos de diseño antes de aplicar la mecánica de éste, y la práctica del diseño en sí lleva

atributos de la calidad . . . . . 187

a la creación de distintas representaciones del software que sirve como guía para la actividad

buen diseño . . . . . . . . . . . . 187

de construcción que siga.

cohesión . . . . . . . . . . . . . . . 193

El diseño es crucial para el éxito de la ingeniería de software. A principios de la década de

diseño de datos. . . . . . . . . . 199

1990, Mitch Kapor, creador de Lotus 1-2-3, publicó en Dr. Dobbs Journal un “manifiesto del di-

diseño del software. . . . . . . 188

seño de software”. Decía lo siguiente:

diseño orientado a objeto . . 195 división de problemas . . . . . 191

¿Qué es el diseño? Es donde se está con un pie en dos mundos —el de la tecnología y el de las personas y los propósitos humanos— que tratan de unificarse...

independencia funcional . . . . 193

Vitruvio, romano crítico de arquitectura, afirmaba que los edificios bien diseñados eran aquellos

lineamientos de la calidad . . 186

que tenían resistencia, funcionalidad y belleza. Lo mismo se aplica al buen software. Resistencia: un

modularidad . . . . . . . . . . . . 191

programa no debe tener ningún error que impida su funcionamiento. Funcionalidad: un programa debe

ocultamiento de información. . . . . . . . . . . . . 192

se apropiado para los fines que persigue. Belleza: la experiencia de usar el programa debe ser placen-

patrones. . . . . . . . . . . . . . . 191 proceso de diseño . . . . . . . . 186 rediseño . . . . . . . . . . . . . . . 195 refinamiento . . . . . . . . . . . . 194

tera. Éstos son los comienzos de una teoría del diseño de software.

El objetivo del diseño es producir un modelo o representación que tenga resistencia, funcionalidad y belleza. Para lograrlo, debe practicarse la diversificación y luego la convergencia. Belady [Bel81] afirma que “la diversificación es la adquisición de un repertorio de alternativas, materia prima del diseño: componentes, soluciones con los componentes y conocimiento, todo lo cual

UNA ¿Qué es? El diseño es lo que casi todo ingeniero quiere hacer. Es el lugar en el que las RÁPIDA reglas de la creatividad —los requerimientos de los participantes, las necesidades del negocio y las consideraciones técnicas— se unen para formular un producto o sistema. El diseño crea una representación o modelo del software, pero, a diferencia del modelo de los requerimientos (que se centra en describir los datos que se necesitan, la función y el comportamiento), el modelo de diseño proporciona detalles sobre arquitectura del software, estructuras de datos, interfaces y componentes que se necesitan para implementar el sistema. ¿Quién lo hace? Ingenieros de software llevan a cabo cada una de las tareas del diseño. ¿Por qué es importante? El diseño permite modelar el sistema o producto que se va a construir. Este modelo se evalúa respecto de la calidad y su mejora antes de generar código; después, se efectúan pruebas y se involucra a muchos usuarios finales. El diseño es el lugar en el que se establece la calidad del software. ¿Cuáles son los pasos? El diseño representa al software de varias maneras. En primer lugar, debe representarse la

MIRADA

arquitectura del sistema o producto. Después se modelan las interfaces que conectan al software con los usuarios finales, con otros sistemas y dispositivos, y con sus propios componentes constitutivos. Por último, se diseñan los componentes del software que se utilizan para construir el sistema. Cada una de estas perspectivas representa una acción de diseño distinta, pero todas deben apegarse a un conjunto básico de conceptos de diseño que guíe el trabajo de producción de software. ¿Cuál es el producto final? El trabajo principal que se produce durante el diseño del software es un modelo de diseño que agrupa las representaciones arquitectónicas, interfaces en el nivel de componente y despliegue. ¿Cómo me aseguro de que lo hice bien? El modelo de diseño es evaluado por el equipo de software en un esfuerzo por determinar si contiene errores, inconsistencias u omisiones, si existen mejores alternativas y si es posible implementar el modelo dentro de las restricciones, plazo y costo que se hayan establecido.

183


14/1/10 14:31:05

184

PAR T E DOS

MO D E LADO

está contenido en catálogos, libros de texto y en la mente”. Una vez que se reúne este conjunto diversificado de información, deben escogerse aquellos elementos del repertorio que cumplan los requerimientos definidos por la ingeniería y por el modelo de análisis (capítulos 5 a 7). A medida que esto ocurre, se evalúan las alternativas, algunas se rechazan, se converge en “una configuración particular de componentes y, con ello, en la creación del producto final” [Bel81]. La diversificación y la convergencia combinan la intuición y el criterio con base en la experiencia en la construcción de entidades similares, un conjunto de principios heurísticos que guían la forma en la que evoluciona el modelo, un conjunto de criterios que permiten evaluar la calidad y un proceso iterativo que finalmente conduce a una representación del diseño definitivo. El diseño del software cambia continuamente conforme evolucionan los nuevos métodos, surgen mejores análisis y se obtiene una comprensión más amplia.1 Incluso hoy, la mayor parte de las metodologías de diseño de software carece de profundidad, flexibilidad y naturaleza cuantitativa, que normalmente se asocian con las disciplinas de diseño de ingeniería más clásicas. No obstante, sí existen métodos para diseñar software, se dispone de criterios para el diseño con calidad y se aplica la notación del diseño. En este capítulo, se estudian los conceptos y principios fundamentales aplicables a todo el diseño de software, los elementos del modelo del diseño y el efecto que tienen los patrones en el proceso de diseño. En los capítulos 9 a 13 se presentarán varias metodologías de diseño de software, según se aplican en la obtención de arquitecturas e interfaces en el nivel de componente, así como a enfoques de diseño basados en patrones y orientados a web.

8. 1

DISEÑO

EN EL CONTEXTO DE LA INGENIERÍA DE SOFTWARE

El diseño de software se ubica en el área técnica de la ingeniería de software y se aplica sin

Cita:

importar el modelo del proceso que se utilice. El diseño del software comienza una vez que se

“El milagro más común de la ingeniería de software es la transición del análisis al diseño y de éste al código.”

han analizado y modelado los requerimientos, es la última acción de la ingeniería de soft-

Richard Due’

mación necesaria para crear los cuatro modelos de diseño necesarios para la especificación

ware dentro de la actividad de modelado y prepara la etapa de construcción (generación y prueba de código). Cada uno de los elementos del modelo de requerimientos (capítulos 6 y 7) proporciona inforcompleta del diseño. En la figura 8.1 se ilustra el flujo de la información durante el diseño del software. El trabajo de diseño es alimentado por el modelo de requerimientos, manifestado por elementos basados en el escenario, en la clase, orientados al flujo, y del comportamiento. El empleo de la notación y de los métodos de diseño estudiados en los últimos capítulos produce diseños de los datos o clases, de la arquitectura, de la interfaz y de los componentes.

CONSEJO

El diseño del software siempre debe comenzar con el análisis de los datos, pues son el fundamento de todos los demás elementos del diseño. Una vez obtenido el fundamento, se obtiene la arquitectura. Sólo entonces deben realizarse otros trabajos del diseño.

El diseño de datos o clases transforma los modelos de clases (capítulo 6) en realizaciones de clases de diseño y en las estructuras de datos que se requieren para implementar el software. Los objetos y relaciones definidos en el diagrama CRC y el contenido detallado de los datos ilustrado por los atributos de clase y otros tipos de notación dan la base para el diseño de los datos. Parte del diseño de clase puede llevarse a cabo junto con el diseño de la arquitectura del software. Un diseño más detallado de las clases tiene lugar cuando se diseña cada componente del software. El diseño de la arquitectura define la relación entre los elementos principales de la estructura del software, los estilos y patrones de diseño de la arquitectura que pueden usarse para alcanzar

1

Aquellos lectores interesados en la filosofía del diseño de software pueden consultar el inquietante análisis de Philippe Kruchen sobre el diseño “posmoderno” [Kru05a].


14/1/10 14:31:06

C AP Í T UL O 8

FIGURA 8.1

185

CONCEPT OS DE DISEÑO

Traducción del modelo de requerimientos al modelo de diseño

Elementos basados en el escenario Casos de uso - texto Diagramas de casos de uso Diagramas de actividades Diagramas de canal

Elementos orientados al flujo

Diseño en el nivel de componentes

Diagramas de flujo de datos Diagramas de flujo del control Narrativas de procesamiento

Modelo de análisis Elementos del comportamiento Diagramas de estado Diagramas de secuencia

Elementos basados en clases

Diagramas de clases Paquetes de análisis Modelos CRC Diagramas de colaboración

Diseño de la interfaz Diseño de la arquitectura

Diseño de datos o clases

Modelo del diseño

los requerimientos definidos por el sistema y las restricciones que afectan la forma en la que se

Cita: “Hay dos formas de construir un diseño del software. Una es hacerlo tan simple que sea obvio que no hay deficiencias y la otra es hacerlo tan complicado que no haya deficiencias obvias. El primer método es mucho más difícil.” C. A. R. Hoare

implementa la arquitectura [Sha96]. La representación del diseño de la arquitectura —el marco de un sistema basado en computadora— se obtiene del modelo de los requerimientos. El diseño de la interfaz describe la forma en la que el software se comunica con los sistemas que interactúan con él y con los humanos que lo utilizan. Una interfaz implica un flujo de información (por ejemplo, datos o control) y un tipo específico de comportamiento. Entonces, los modelos de escenarios de uso y de comportamiento dan mucha de la información requerida para diseñar la interfaz. El diseño en el nivel de componente transforma los elementos estructurales de la arquitectura del software en una descripción de sus componentes en cuanto a procedimiento. La información obtenida a partir de los modelos basados en clase, flujo y comportamiento sirve como la base para diseñar los componentes. Durante el diseño se toman decisiones que en última instancia afectarán al éxito de la construcción del software y, de igual importancia, a la facilidad con la que puede darse mantenimiento al software. Pero, ¿por qué es tan importante el diseño? La importancia del diseño del software se resume en una palabra: calidad. El diseño es el sitio en el que se introduce calidad en la ingeniería de software. Da representaciones del software que pueden evaluarse en su calidad. Es la única manera de traducir con exactitud a un producto o sistema terminado los requerimientos de los participantes. Es el fundamento de toda la ingeniería de software y de las actividades que dan el apoyo que sigue. Sin diseño se corre el riesgo de obtener un sistema inestable, que falle cuando se hagan cambios pequeños, o uno que sea difícil de someter a prueba, o en el que no sea posible evaluar la calidad hasta que sea demasiado tarde en el proceso de software, cuando no queda mucho tiempo y ya se ha gastado mucho dinero.


14/1/10 14:31:06

186

PAR T E DOS

MO D E LADO

C ASA S EGURA Diseño versus codificación La escena: El cubículo de Jamie, cuando el equipo se prepara para traducir a diseño los requerimientos.

Jamie: ¿Qué?

Participantes: Jamie, Vinod y Ed, miembros del equipo de ingeniería de software para CasaSegura.

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í.

La conversación:

Vinod: Y una arquitectura complicada arruina al mejor código.

Jamie: Ustedes saben, Doug [el gerente del equipo] está obsesionado con el diseño. Tengo que ser honesto, lo que realmente amo es codificar. Denme C++ o Java y soy feliz.

Jamie (piensa unos momentos): Entonces, dicen que no puede representarse la arquitectura con código... eso no es cierto.

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: 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 aún así me gusta más codificar.

Vinod: El nivel de abstracción.

8. 2

EL

PROCESO DE DISEÑO

El diseño de software es un proceso iterativo por medio del cual se traducen los requerimientos en un “plano” para construir el software. Al principio, el plano ilustra una visión holística del software. Es decir, el diseño se representa en un nivel alto de abstracción, en el que se rastrea directamente el objetivo específico del sistema y los requerimientos más detallados de datos, funcionamiento y comportamiento. A medida que tienen lugar las iteraciones del diseño, las mejoras posteriores conducen a niveles menores de abstracción. Éstos también pueden rastrearse hasta los requerimientos, pero la conexión es más sutil.

8.2.1

Lineamientos y atributos de la calidad del software

A través del proceso de diseño se evalúa la calidad de éste de acuerdo con la serie de revisiones

Cita: “…escribir un fragmento inteligente de código que funcione es una cosa; diseñar algo que dé apoyo a largo plazo a una empresa es otra muy diferente”. C. Ferguson

técnicas que se estudia en el capítulo 15. McGlaughlin [McG91] sugiere tres características que funcionan como guía para evaluar un buen diseño:

• Debe implementar todos los requerimientos explícitos contenidos en el modelo de requerimientos y dar cabida a todos los requerimientos implícitos que desean los participantes.

• Debe ser una guía legible y comprensible para quienes generan el código y para los que lo prueban y dan el apoyo posterior.

• Debe proporcionar el panorama completo del software, y abordar los dominios de los datos, las funciones y el comportamiento desde el punto de vista de la implementación. En realidad, cada una de estas características es una meta del proceso de diseño. Pero, ¿cómo se logran? Lineamientos de la calidad. A fin de evaluar la calidad de una representación del diseño, usted y otros miembros del equipo de software deben establecer los criterios técnicos de un buen diseño. En la sección 8.3 se estudian conceptos de diseño que también sirven como crite-


14/1/10 14:31:07

C AP Í T UL O 8

187


rios de calidad del software. En este momento, considere los siguientes lineamientos para el diseño:

?

1. Debe tener una arquitectura que 1) se haya creado con el empleo de estilos o patrones

¿Cuáles son las características de un buen diseño?

arquitectónicos reconocibles, 2) esté compuesta de componentes con buenas características de diseño (éstas se analizan más adelante, en este capítulo), y 3) se implementen en forma evolutiva,2 de modo que faciliten la implementación y las pruebas. 2. Debe ser modular, es decir, el software debe estar dividido de manera lógica en elementos o subsistemas. 3. Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes. 4. Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar y que surjan de patrones reconocibles de datos. 5. Debe llevar a componentes que tengan características funcionales independientes. 6. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambiente externo. 7. Debe obtenerse con el empleo de un método repetible motivado por la información obtenida durante el análisis de los requerimientos del software. 8. Debe representarse con una notación que comunique con eficacia su significado. Estos lineamientos de diseño no se logran por azar. Se consiguen con la aplicación de los principios de diseño fundamentales, una metodología sistemática y con revisión.

I NFOR MACIÓN Evaluación de la calidad del diseño. La revisión técnica El diseño es importante porque permite que un equipo de software evalúe la calidad3 de éste antes de que se implemente, momento en el que es fácil y barato corregir errores, omisiones o inconsistencias. Pero, ¿cómo se evalúa la calidad durante el diseño? El software no puede someterse a prueba porque no hay nada ejecutable. ¿Qué hacer? Durante el diseño, la calidad se evalúa por medio de la realización de una serie de revisiones técnicas (RT). Las RT se estudian con detalle en el capítulo 15,4 pero es útil hacer un resumen de dicha técnica en este momento. Una revisión técnica es una reunión celebrada por miembros del equipo de software. Por lo general, participan dos, tres o cuatro personas, en función del alcance de la información del diseño que se revisará. Cada persona tiene un papel: el líder de la

revisión planea la reunión, establece la agenda y coordina la junta; el secretario toma notas para que no se pierda nada; el productor es la persona cuyo trabajo (por ejemplo, el diseño de un componente del software) se revisa. Antes de la reunión, se entrega a cada persona del equipo una copia del producto del trabajo de diseño y se le pide que la lea y que busque errores, omisiones o ambigüedades. El objetivo al comenzar la reunión es detectar todos los problemas del producto, de modo que puedan corregirse antes de que comience la implementación. Es común que la RT dure entre 90 minutos y 2 horas. Al final de ella, el equipo de revisión determina si se requiere de otras acciones por parte del productor a fin de que se apruebe el producto como porción del modelo del diseño final.

Atributos de la calidad. Hewlett-Packard [Gra87] desarrolló un conjunto de atributos de la

Cita: “La calidad no es algo que se deje arriba de los sujetos y objetos como si fuera el remate de un árbol de navidad.” Robert Pirsig

calidad del software a los que se dio el acrónimo FURPS: funcionalidad, usabilidad, confiabilidad, rendimiento y mantenibilidad. Los atributos de calidad FURPS representan el objetivo de todo diseño de software:

2

Para sistemas pequeños, en ocasiones el diseño puede desarrollarse en forma lineal.

3

Los factores de calidad que se estudian en el capítulo 23 ayudan al equipo de revisión cuando evalúa aquélla.

4

Tal vez el lector considere oportuno revisar el capítulo 15 en este momento. Las revisiones técnicas son una parte crítica del proceso de diseño y un mecanismo importante para lograr su calidad.


14/1/10 14:31:07

188

PAR T E DOS

CONSEJO

Los diseñadores del software tienden a centrarse en el problema que se va a resolver. No olvide que los atributos FURPS siempre forman parte del problema. Deben tomarse en cuenta.

MO D E LADO

• La funcionalidad se califica de acuerdo con el conjunto de características y capacidades del programa, la generalidad de las funciones que se entregan y la seguridad general del sistema.

• La usabilidad se evalúa tomando en cuenta factores humanos (véase el capítulo 11), la estética general, la consistencia y la documentación.

• La confiabilidad se evalúa con la medición de la frecuencia y gravedad de las fallas, la exactitud de los resultados que salen, el tiempo medio para que ocurra una falla (TMPF), la capacidad de recuperación ante ésta y lo predecible del programa.

• El rendimiento se mide con base en la velocidad de procesamiento, el tiempo de respuesta, el uso de recursos, el conjunto y la eficiencia.

• La mantenibilidad combina la capacidad del programa para ser ampliable (extensibilidad), adaptable y servicial (estos tres atributos se denotan con un término más común: mantenibilidad), y además que pueda probarse, ser compatible y configurable (capacidad de organizar y controlar los elementos de la configuración del software, véase el capítulo 22) y que cuente con la facilidad para instalarse en el sistema y para que se detecten los problemas. No todo atributo de la calidad del software se pondera por igual al diseñarlo. Una aplicación tal vez se aboque a lo funcional con énfasis en la seguridad. Otra quizá busque rendimiento con la mira puesta en la velocidad de procesamiento. En una tercera se persigue la confiabilidad. Sin importar la ponderación, es importante observar que estos atributos de la calidad deben tomarse en cuenta cuando comienza el diseño, no cuando haya terminado éste y la construcción se encuentre en marcha.

8.2.2

La evolución del diseño del software

La evolución del diseño del software es un proceso continuo que ya ha cubierto casi seis déca-

Cita: “Un diseñador sabe que alcanzó la perfección no cuando no hay nada por agregar, sino cuando no hay nada que quitar.” Antoine de Saint-Exupery

das. Los primeros trabajos de diseño se concentraban en criterios para el desarrollo de programas modulares [Den73] y en métodos para mejorar estructuras de software con un enfoque de arriba abajo [Wir71]. Los aspectos de procedimiento del diseño evolucionaron hacia una filosofía llamada programación estructurada [Dah72], [Mil72]. Los trabajos posteriores propusieron métodos para traducir el flujo de datos [Ste74] o la estructura de éstos (por ejemplo, [Jac75], [War74]) a una definición de diseño. Los enfoques más nuevos (por ejemplo, [Jac92], [Gam95]) propusieron un enfoque orientado a objeto para diseñar derivaciones. En los últimos tiempos, el énfasis al desarrollar software se pone en la arquitectura de éste [Kru06] y en los patrones de diseño susceptibles de emplearse para implementar arquitecturas y niveles más bajos de abstracciones del diseño (por ejemplo, [Hol06], [Sha05]). Se da cada vez más importancia a los métodos orientados al aspecto (por ejemplo, [Cla05], [Jac04]), al desarrollo orientado al modelo [Sch06] y a las pruebas [Ast04], que se concentran en llegar a una modularidad eficaz y a la estructura arquitectónica de los diseños que se generan.

?

¿Qué características son comunes en todos los métodos de diseño?

En la industria del software se aplican varios métodos de diseño, aparte de los ya mencionados. Igual que los métodos de análisis presentados en los capítulos 6 y 7, cada método de diseño de software introduce heurística y notación únicas, así como un punto de vista sobre lo que caracteriza a la calidad en el diseño. No obstante, todos estos métodos tienen algunas características en común: 1) un mecanismo para traducir el modelo de requerimientos en una representación del diseño, 2) una notación para representar las componentes funcionales y sus interfaces, 3) una heurística para mejorar y hacer particiones y 4) lineamientos para evaluar la calidad. Sin importar el método de diseño que se utilice, debe aplicarse un conjunto de conceptos básicos al diseño en el nivel de datos, arquitectura, interfaz y componente. En las secciones que siguen se estudian estos conceptos.


14/1/10 14:31:07

C AP Í T UL O 8

189


C ONJUNTO

DE TAREAS

Conjunto de tareas generales para el diseño

3.

4.

1. Estudiar el modelo del dominio de la información y diseñar las estructuras de datos apropiadas para los objetos de datos y sus atributos. 2. Seleccionar un estilo de arquitectura que sea adecuado para el software con el uso del modelo de análisis. Hacer la partición del modelo de análisis en subsistemas de diseño y asignar éstos dentro de la arquitectura: Asegúrese de que cada subsistema sea cohesivo en sus funciones. Diseñe interfaces del subsistema. Asigne clases de análisis o funciones a cada subsistema. Crear un conjunto de clases de diseño o componentes: Traduzca la descripción de clases de análisis a una clase de diseño. Compare cada clase de diseño con los criterios de diseño; considere los aspectos hereditarios. Defina métodos y mensajes asociados con cada clase de diseño. Evalúe y seleccione patrones de diseño para una clase de diseño o subsistema.

8. 3

CONCEPTOS

Revise las clases de diseño y, si se requiere, modifíquelas. Diseñar cualesquiera interfaces requeridas con sistemas o dispositivos externos. 6. Diseñar la interfaz de usuario. Revise los resultados del análisis de tareas. Especifique la secuencia de acciones con base en los escenarios de usuario. Cree un modelo de comportamiento de la interfaz. Defina los objetos de la interfaz y los mecanismos de control. Revise el diseño de la interfaz y, si se requiere, modifíquelo. 7. Efectuar el diseño en el nivel de componente. Especifique todos los algoritmos en un nivel de abstracción relativamente bajo. Mejore la interfaz de cada componente. Defina estructuras de datos en el nivel de componente. Revise cada componente y corrija todos los errores que se detecten. 8. Desarrollar un modelo de despliegue. 5.

DE DISEÑO

Durante la historia de la ingeniería de software, ha evolucionado un conjunto de conceptos fundamentales sobre su diseño. Aunque con el paso de los años ha variado el grado de interés en cada concepto, todos han soportado la prueba del tiempo. Cada uno da al diseñador del software el fundamento desde el que pueden aplicarse métodos de diseño sofisticados. Todos ayudan a responder las preguntas siguientes:

• ¿Qué criterios se usan para dividir el software en sus componentes individuales? • ¿Cómo se extraen los detalles de la función o la estructura de datos de la representación conceptual del software?

• ¿Cuáles son los criterios uniformes que definen la calidad técnica de un diseño de software? M. A. Jackson [Jac75] dijo: “El principio de la sabiduría [para un ingeniero de software] es reconocer la diferencia que hay entre hacer que un programa funcione y lograr que lo haga bien”. Los conceptos fundamentales del diseño del software proveen la estructura necesaria para “hacerlo bien”. En las secciones que siguen, se da un panorama breve de los conceptos importantes del diseño de software, tanto del desarrollo tradicional como del orientado a objeto.

Cita: “La abstracción es uno de los modos fundamentales con los que los humanos luchamos con la complejidad.” Grady Booch


8.3.1

Abstracción

Cuando se considera una solución modular para cualquier problema, es posible plantear muchos niveles de abstracción. En el más elevado se enuncia una solución en términos gruesos con el uso del lenguaje del ambiente del problema. En niveles más bajos de abstracción se da la descripción más detallada de la solución. La terminología orientada al problema se acopla con la que se orienta a la implementación, en un esfuerzo por enunciar la solución. Por último,

14/1/10 14:31:08

190

PAR T E DOS

MO D E LADO

en el nivel de abstracción más bajo se plantea la solución, de modo que pueda implementarse directamente. Cuando se desarrollan niveles de abstracción distintos, se trabaja para crear abstracciones CONSEJO

Como diseñador, trabaje mucho para obtener abstracciones tanto de procedimiento como de datos que sirvan para el problema en cuestión. Será aún mejor si sirvieran para un dominio completo de problemas.

tanto de procedimiento como de datos. Una abstracción de procedimiento es una secuencia de instrucciones que tienen una función específica y limitada. El nombre de la abstracción de procedimiento implica estas funciones, pero se omiten detalles específicos. Un ejemplo de esto sería la palabra abrir, en el caso de una puerta. Abrir implica una secuencia larga de pasos del procedimiento (caminar hacia la puerta, llegar y tomar el picaporte, girar éste y jalar la puerta, retroceder para que la puerta se abra, etcétera).5 Una abstracción de datos es un conjunto de éstos con nombre que describe a un objeto de datos. En el contexto de la abstracción de procedimiento abrir, puede definirse una abstracción de datos llamada puerta. Como cualquier objeto de datos, la abstracción de datos para puerta agruparía un conjunto de atributos que describirían la puerta (tipo, dirección del abatimiento, mecanismo de apertura, peso, dimensiones, etc.). Se concluye que la abstracción de procedimiento abrir usaría información contenida en los atributos de la abstracción de datos puerta.

8.3.2 WebRef En la dirección www.sei.cmu. edu/ata/ata_init.html hay un análisis profundo de la arquitectura del software.

Arquitectura

La arquitectura del software alude a “la estructura general de éste y a las formas en las que ésta da integridad conceptual a un sistema” [Sha95a]. En su forma más sencilla, la arquitectura es la estructura de organización de los componentes de un programa (módulos), la forma en la que éstos interactúan y la estructura de datos que utilizan. Sin embargo, en un sentido más amplio, los componentes se generalizan para que representen los elementos de un sistema grande y sus interacciones. Una meta del diseño del software es obtener una aproximación arquitectónica de un sistema. Ésta sirve como estructura a partir de la cual se realizan las actividades de diseño más detalladas. Un conjunto de patrones arquitectónicos permite que el ingeniero de software resuelva problemas de diseño comunes. Shaw y Garlan [Sha95a] describen un conjunto de propiedades que deben especificarse como

Cita:

parte del diseño de la arquitectura:

“Una arquitectura del software es el producto del trabajo de desarrollo que tiene la rentabilidad más alta para una inversión en cuanto a calidad, secuencia de actividades y costo.”

Propiedades estructurales. Este aspecto de la representación del diseño arquitectónico define los componentes de un sistema (módulos, objetos, filtros, etc.) y la manera en la que están agrupados e interactúan unos con otros. Por ejemplo, los objetos se agrupan para que encapsulen tanto datos como el procedimiento que los manipula e interactúen invocando métodos. Propiedades extrafuncionales. La descripción del diseño arquitectónico debe abordar la forma en la que la arquitectura del diseño satisface los requerimientos de desempeño, capacidad, confiabi-

Len Bass et al.

lidad, seguridad y adaptabilidad, así como otras características del sistema. Familias de sistemas relacionados. El diseño arquitectónico debe basarse en patrones repetibles que es común encontrar en el diseño de familias de sistemas similares. En esencia, el diseño debe tener la capacidad de reutilizar bloques de construcción arquitectónica.

CONSEJO

No deje al azar la arquitectura. Si lo hace, pasará el resto del proyecto forzándola para que se ajuste al diseño. Diseñe la arquitectura explícitamente.

Dada la especificación de estas propiedades, el diseño arquitectónico se representa con el uso de uno o más de varios modelos diferentes [Gar95]. Los modelos estructurales representan la arquitectura como un conjunto organizado de componentes del programa. Los modelos de marco aumentan el nivel de abstracción del diseño, al tratar de identificar patrones de diseño arquitectónico repetibles que se encuentran en tipos similares de aplicaciones. Los modelos dinámicos abordan los aspectos estructurales de la arquitectura del programa e indican cómo cambia la

5

Sin embargo, debe notarse que un conjunto de operaciones puede reemplazarse con otro, en tanto la función que implica la abstracción de procedimiento sea la misma. Por tanto, los pasos requeridos para implementar abrir cambiarían mucho si la puerta fuera automática y tuviera un sensor.


14/1/10 14:31:08

C AP Í T UL O 8


191

estructura o la configuración del sistema en función de eventos externos. Los modelos del proceso se centran en el diseño del negocio o proceso técnico al que debe dar acomodo el sistema. Por último, los modelos funcionales se usan para representar la jerarquía funcional de un sistema. Para representar estos modelos, se ha desarrollado cierto número de lenguajes de descripción

Cita: “Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, por lo que describe el núcleo de la solución de ese problema, en forma tal que puede usarse ésta un millón de veces sin repetir lo mismo ni una sola vez.” Christopher Alexander

arquitectónica (LDA) [Sha95b]. Aunque han sido propuestos muchos LDA diferentes, la mayoría tiene mecanismos para describir los componentes del sistema y la manera en la que se conectan entre sí. Debe observarse que hay un debate acerca del papel que tiene la arquitectura en el diseño. Algunos investigadores afirman que la obtención de la arquitectura del software debe separarse del diseño y que ocurre entre las acciones de la ingeniería de requerimientos y las del diseño más convencional. Otros piensan que la definición de la arquitectura es parte integral del proceso de diseño. En el capítulo 9 se estudia la forma en la que se caracteriza la arquitectura del software y su papel en el diseño.

8.3.3

Patrones

Brad Appleton define un patrón de diseño de la manera siguiente: “Es una mezcla con nombre propio de puntos de vista que contienen la esencia de una solución demostrada para un problema recurrente dentro de cierto contexto de necesidades en competencia” [App00]. Dicho de otra manera, un patrón de diseño describe una estructura de diseño que resuelve un problema particular del diseño dentro de un contexto específico y entre “fuerzas” que afectan la manera en la que se aplica y en la que se utiliza dicho patrón. El objetivo de cada patrón de diseño es proporcionar una descripción que permita a un diseñador determinar 1) si el patrón es aplicable al trabajo en cuestión, 2) si puede volverse a usar (con lo que se ahorra tiempo de diseño) y 3) si sirve como guía para desarrollar un patrón distinto en funciones o estructura. En el capítulo 12 se estudian los patrones de diseño.

8.3.4

División de problemas

La división de problemas es un concepto de diseño que sugiere que cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos susceptibles de resolverse u optimizarse de manera independiente. Un problema es una característica o comportamiento que se especifica en el modelo de los requerimientos para el software. Al separar un problema en sus piezas más pequeñas y por ello más manejables, se requiere menos esfuerzo y tiempo para resolverlo. CONSEJO

El argumento para separar los problemas puede llevarse demasiado lejos. Si se divide un problema en un número muy grande de problemas muy pequeños, será fácil resolver cada uno de éstos, pero unificarlos en la solución (integración) será muy difícil.

Si para dos problemas, p1 y p2, la complejidad que se percibe para p1 es mayor que la percibida para p2, entonces se concluye que el esfuerzo requerido para resolver p1 es mayor que el necesario para resolver p2. Como caso general, este resultado es intuitivamente obvio. Lleva más tiempo resolver un problema difícil. También se concluye que cuando se combinan dos problemas, con frecuencia la complejidad percibida es mayor que la suma de la complejidad tomada por separado. Esto lleva a la estrategia de divide y vencerás, pues es más fácil resolver un problema complejo si se divide en elementos manejables. Esto tiene implicaciones importantes en relación con la modularidad del software. La división de problemas se manifiesta en otros conceptos de diseño relacionados: modularidad, aspectos, independencia de funcionamiento y mejora. Cada uno de éstos se estudiará en las secciones siguientes.

8.3.5

Modularidad

La modularidad es la manifestación más común de la división de problemas. El software se divide en componentes con nombres distintos y abordables por separado, en ocasiones llamados módulos, que se integran para satisfacer los requerimientos del problema.


14/1/10 14:31:08

192

PAR T E DOS

MO D E LADO

FIGURA 8.2 Costo total del software

Modularidad y costo del software Costo del esfuerzo

Costo de integración Región de costo mínimo M

Costo por módulo Número de módulos

Se ha dicho que “la modularidad es el único atributo del software que permite que un programa sea manejable en lo intelectual” [Mye78]. El software monolítico (un programa grande compuesto de un solo módulo) no es fácil de entender para un ingeniero de software. El número de trayectorias de control, alcance de referencia, número de variables y complejidad general haría que comprenderlo fuera casi imposible. En función de las circunstancias, el diseño debe descomponerse en muchos módulos con la esperanza de que sea más fácil entenderlos y, en consecuencia, reducir el costo requerido para elaborar el software. Según el punto de vista de la división de problemas, sería posible concluir que si el software se dividiera en forma indefinida, el esfuerzo requerido para desarrollarlo ¡sería despreciable por pequeño! Desafortunadamente, hay otras fuerzas que entran en juego y que hacen que esta conclusión sea (tristemente) inválida. De acuerdo con la figura 8.2, el esfuerzo (costo) de desarrollar un módulo individual de software disminuye conforme aumenta el número total de módulos. Dado el mismo conjunto de requerimientos, tener más módulos significa tamaños individuales más pequeños. Sin embargo, a medida que se incrementa el número de módulos, el esfuerzo (costo) asociado con su integración también aumenta. Estas características llevan a una curva de costo total como la que se muestra en la figura. Existe un número, M, de módulos que arrojarían el mínimo costo de desarrollo, pero no se dispone de las herramientas necesarias para predecir M con exactitud.

?

¿Cuál es el número correcto de módulos para un sistema dado?

Las curvas que aparecen en la figura 8.2 constituyen una guía útil al considerar la modularidad. Deben hacerse módulos, pero con cuidado para permanecer en la cercanía de M. Debe evitarse hacer pocos o muchos módulos. Pero, ¿cómo saber cuál es la cercanía de M? ¿Cuán modular debe hacerse el software? Las respuestas a estas preguntas requieren la comprensión de otros conceptos de diseño que se analizan más adelante en este capítulo. Debe hacerse un diseño (y el programa resultante) con módulos, de manera que el desarrollo pueda planearse con más facilidad, que sea posible definir y desarrollar los incrementos del software, que los cambios se realicen con más facilidad, que las pruebas y la depuración se efectúen con mayor eficiencia y que el mantenimiento a largo plazo se lleve a cabo sin efectos colaterales de importancia.

PU

NT

8.3.6

CLAVE

El concepto de modularidad lleva a una pregunta fundamental: “¿Cómo descomponer una so-

O

El objetivo de ocultar la información es esconder los detalles de las estructuras de datos y el procesamiento tras una interfaz de módulo. No es necesario que los usuarios de éste los conozcan.


Ocultamiento de información

lución de software para obtener el mejor conjunto de módulos?” El principio del ocultamiento de información sugiere que los módulos se “caractericen por decisiones de diseño que se oculten (cada una) de las demás”. En otras palabras, deben especificarse y diseñarse módulos, de forma que la información (algoritmos y datos) contenida en un módulo sea inaccesible para los que no necesiten de ella.

14/1/10 14:31:09

C AP Í T UL O 8


193

El ocultamiento implica que la modularidad efectiva se logra definiendo un conjunto de módulos independientes que intercambien sólo aquella información necesaria para lograr la función del software. La abstracción ayuda a definir las entidades de procedimiento (o informativas) que constituyen el software. El ocultamiento define y hace cumplir las restricciones de acceso tanto a los detalles de procedimiento como a cualquier estructura de datos local que utilice el módulo [Ros75]. El uso del ocultamiento de información como criterio de diseño para los sistemas modulares proporciona los máximos beneficios cuando se requiere hacer modificaciones durante las pruebas, y más adelante, al dar mantenimiento al software. Debido a que la mayoría de los datos y detalles del procedimiento quedan ocultos para otras partes del software, es menos probable que los errores inadvertidos introducidos durante la modificación se propaguen a distintos sitios dentro del software.

8.3.7

Independencia funcional

El concepto de independencia funcional es resultado directo de la separación de problemas y de los conceptos de abstracción y ocultamiento de información. En escritos cruciales sobre el diseño de software, Wirth [Wir71] y Parnas [Par72] mencionan técnicas de mejora que promueven la independencia modular. Los trabajos posteriores de Stevens, Myers y Constantine [Ste74] dan solidez al concepto. La independencia funcional se logra desarrollando módulos con funciones “miopes” que tengan “aversión” a la interacción excesiva con otros módulos. Dicho de otro modo, debe diseñarse software de manera que cada módulo resuelva un subconjunto específico de requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa. Es lógico preguntar por qué es importante la independencia.

?

¿Por qué debe tratarse de crear módulos independientes?

El software con modularidad eficaz, es decir, con módulos independientes, es más fácil de desarrollar porque su función se subdivide y las interfaces se simplifican (cuando el desarrollo es efectuado por un equipo hay que considerar las ramificaciones). Los módulos independientes son más fáciles de mantener (y probar) debido a que los efectos secundarios causados por el diseño o por la modificación del código son limitados, se reduce la propagación del error y es posible obtener módulos reutilizables. En resumen, la independencia funcional es una clave para el buen diseño y éste es la clave de la calidad del software. La independencia se evalúa con el uso de dos criterios cualitativos: la cohesión y el acopla-

PU

NT

O

CLAVE

La cohesión es un indicador cualitativo del grado en el que un módulo se centra en hacer una sola cosa.

miento. La cohesión es un indicador de la fortaleza relativa funcional de un módulo. El acoplamiento lo es de la independencia relativa entre módulos. La cohesión es una extensión natural del concepto de ocultamiento de información descrito en la sección 8.3.6. Un módulo cohesivo ejecuta una sola tarea, por lo que requiere interactuar poco con otros componentes en otras partes del programa. En pocas palabras, un módulo cohesivo debe (idealmente) hacer sólo una cosa. Aunque siempre debe tratarse de lograr mucha cohesión (por ejemplo, una sola tarea), con frecuencia es necesario y aconsejable hacer que un componente de software realice funciones múltiples. Sin embargo, para lograr un buen diseño hay que evitar los componentes “esquizofrénicos” (módulos que llevan a cabo funciones no relacionadas).

PU

El acoplamiento es una indicación de la interconexión entre módulos en una estructura de

NT

O

CLAVE

El acoplamiento es un indicador cualitativo del grado en el que un módulo está conectado con otros y con el mundo exterior.

software, y depende de la complejidad de la interfaz entre módulos, del grado en el que se entra o se hace referencia a un módulo y de qué datos pasan a través de la interfaz. En el diseño de software, debe buscarse el mínimo acoplamiento posible. La conectividad simple entre módulos da como resultado un software que es más fácil de entender y menos propenso al “efecto de oleaje” [Ste74], ocasionado cuando ocurren errores en un sitio y se propagan por todo el sistema.


14/1/10 14:31:09

194

PAR T E DOS

8.3.8 CONSEJO

Existe la tendencia a pasar de inmediato a los detalles e ignorar los pasos del refinamiento. Esto genera errores y hace que el diseño sea mucho más difícil de revisar. Realice refinamiento stepwise.

MO D E LADO

Refinamiento

El refinamiento stepwise es una estrategia de diseño propuesta originalmente por Niklaus Wirth [Wir71]. Un programa se elabora por medio del refinamiento sucesivo de los detalles del procedimiento. Se desarrolla una jerarquía con la descomposición de un enunciado macroscópico de la función (abstracción del procedimiento) en forma escalonada hasta llegar a los comandos del lenguaje de programación. En realidad, el refinamiento es un proceso de elaboración. Se comienza con un enunciado de la función (o descripción de la información), definida en un nivel de abstracción alto. Es decir, el enunciado describe la función o información de manera conceptual, pero no dice nada sobre los trabajos internos de la función o de la estructura interna de la información. Después se trabaja sobre el enunciado original, dando más y más detalles conforme tiene lugar el refinamiento (elaboración) sucesivo. La abstracción y el refinamiento son conceptos complementarios. La primera permite especificar internamente el procedimiento y los datos, pero elimina la necesidad de que los “extraños” conozcan los detalles de bajo nivel. El refinamiento ayuda a revelar estos detalles a medida que avanza el diseño. Ambos conceptos permiten crear un modelo completo del diseño conforme éste evoluciona.

8.3.9

Aspectos

Conforme tiene lugar el análisis de los requerimientos, surge un conjunto de “preocupaciones”

Cita: “Es difícil leer un libro sobre los principios de la magia sin echar una mirada de vez en cuando a la portada para asegurarse de que no es un texto sobre diseño de software.” Bruce Tognazzini

que “incluyen requerimientos, casos de uso, características, estructuras de datos, calidad del servicio, variantes, fronteras de las propiedades intelectuales, colaboraciones, patrones y contratos” [AOS07]. Idealmente, un modelo de requerimientos se organiza de manera que permita aislar cada preocupación (requerimiento) a fin de considerarla en forma independiente. Sin embargo, en la práctica, algunas de estas preocupaciones abarcan todo el sistema y no es fácil dividirlas en compartimientos. Cuando comienza el diseño, los requerimientos son refinados en una representación de diseño modular. Considere dos requerimientos, A y B. El A interfiere con el B “si se ha elegido una descomposición [refinamiento] en la que B no puede satisfacerse sin tomar en cuenta a A” [Ros04]. Por ejemplo, considere dos requerimientos para la webapp CasaSeguraAsegurada.com. El requerimiento A se describe con el caso de uso AVC-DVC analizado en el capítulo 6. Un refinamiento del diseño se centraría en aquellos módulos que permitieran que usuarios registrados

PU

NT

O

CLAVE

Una preocupación de interferencia es alguna característica del sistema que se aplica a través de muchos requerimientos distintos.

accedieran al video de cámaras situadas en un espacio. El requerimiento B es de seguridad y establece que un usuario registrado debe ser validado antes de que use CasaSeguraAsegurada. com. Este requerimiento es aplicable a todas las funciones disponibles para los usuarios registrados de CasaSegura. Cuando ocurre el refinamiento del diseño, A* es una representación del diseño para el requerimiento A, y B* es otra para el requerimiento B. Por tanto, A* y B* son representaciones de las preocupaciones, y B* interfiere con A*. Un aspecto es una representación de una preocupación de interferencia. Entonces, la representación del diseño, B*, del requerimiento un usuario registrado debe ser validado antes de que use CasaSeguraAsegurada.com es un aspecto de la webapp CasaSegura. Es importante identificar aspectos, de modo que el diseño les pueda dar acomodo conforme sucede el refinamiento y la división en módulos. En un contexto ideal, un aspecto se implementa como módulo (componente) separado y no como fragmentos de software “dispersos” o “regados” en muchos componentes [Ban06]. Para lograr esto, la arquitectura del diseño debe apoyar un mecanismo para definir aspecto: un módulo que permita implementar la preocupación en todas aquellas con las que interfiera.


14/1/10 14:31:09

C AP Í T UL O 8

8.3.10

195


Rediseño

Una actividad de diseño importante que se sugiere para muchos métodos ágiles (véase el capí-

WebRef En la dirección www.refactoring. com, se encuentran recursos excelentes para el rediseño.

tulo 3) es el rediseño, técnica de reorganización que simplifica el diseño (o código) de un componente sin cambiar su función o comportamiento. Fowler [Fow00] define el rediseño del modo siguiente: “Es el proceso de cambiar un sistema de software en forma tal que no se altera el comportamiento externo del código [diseño], pero sí se mejora su estructura interna.” Cuando se rediseña el software, se examina el diseño existente en busca de redundancias,

WebRef En http://c2.com/cgi/wiki?Re factoringPatterns, se encuentran varios patrones de rediseño.

elementos de diseño no utilizados, algoritmos ineficientes o innecesarios, estructuras de datos mal construidas o inapropiadas y cualquier otra falla del diseño que pueda corregirse para obtener un diseño mejor. Por ejemplo, una primera iteración de diseño tal vez genere un componente con poca cohesión (realiza tres funciones que tienen poca relación entre sí). Después de un análisis cuidadoso, se decide rediseñar el componente en tres componentes separados, cada uno con mucha cohesión. El resultado será un software más fácil de integrar, de probar y de mantener.

C ASA S EGURA 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. La conversación: [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 una 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.

8.3.11

Jamie: He visto tu trabajo, Shak, y aplicas de manera natural mucho de lo que se habló… ésa es la razón por la que funcionan 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 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 enseñaron 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.

Conceptos de diseño orientados a objeto

El paradigma de la orientación a objeto (OO) se utiliza mucho en la ingeniería de software moderna. El apéndice 2 está pensado para aquellos lectores que no estén familiarizados con los conceptos de diseño OO, tales como clases y objetos, herencia, mensajes y polimorfismo, entre otros.


14/1/10 14:31:10

196

PAR T E DOS

8.3.12

MO D E LADO

Clases de diseño

El modelo de requerimientos define un conjunto de clases de análisis (capítulo 6). Cada una describe algún elemento del dominio del problema y se centra en aspectos de éste que son visibles para el usuario. El nivel de abstracción de una clase de análisis es relativamente alto. Conforme el diseño evoluciona, se definirá un conjunto de clases de diseño que refinan las clases de análisis, dando detalles del diseño que permitirán que las clases se implementen y generen una infraestructura para el software que apoye la solución de negocios. Pueden desarrollarse cinco tipos diferentes de clases de diseño, cada una de las cuales representa una capa distinta de la arquitectura del diseño [Amb01]:

?

¿Qué tipos de clases crea el diseñador?

• Clases de usuario de la interfaz. Definen todas las abstracciones necesarias para la interacción humano-computadora (IHC). En muchos casos, la IHC ocurre dentro del contexto de una metáfora (por ejemplo, cuaderno de notas, formato de orden, máquina de fax, etc.) y las clases del diseño para la interfaz son representaciones visuales de los elementos de la metáfora.

• Clases del dominio de negocios. Es frecuente que sean refinamientos de las clases de análisis definidas antes. Las clases identifican los atributos y servicios (métodos) que se requieren para implementar algunos elementos del dominio de negocios.

• Clases de proceso. Implantan abstracciones de negocios de bajo nivel que se requieren para administrar por completo las clases de dominio de negocios.

• Clases persistentes. Representan almacenamientos de datos (por ejemplo, una base de datos) que persistirán más allá de la ejecución del software.

• Clases de sistemas. Implantan las funciones de administración y control del software que permiten que el sistema opere y se comunique dentro de su ambiente de computación y con el mundo exterior. A medida que se forma la arquitectura, el nivel de abstracción se reduce cuando cada clase de análisis se transforma en una representación del diseño. Es decir, las clases de análisis representan objetos de datos (y servicios asociados que se aplican a éstos) que usan la terminología del dominio del negocio. Las clases de diseño presentan muchos más detalles técnicos como guía para su implementación. Arlow y Neustadt [Arl02] sugieren que se revise cada clase de diseño para asegurar que esté “bien formada”. Definen cuatro características de las clases de diseño bien formadas:

?

¿Qué es una clase de diseño “bien formada”?

Completa y suficiente. Una clase de diseño debe ser el encapsulado total de todos los atributos y métodos que sea razonable esperar (con base en una interpretación comprensible del nombre de la clase) y que existan para la clase. Por ejemplo, la clase Escena definida para el software de la edición de video será completa sólo si contiene todos los atributos y métodos que se asocian de manera razonable con la creación de una escena de video. La suficiencia asegura que la clase de diseño contiene sólo los métodos que bastan para lograr el objetivo de la clase, ni más ni menos. Primitivismo. Los métodos asociados con una clase de diseño deben centrarse en el cumplimiento de un servicio para la clase. Una vez implementado el servicio con un método, la clase no debe proveer otro modo de hacer lo mismo. Por ejemplo, la clase VideoClip para el software de la edición de video tal vez tenga los atributos punto-inicial y punto-final que indiquen los puntos de inicio y fin del corto (observe que el video original cargado en el sistema puede ser más extenso que el corto utilizado). Los métodos EstablecerPuntoInicial ( ) y EstablecerPuntoFinal ( ) proporcionan los únicos medios para establecer los puntos de comienzo y terminación del corto. Mucha cohesión. Una clase de diseño cohesiva tiene un conjunto pequeño y centrado de responsabilidades; para implementarlas emplea atributos y métodos de objetivo único. Por


14/1/10 14:31:10

C AP Í T UL O 8

197


ejemplo, la clase VideoClip quizá contenga un conjunto de métodos para editar el corto de video. La cohesión se mantiene en tanto cada método se centre sólo en los atributos asociados con el corto. Poco acoplamiento. Dentro del modelo de diseño, es necesario que las clases de diseño colaboren una con otra. Sin embargo, la colaboración debe mantenerse en un mínimo aceptable. Si un modelo de diseño está muy acoplado (todas las clases de diseño colaboran con todas las demás), el sistema es difícil de implementar, probar y mantener con el paso del tiempo. En general, las clases de diseño dentro de un subsistema deben tener sólo un conocimiento limitado de otras clases. Esta restricción se llama Ley de Demeter [Lie03] y sugiere que un método sólo debe enviar mensajes a métodos que están en clases vecinas.6

C ASA S EGURA 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.

8. 4

EL

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.

MODELO DEL DISEÑO

El modelo del diseño puede verse en dos dimensiones distintas, como se ilustra en la figura 8.4. La dimensión del proceso indica la evolución del modelo del diseño conforme se ejecutan las tareas de éste como parte del proceso del software. La dimensión de la abstracción representa el nivel de detalle a medida que cada elemento del modelo de análisis se transforma en un equivalente de diseño y luego se mejora en forma iterativa. En relación con la figura 8.4, la línea punteada indica la frontera entre los modelos de análisis y de diseño. En ciertos casos, es posible hacer una distinción clara entre ambos modelos. En otros, el modelo de análisis se mezcla poco a poco con el de diseño y la distinción es menos obvia. Los elementos del modelo de diseño usan muchos de los diagramas UML7 que se utilizaron en el modelo del análisis. La diferencia es que estos diagramas se refinan y elaboran como parte

6

Una manera menos formal de la Ley de Demeter es: “cada unidad debe hablar sólo con sus amigas: no hablar con extraños”.

7


En el apéndice 1 se encuentra un método de enseñanza sobre los conceptos y notación básica del UML.

14/1/10 14:31:10

198

PAR T E DOS

MO D E LADO

FIGURA 8.3 PlanodelaPlanta

Clase de diseño para PlanodelaPlanta y composición del agregado para ella (véase el análisis en el recuadro)

Cámara

tipo DimensionesExteriores

1

AgregarCámara( ) AgregarPared( ) AgregarVentana( ) EliminarSegmento( ) Dibujar( ) 1

*

tipo identificación VistaGeneral ÁngulodeVisión PrepararAcercamiento

* Segmento ComenzarCoordenada TerminarCoordenada ObtenerTipo( ) Dibujar( )

SegmentodePared

PU

Ventana

del diseño; se dan más detalles específicos de la implantación y se hace énfasis en la estructura

NT

O

y en el estilo arquitectónico, en los componentes que residen dentro de la arquitectura y en las

CLAVE

El modelo de diseño tiene cuatro elementos principales: datos, arquitectura, componentes e interfaz.

FIGURA 8.4

interfaces entre los componentes y el mundo exterior. No obstante, debe observarse que los elementos del modelo indicados a lo largo del eje horizontal no siempre se desarrollan en forma secuencial. En la mayoría de los casos, el diseño preliminar de la arquitectura establece la etapa y va seguido del diseño de la interfaz y del dise-

Dimensiones del modelo de diseño Alto

Dimensión de la abstracción

Modelo del análisis Diagramas de clase Paquetes de análisis Modelos CRC Diagramas de colaboración Diagramas de flujo de datos Diagramas de flujo del control Narrativas del procesamiento

Realizaciones de la clase de diseño Subsistemas Diagramas de colaboración

Modelo del diseño

Bajo

Refinamientos a: Realizaciones de la clase de diseño Subsistemas Diagramas de colaboración Elementos de arquitectura

Casos de uso - texto Diagramas de actividades Casos de uso - diagramas Diagramas de canal Diagramas de colaboración Diagramas de estado Diagramas de secuencia

Diseño de la interfaz técnica Diseño de la navegación Diseño de la interfaz gráfica de usuario

Elementos de la interfaz

Diagramas de clase Paquetes de análisis Requerimientos: Modelos CRC Restricciones Diagramas de colaboración Diagramas de flujo de datos Interoperabilidad Narrativas del procesamiento Objetivos y Diagramas de estado configuración Diagramas de secuencia

Diagramas de componentes Clases de diseño Diagramas de actividades Diagramas de secuencia

Realizaciones de la clase de diseño Subsistemas Diagramas de colaboración Diagramas de componentes Clases de diseño Refinamientos a: Diagramas de actividades Diagramas de componentes Diagramas de secuencia Clases de diseño Diagramas de actividad Diagramas de despliegue Diagramas de secuencia Elementos en el nivel de componentes

Elementos en el nivel del despliegue

Dimensión del proceso


14/1/10 14:31:11

C AP Í T UL O 8


199

ño del nivel de los componentes, los cuales con frecuencia ocurren en paralelo. El modelo de

Cita: “Las preguntas acerca de si el diseño es necesario o digno de pagarse están más allá de la discusión: el diseño es inevitable. La alternativa al buen diseño es el mal diseño, no la falta de diseño.” Douglas Martin

despliegue por lo general se retrasa hasta que el diseño haya sido desarrollado por completo. Es posible aplicar patrones de diseño en cualquier punto de este proceso (véase el capítulo 12). Estos patrones permiten aplicar el conocimiento del diseño a problemas específicos del dominio que han sido encontrados y resueltos por otras personas.

8.4.1

Elementos del diseño de datos

Igual que otras actividades de la ingeniería de software, el diseño de datos (en ocasiones denominado arquitectura de datos) crea un modelo de datos o información que se representa en un nivel de abstracción elevado (el punto de vista del usuario de los datos). Este modelo de los datos se refina después en forma progresiva hacia representaciones más específicas de la implementación que puedan ser procesadas por el sistema basado en computadora. En muchas aplicaciones de software, la arquitectura de los datos tendrá una influencia profunda en la arquitectura del software que debe procesarlo.

PU

La estructura de los datos siempre ha sido parte importante del diseño de software. En el

NT

O

CLAVE

En el nivel de la arquitectura (aplicación), el diseño de los datos se centra en archivos o bases de datos; en el de los componentes, el diseño de datos considera las estructuras de datos que se requieren para implementar objetos de datos locales.

nivel de componentes del programa, del diseño de las estructuras de datos y de los algoritmos requeridos para manipularlos, es esencial la creación de aplicaciones de alta calidad. En el nivel de la aplicación, la traducción de un modelo de datos (obtenido como parte de la ingeniería de los requerimientos) a una base de datos es crucial para lograr los objetivos de negocios de un sistema. En el nivel de negocios, el conjunto de información almacenada en bases de datos incompatibles y reorganizados en un “data warehouse” permite la minería de datos o descubrimiento de conocimiento que tiene un efecto en el éxito del negocio en sí. En cada caso, el diseño de los datos juega un papel importante. El diseño de datos se estudia con más detalle en el capítulo 9.

8.4.2

Elementos del diseño arquitectónico

El diseño de la arquitectura del software es el equivalente del plano de una casa. Éste ilustra la

Cita: “Puede usarse una goma en la mesa de dibujo o un marro en el sitio construido.” Frank Lloyd Wright

distribución general de las habitaciones, su tamaño, forma y relaciones entre ellas, así como las puertas y ventanas que permiten el movimiento entre los cuartos. El plano da una visión general de la casa. Los elementos del diseño de la arquitectura dan la visión general del software. El modelo arquitectónico [Sha96] proviene de tres fuentes: 1) información sobre el dominio de la aplicación del software que se va a elaborar, 2) los elementos específicos del modelo de requerimientos, tales como diagramas de flujo de datos o clases de análisis, sus relaciones y colaboraciones para el problema en cuestión y 3) la disponibilidad de estilos arquitectónicos (capítulo 9) y sus patrones (capítulo 12). Por lo general, el elemento de diseño arquitectónico se ilustra como un conjunto de sistemas interconectados, con frecuencia obtenidos de paquetes de análisis dentro del modelo de requerimientos. Cada subsistema puede tener su propia arquitectura (por ejemplo, la interfaz gráfica de usuario puede estar estructurada de acuerdo con un estilo de arquitectura preexistente para

Cita: “El público está más familiarizado con el mal diseño que con el buen diseño. En realidad, está condicionado para que prefiera el mal diseño porque es con el que vive. Lo nuevo le parece amenazador; lo viejo le da seguridad.” Paul Rand


interfaces de usuario). En el capítulo 9 se presentan técnicas para obtener elementos específicos del modelo arquitectónico.

8.4.3

Elementos de diseño de la interfaz

El diseño de la interfaz para el software es análogo al conjunto de trazos (y especificaciones) detalladas para las puertas, ventanas e instalaciones de una casa. Tales dibujos ilustran el tamaño y forma de puertas y ventanas, la manera en la que operan, la forma en la que llegan las instalaciones de servicios (agua, electricidad, gas, teléfono, etc.) a la vivienda y se distribuyen entre las habitaciones indicadas en el plano. Indican dónde está el timbre de la puerta, si se usará un intercomunicador para anunciar la presencia de un visitante y cómo se va a instalar el

14/1/10 14:31:11

200

PAR T E DOS

MO D E LADO

sistema de seguridad. En esencia, los planos (y especificaciones) detallados para las puertas, ventanas e instalaciones externas nos dicen cómo fluyen las cosas y la información hacia dentro y fuera de la casa y dentro de los cuartos que forman parte del plano. Los elementos de diseño de la interfaz del software permiten que la información fluya hacia dentro y afuera del sistema, y cómo están comunicados los componentes que son parte de la arquitectura. PU

Hay tres elementos importantes del diseño de la interfaz: 1) la interfaz de usuario (IU), 2)

NT

O

CLAVE

Hay tres partes para el elemento de diseño de la interfaz: la interfaz de usuario, las interfaces dirigidas hacia el sistema externo a la aplicación y las interfaces orientadas hacia los componentes dentro de ésta.

las interfaces externas que tienen que ver con otros sistemas, dispositivos, redes y otros productores o consumidores de información y 3) interfaces internas que involucran a los distintos componentes del diseño. Estos elementos del diseño de la interfaz permiten que el software se comunique externamente y permita la comunicación y colaboración internas entre los componentes que constituyen la arquitectura del software. El diseño de la IU (denominada cada vez con más frecuencia diseño de la usabilidad) es una acción principal de la ingeniería de software y se estudia con detalle en el capítulo 11. El diseño de la usabilidad incorpora elementos estéticos (como distribución, color, gráficos, mecanismos de interacción, etc.), elementos ergonómicos (por ejemplo, distribución y colocación de la información, metáforas, navegación por la IU, etc.) y elementos técnicos (como patrones de la IU y patrones reutilizables). En general, la IU es un subsistema único dentro de la arquitectura general de la aplicación. El diseño de interfaces externas requiere información definitiva sobre la entidad a la que se

Cita: “De vez en cuando apártate, relájate un poco, para que cuando regreses al trabajo tu criterio sea más seguro. Toma algo de distancia porque entonces el trabajo parece más pequeño y es posible apreciar una porción mayor con una sola mirada, de modo que se detecta con facilidad la falta de armonía y proporción.” Leonardo da Vinci

envía información o desde la que se recibe. En todo caso, esta información debe recabarse durante la ingeniería de requerimientos (capítulo 5) y verificarse una vez que comienza el diseño de la interfaz.8 El diseño de interfaces externas debe incorporar la revisión en busca de errores y (cuando sea necesario) las medidas de seguridad apropiadas. El diseño de las interfaces internas se relaciona de cerca con el diseño de componentes (véase el capítulo 10). Las realizaciones del diseño de las clases de análisis representan todas las operaciones y esquemas de mensajería que se requieren para permitir la comunicación y colaboración entre las operaciones en distintas clases. Cada mensaje debe diseñarse para que contenga la información que se requiere transmitir y los requerimientos específicos de la función de la operación que se ha solicitado. Si para el diseño se elige el enfoque clásico de un proceso de entrada-salida, la interfaz de cada componente del software se diseña con base en las representaciones del flujo de datos y en la funcionalidad descrita en una narrativa de procesamiento. En ciertos casos, una interfaz se modela en forma muy parecida a la de una clase. En el UML

WebRef En la dirección www.useit.com, se encuentra información sumamente valiosa sobre el diseño de la IU.

se define interfaz del modo siguiente [OMG03a]: “Es un especificador para las operaciones visibles desde el exterior [públicas] de una clase, un componente u otro clasificador (incluso subsistemas), sin especificar su estructura interna.” En pocas palabras, una interfaz es un conjunto de operaciones que describen alguna parte del comportamiento de una clase y dan acceso a aquéllas. Por ejemplo, la función de seguridad de CasaSegura hace uso del panel de control que permite

Cita: “Un error común que comete la gente cuando trata de diseñar algo a prueba de tontos es subestimar la ingenuidad de los completamente tontos.” Douglas Adams

que el propietario controle ciertos aspectos de la función de seguridad. En una versión avanzada del sistema, las funciones del panel de control podrían implementarse a través de un PDA inalámbrico o un teléfono móvil. La clase PaneldeControl (véase la figura 8.5) proporciona el comportamiento asociado con un teclado, por lo que debe implementar las operaciones LeerTeclazo ( ) y DecodificarTecla ( ). Si estas operaciones se van a dar a otras clases (en este caso, PDAInalámbrico y TeléfonoMóvil), es útil definir una interfaz como la de la figura. La interfaz, llamada Teclado, se ilustra como un estereotipo <> o como un círculo pequeño con leyenda y conectado a la clase

8

Las características de la interfaz pueden cambiar con el tiempo. Por tanto, un diseñador debe cerciorarse de que la especificación para ella sea exacta y completa.


14/1/10 14:31:11

C AP Í T UL O 8

201


FIGURA 8.5 TeléfonoMóvil

Representación de la interfaz para PaneldeControl

PDAInalámbrico

PaneldeControl PantalladeCristalLíquido IndicadoresLuminosos CaracterísticasdeTeclado Bocina InterfazInalámbrica LeerTeclazo( ) DecodificarTecla( ) DesplegarEstado( ) EncenderIndicadoresLuminosos( ) EnviarMensajedeControl( )

Teclado

Teclado <> LeerTeclazo( ) DecodificarTecla( )

con una línea. La interfaz se define sin atributos y con el conjunto de operaciones que sean necesarias para lograr el comportamiento de un teclado. La línea punteada con un triángulo abierto en su extremo (en la figura 8.5) indica que la clase PaneldeControl proporciona las operaciones de Teclado como parte de su comportamiento. En UML, esto se caracteriza como una realización. Es decir, parte del comportamiento de PaneldeControl se implementará con la realización de las operaciones de Teclado. Éstas se darán a otras clases que accedan a la interfaz.

8.4.4

Elementos del diseño en el nivel de los componentes

El diseño en el nivel de los componentes del software es el equivalente de los planos (y especificaciones) detallados de cada habitación de la casa. Estos dibujos ilustran el cableado y la plomería de cada cuarto, la ubicación de cajas eléctricas e interruptores, grifos, coladeras, regaderas, tinas, drenajes, gabinetes y closets. También describen el tipo de piso que se va a usar, las molduras que se van a aplicar y todos los detalles asociados con una habitación. El diseño de componentes para el software describe por completo los detalles internos de cada componente. Para lograrlo, este diseño define estructuras de datos para todos los objetos de datos locales y detalles algorítmicos para todo el procesamiento que tiene lugar dentro de un componente, así como la interfaz que permite el acceso a todas las operaciones de los componentes

Cita: “Los detalles no son los detalles. Constituyen el diseño.” Charles Eames

(comportamientos). En el contexto de la ingeniería de software orientada a objeto, un componente se representa en forma de diagrama UML, como se ilustra en la figura 8.6. En ésta, aparece un componente llamado AdministracióndeSensor (parte de la función de seguridad de CasaSegura). Una flecha punteada conecta al componente con una clase llamada Sensor, a él asignada. El compo-

FIGURA 8.6 Diagrama de componente UML


AdministracióndeSensor

Sensor

14/1/10 14:31:12

202

PAR T E DOS

MO D E LADO

nente AdministracióndeSensor lleva a cabo funciones asociadas con los sensores de CasaSegura, incluso su vigilancia y configuración. En el capítulo 10 se analizan más los diagramas de componentes. Los detalles del diseño de un componente se modelan en muchos niveles de abstracción diferentes. Se utiliza un diagrama de actividades UML para representar la lógica del procesamiento. El flujo detallado del procedimiento para un componente se representa con seudocódigo (representación que se parece a un lenguaje de programación y que se describe en el capítulo 10) o con alguna otra forma diagramática (como un diagrama de flujo o de cajas). La estructura algorítmica sigue las reglas establecidas para la programación estructurada (por ejemplo, un conjunto de construcciones restringidas de procedimiento). Las estructuras de datos, seleccionadas con base en la naturaleza de los objetos de datos que se van a procesar, por lo general se modelan con el empleo de seudocódigo del lenguaje de programación que se usará para la implementación.

8.4.5

Elementos del diseño del despliegue

Los elementos del diseño del despliegue indican la forma en la que se acomodarán la funcionalidad del software y los subsistemas dentro del ambiente físico de la computación que lo apoyará. Por ejemplo, los elementos del producto CasaSegura se configuran para que operen dentro de tres ambientes de computación principales: una PC en la casa, el panel de control de CasaSe-

PU

NT

O

CLAVE

Los diagramas de despliegue comienzan en forma de descriptor, donde el ambiente de despliegue se describe en términos generales. Después se utilizan formas de instancia y se describen explícitamente los elementos de la configuración.

gura y un servidor alojado en CPI Corp. (que provee el acceso al sistema a través de internet). Durante el diseño se desarrolla un diagrama de despliegue que después se refina, como se ilustra en la figura 8.7. En ella aparecen tres ambientes de computación (en realidad habría más, con sensores y cámaras, entre otros). Se indican los subsistemas (funcionalidad) que están alojados dentro de cada elemento de computación. Por ejemplo, la computadora personal aloja subsistemas que implementan características de seguridad, vigilancia, administración del hogar y comunicaciones. Además, se ha diseñado un subsistema de acceso externo para manejar todos los intentos de acceder al sistema CasaSegura desde un lugar externo. Cada subsistema se elaboraría para que indicara los componentes que implementa.

FIGURA 8.7 Diagrama de despliegue UML

Panel de control

Servidor en CPI

Seguridad

AccesodelPropietario

Computadora personal AccesoExterno


Seguridad

Vigilancia

Administración delHogar

Comunicación

14/1/10 14:31:12

C AP Í T UL O 8


203

El diagrama que aparece en la figura 8.7 es un formato descriptor. Esto significa que el diagrama de despliegue muestra el ambiente de computación, pero no indica de manera explícita los detalles de la configuración. Por ejemplo, no se da mayor identificación de la “computadora personal”. Puede ser una Mac o basarse en Windows, una estación de trabajo Sun o un sistema Linux. Estos detalles se dan cuando se regrese al diagrama de despliegue en el formato de instancia en las etapas finales del diseño, o cuando comience la construcción. Se identifica cada instancia del despliegue (una configuración específica, llamada configuración del hardware).

8. 5

RESUMEN El diseño del software comienza cuando termina la primera iteración de la ingeniería de requerimientos. El objetivo del diseño del software es aplicar un conjunto de principios, conceptos y prácticas que llevan al desarrollo de un sistema o producto de alta calidad. La meta del diseño es crear un modelo de software que implantará correctamente todos los requerimientos del usuario y causará placer a quienes lo utilicen. Los diseñadores del software deben elegir entre muchas alternativas de diseño y llegar a la solución que mejor se adapte a las necesidades de los participantes en el proyecto. El proceso de diseño va de una visión “panorámica” del software a otra más cercana que define el detalle requerido para implementar un sistema. El proceso comienza por centrarse en la arquitectura. Se definen los subsistemas, se establecen los mecanismos de comunicación entre éstos, se identifican los componentes y se desarrolla la descripción detallada de cada uno. Además, se diseñan las interfaces externa, interna y de usuario. Los conceptos de diseño han evolucionado en los primeros 60 años de trabajo de la ingeniería de software. Describen atributos de software de computadora que debe presentarse sin importar el proceso que se elija para hacer la ingeniería, los métodos de diseño que se apliquen o los lenguajes de programación que se utilicen. En esencia, los conceptos de diseño ponen el énfasis en la necesidad de la abstracción como mecanismo para crear componentes reutilizables de software, en la importancia de la arquitectura como forma de entender mejor la estructura general de un sistema, en los beneficios de la ingeniería basada en patrones como técnica de diseño de software con capacidad comprobada, en el valor de la separación de problemas y de la modularidad eficaz como forma de elaborar software más entendible, más fácil de probar y de recibir mantenimiento, en las consecuencias de ocultar información como mecanismo para reducir la propagación de los efectos colaterales cuando hay errores, en el efecto de la independencia funcional como criterio para construir módulos eficaces, en el uso del refinamiento como mecanismo de diseño, en una consideración de los aspectos que interfieren con los requerimientos del sistema, en la aplicación del rediseño para optimizar el diseño obtenido y en la importancia de las clases orientadas a objetos y de las características relacionadas con ellos. El modelo del diseño incluye cuatro elementos distintos. Conforme se desarrolla cada uno, surge una visión más completa del diseño. El elemento arquitectónico emplea información obtenida del dominio de la aplicación, del modelo de requerimientos y de los catálogos disponibles de patrones y estilos para obtener una representación estructural completa del software, de sus subsistemas y componentes. Los elementos del diseño de la interfaz modelan las interfaces internas y externas y la de usuario. Los elementos en el nivel de componentes definen cada uno de los módulos (componentes) que constituyen la arquitectura. Por último, los elementos del diseño albergan la arquitectura, sus componentes y las interfaces dirigidas hacia la configuración física en la que se alojará el software.

PROBLEMAS


8.1. Cuando se “escribe” un programa, ¿se diseña software? ¿En qué difieren el diseño de software y la codificación?


14/1/10 14:31:12

204

PAR T E DOS

MO D E LADO

8.2. Si el diseño del software no es un programa (y no lo es), entonces, ¿qué es? 8.3. ¿Cómo se evalúa la calidad del diseño del software? 8.4. Estudie el conjunto de tareas presentado para el diseño. ¿Dónde se evalúa la calidad en dicho conjunto? ¿Cómo se logra? ¿Cómo se consiguen los atributos de calidad estudiados en la sección 8.2.1? 8.5. Dé ejemplos de tres abstracciones de datos y de las abstracciones de procedimiento que se usan para manipularlas. 8.6. Describa con sus propias palabras la arquitectura de software. 8.7. Sugiera un patrón de diseño que encuentre en una categoría de objetos cotidianos (por ejemplo, electrónica de consumo, automóviles, aparatos, etc.). Describa el patrón en forma breve. 8.8. Describa con sus propias palabras la separación de problemas. ¿Hay algún caso en el que no sea apropiada la estrategia de divide y vencerás? ¿Cómo afecta esto al argumento a favor de la modularidad? 8.9. ¿Cuándo debe implementarse un diseño modular como software monolítico? ¿Cómo se logra esto? ¿El rendimiento es la única justificación para la implementación de software monolítico? 8.10. Analice la relación entre el concepto de ocultamiento de información como atributo de la modularidad efectiva y el de independencia de los módulos. 8.11. ¿Cómo se relacionan los conceptos de acoplamiento y portabilidad del software? Dé ejemplos que apoyen su punto de vista. 8.12. Aplique un “enfoque de refinamiento stepwise” para desarrollar tres niveles distintos de abstracciones del procedimiento para uno o más de los programas siguientes: a) un revisor de la escritura que, dada una cantidad numérica de dinero, imprima ésta en las palabras que se requieren normalmente en un cheque. b) una resolución en forma iterativa de las raíces de una ecuación trascendente. c) un algoritmo de programación de tareas simples para un sistema operativo. 8.13. Considere el software requerido para implementar la capacidad de navegación (con un GPS) en un dispositivo móvil de comunicación portátil. Describa dos o tres preocupaciones de interferencia que se presentarían. Analice la manera en la que se representaría como aspecto una de estas preocupaciones. 8.14. ¿”Rediseñar” significa que se modifica todo el diseño en forma iterativa? Si no es así, ¿qué significa? 8.15. Describa en breves palabras cada uno de los cuatro elementos del modelo del diseño.

LECTURAS


Donald Norman ha escrito dos libros (The Design of Everyday Things, Doubleday, 1990, y The Psychology of Everyday Things, Harpercollins, 1988) que se han convertido en clásicos de la bibliografía sobre el diseño y una “obligación” de lectura para quien diseñe cualquier cosa que utilicen los humanos. Adams (Conceptual Blockbusting, 3a. ed., Addison-Wesley, 1986) escribió un libro cuya lectura es esencial para los diseñadores que deseen ampliar su forma de pensar. Por último, el texto clásico de Polya (How to Solve It, 2a. ed., Princeton University Press, 1988) proporciona un proceso general de solución de problemas que ayuda a los diseñadores de software cuando se enfrentan a problemas complejos. En la misma tradición, Winograd et al. (Bringing Design to Software, Addison-Wesley, 1996) analizan los diseños de software que funcionan, los que no y su por qué. Un libro fascinante editado por Wixon y Ramsey (Field Methods Casebook for Software Design, Wiley, 1996) sugiere métodos de investigación de campo (muy parecidos a los de los antropólogos) para entender cómo hacen el trabajo los usuarios finales y luego diseñar el software que satisfaga sus necesidades. Beyer y Holtzblatt (Contextual Design: A Customer-Centered Approach to Systems Designs, Academic Press, 1997) ofrecen otro punto de vista del diseño de software que integra al consumidor o usuario en cada aspecto del proceso de diseño. Bain (Emergent Design, Addison-Wesley, 2008) acopla los patrones, el rediseño y el desarrollo orientado a pruebas en un enfoque de diseño eficaz. Un tratamiento exhaustivo del diseño en el contexto de la ingeniería de software es presentado por Fox (Introduction to Software Engineering Design, Addison-Wesley, 2006) y Zhu (Software Design Methodology, Butterworth-Heinemann, 2005). McConnell (Code Complete, 2a. ed., Microsoft Press, 2004) plantea un estudio excelente de los aspectos prácticos del diseño de software de alta calidad. Robertson (Simple Program Design, 3a. ed., Boyd y Fraser Publishing, 1999) presenta un análisis introductorio del diseño de software, útil para quienes se inician en el estudio del tema. Budgen (Software Design, 2a. ed., Addison-Wesley, 2004) presenta


14/1/10 14:31:12

C AP Í T UL O 8


205

varios métodos populares de diseño y los compara entre sí. Fowler y sus colegas (Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999) estudian técnicas para la optimización incremental de diseños de software. Rosenberg y Stevens (Use Case Driven Object Modeling with UML, Apress, 2007) estudian el desarrollo de diseños orientados a objeto con el empleo de casos de uso como fundamento. En una antología editada por Freeman y Wasserman (Software Design Techniques, 4a. ed., IEEE, 1983), hay una excelente revisión histórica del diseño de software. Esta edición contiene muchas reimpresiones de los artículos clásicos que forman la base de las tendencias actuales del diseño del software. Card y Glass (Measuring Software Design Quality, Prentice-Hall, 1990) presentan mediciones de la calidad procedentes de los campos de la técnica y la administración. En internet hay una variedad amplia de fuentes de información acerca del diseño de software. En el sitio web del libro: www.mhhe.com/engcs/compsci/pressman/professional/olc/ser.htm, se encuentra una lista actualizada de referencias existentes en la red mundial que son relevantes para el diseño de software y para la ingeniería de diseño.


14/1/10 14:31:12

CAPÍTULO

9 CONCEPTOS

DISEÑO

DE LA

ARQUITECTURA

CLAVE

arquetipos . . . . . . . . . . . . . 218 arquitectura . . . . . . . . . . . . 207 alternativas . . . . . . . . . . . 221 centrada en datos . . . . . . . 213 complejidad. . . . . . . . . . . . 224 componentes. . . . . . . . . . . 219 diseño . . . . . . . . . . . . . . . 217 en capas . . . . . . . . . . . . . . 214 estilos . . . . . . . . . . . . . . . 211 flujo de datos . . . . . . . . . . 213 formato . . . . . . . . . . . . . . 210 géneros . . . . . . . . . . . . . . 209 orientada a objeto. . . . . . . 214 patrones. . . . . . . . . . . . . . 215 refinamiento . . . . . . . . . . . 219 ATAM . . . . . . . . . . . . . . . . . 222 instancias . . . . . . . . . . . . . . 220 lenguaje de descripción arquitectónica . . . . . . . . . . . 224 mapeo . . . . . . . . . . . . . . . . 225

e ha descrito al diseño como un proceso de etapas múltiples en el que, a partir de los re-

S

querimientos de información, se sintetizan las representaciones de los datos y la estructura del programa, las características de la interfaz y los detalles del procedimiento. Esta

descripción la amplía Freeman [Fre80], como sigue: El diseño es una actividad que tiene que ver con la toma de decisiones importantes, con frecuencia de naturaleza estructural. Comparte con la programación el objetivo de abstraer una representación de la información y de las secuencias de procesamiento, pero en los extremos el grado de detalle es muy distinto. El diseño elabora representaciones coherentes y bien planeadas de programas, que se concentran en las relaciones de las partes en el nivel más alto y en las operaciones lógicas involucradas en los niveles bajos.

Como se señaló en el capítulo 8, el diseño está motivado por la información. Los métodos de diseño del software provienen de los tres dominios del modelo de análisis. Los dominios de datos, funciones y comportamiento sirven como guía para la creación del diseño del software. En este capítulo se presentan los métodos requeridos para crear “representaciones coherentes y bien planeadas” de las capas de datos y de la arquitectura del modelo de diseño. El objetivo es brindar un enfoque sistemático para la obtención del diseño arquitectónico, el plano preliminar a partir del cual se elabora el software.

rediseño . . . . . . . . . . . . . . . 228

UNA ¿Qué es? El diseño arquitectónico representa la estructura de los datos y de los componentes RÁPIDA del programa que se requieren para construir un sistema basado en computadora. Considera el estilo de arquitectura que adoptará el sistema, la estructura y las propiedades de los componentes que lo constituyen y las interrelaciones que ocurren entre sus componentes arquitectónicos. ¿Quién lo hace? Aunque es un ingeniero de software quien puede diseñar tanto los datos como la arquitectura, es frecuente que si deben construirse sistemas grandes y complejos, el trabajo lo realicen especialistas. El diseñador de una base de datos o data warehouse crea la arquitectura de los datos para un sistema. El “arquitecto del sistema” selecciona un estilo arquitectónico apropiado a partir de los requerimientos obtenidos durante el análisis de los datos. ¿Por qué es importante? El lector no intentaría construir una casa sin un plano, ¿o sí? Tampoco comenzaría los planos con el dibujo de la plomería del lugar. Antes de preocuparse por los detalles, necesitaría tener el panora-

MIRADA

ma general: la casa en sí. Eso es lo que hace el diseño arquitectónico, da el panorama y asegura que sea el correcto. ¿Cuáles son los pasos? El diseño de la arquitectura comienza con el diseño de los datos y continúa con la obtención de una o más representaciones de la estructura arquitectónica del sistema. Se analizan alternativas de estilos o patrones arquitectónicos para llegar a la estructura más adecuada para los requerimientos del usuario y para los atributos de calidad. Una vez seleccionada la alternativa, se elabora la arquitectura con el empleo de un método de diseño. ¿Cuál es el producto final? Durante el diseño arquitectónico se crea un modelo de arquitectura que incluye la arquitectura de los datos y la estructura del programa. Además, se describen las propiedades y relaciones (interacciones) que hay entre los componentes. ¿Cómo me aseguro de que lo hice bien? En cada etapa se revisan los productos del trabajo del diseño del software para que sean claros, correctos, completos y consistentes con los requerimientos y entre sí.

206


14/1/10 15:44:35

C AP Í T UL O 9

9. 1

DISEÑO DE LA ARQ U IT ECT U RA

ARQUITECTURA

207

DEL SOFTWARE

En un libro clave sobre el tema, Shaw y Garlan [Sha96] plantean lo siguiente sobre la arquitectura del software: Desde el primer programa que se dividió en módulos, los sistemas de software han tenido arquitecturas y los programadores han sido los responsables de las interacciones entre los módulos y las propiedades globales del ensamble. Históricamente, las arquitecturas han estado implícitas: accidentes de implementación o sistemas heredados del pasado. Los desarrolladores de buen software han adoptado con frecuencia uno o varios patrones de arquitectura como estrategias para la organización del sistema, pero los utilizan de manera informal y no tienen manera de hacerlos explícitos en el sistema resultante.

En el presente, la arquitectura de software eficaz y su representación y diseño explícitos se han vuelto los temas dominantes en la ingeniería de software.

9.1.1

¿Qué es la arquitectura?

Cuando se piensa en la arquitectura de una construcción, llegan a la mente muchos atributos

Cita: “La arquitectura de un sistema es un marco general que describe su forma y estructura: sus componentes y la manera en la que ajustan entre sí”. Jerrold Grochow

distintos. En el nivel más sencillo, se considera la forma general de la estructura física. Pero, en realidad, la arquitectura es mucho más que eso. Es la manera en la que los distintos componentes del edificio se integran para formar un todo cohesivo. Es la forma en la que la construcción se adapta a su ambiente y se integra a los demás edificios en la vecindad. Es el grado en el que el edificio cumple con su propósito y en el que satisface las necesidades del propietario. Es la sensación estética de la estructura —el efecto visual de la edificación— y el modo en el que se combinan texturas, colores y materiales para crear la fachada en el exterior y el “ambiente de vida” en el interior. Es los pequeños detalles: diseño de las lámparas, tipo de piso, color de las cortinas… la lista es casi interminable. Y, finalmente, es arte.

PU

Pero la arquitectura también es algo más. Son los “miles de decisiones, tanto grandes como

NT

O

CLAVE

La arquitectura del software debe modelar la estructura de un sistema y la manera en la que los datos y componentes del procedimiento colaboran entre sí.

pequeñas” [Tyt05]. Algunas de éstas se toman en una etapa temprana del diseño y tienen un efecto profundo en todas las demás acciones. Otras se dejan para más adelante, con lo que se eliminan las restricciones prematuras que llevarían a una mala implementación del estilo arquitectónico. Pero, ¿qué es la arquitectura del software? Bass, Clements y Kazman [Bas03] definen este término tan elusivo de la manera siguiente: La arquitectura del software de un programa o sistema de cómputo es la estructura o estructuras del sistema, lo que comprende a los componentes del software, sus propiedades externas visibles y las relaciones entre ellos.

La arquitectura no es el software operativo. Es una representación que permite 1) analizar la efectividad del diseño para cumplir los requerimientos establecidos, 2) considerar alternativas arquitectónicas en una etapa en la que hacer cambios al diseño todavía es relativamente fácil y 3) reducir los riesgos asociados con la construcción del software. Esta definición pone el énfasis en el papel de los “componentes del software” en cualquier

Cita: “Cásate con tu arquitectura de prisa, arrepiéntete en tu tiempo libre.” Barry Boehm

representación arquitectónica. En el contexto del diseño de la arquitectura, un componente del software puede ser algo tan simple como un módulo de programa o una clase orientada a objeto, pero también puede ampliarse para que incluya bases de datos y “middleware” que permitan la configuración de una red de clientes y servidores. Las propiedades de los componentes son aquellas características necesarias para entender cómo interactúan unos componentes con otros. En el nivel arquitectónico, no se especifican las propiedades internas (por ejemplo, detalles de un algoritmo). Las relaciones entre los componentes pueden ser tan simples como una invocación de procedimiento de un módulo a otro o tan complejos como un protocolo de acceso a una base de datos.


14/1/10 15:44:36

208

PAR T E DOS

MO D E LADO

Ciertos miembros de la comunidad de la ingeniería de software [Kaz03] hacen una diferencia entre las acciones asociadas con la obtención de una arquitectura de software (lo que el autor llama “diseño de la arquitectura”) y las que se aplican para obtener el diseño del software. Como dijo un revisor de esta edición: Hay una diferencia entre los términos arquitectura y diseño. Un diseño es una instancia de una arquitectura, similar a un objeto que es una instancia de una clase. Por ejemplo, considere la arquitectura de cliente-servidor. Con esta arquitectura es posible diseñar de muchos modos un sistema de software basado en red, con el uso de una plataforma Java (Java EE) o Microsoft (estructura .NET). Entonces, hay una arquitectura, pero con base en ella pueden crearse muchos diseños. Así, no es válido mezclar “arquitectura” y “diseño”.

WebRef En la dirección www2.umassd. edu/SECenter/SAResources. html, se encuentran apuntadores útiles para muchos sitios de arquitectura de software.

Aunque el autor está de acuerdo con que un diseño de software es una instancia de una arquitectura específica de software, los elementos y estructuras que se definen como parte de ésta son el origen de todo diseño que evolucione a partir de ellos. El diseño comienza con la consideración de la arquitectura. En este libro, el diseño de la arquitectura de software considera dos niveles de la pirámide del diseño (véase la figura 8.1): el diseño de los datos y el de la arquitectura. En el contexto del análisis precedente, el diseño de los datos permite representar el componente de datos de la arquitectura con definiciones de sistemas y clase convencionales (que incluyen atributos y operaciones) en sistemas orientados a objeto. El diseño arquitectónico se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones.

9.1.2

¿Por qué es importante la arquitectura?

En un libro dedicado a la arquitectura del software, Bass et al. [Bas03] identifican tres razones

Cita: “La arquitectura es demasiado importante para dejarla en manos de una sola persona, no importa cuán brillante sea.” Scott Ambler

clave por las que es importante la arquitectura del software:

• Las representaciones de la arquitectura del software permiten la comunicación entre todas las partes (participantes) interesadas en el desarrollo de un sistema basado en computadora.

• La arquitectura resalta las primeras decisiones que tendrán un efecto profundo en todo el trabajo de ingeniería de software siguiente y, también importante, en el éxito último del sistema como entidad operacional.

• La arquitectura “constituye un modelo relativamente pequeño y asequible por la vía intelectual sobre cómo está estructurado el sistema y la forma en la que sus componentes trabajan juntos” [Bas03]. PU

El modelo del diseño de la arquitectura y los patrones arquitectónicos contenidos dentro de éste

NT

O

CLAVE

El modelo arquitectónico da un punto de vista de la Gestalt del sistema, lo que permite que el ingeniero de software lo examine como un todo.

son transferibles. Es decir, los géneros, estilos y patrones arquitectónicos pueden aplicarse al diseño de otros sistemas y representan un conjunto de abstracciones que permite a los ingenieros de software describir la arquitectura en formas predecibles.

9.1.3

Descripciones arquitectónicas

Cada uno de nosotros tiene una imagen mental de lo que significa la palabra arquitectura. Sin embargo, la realidad es que tiene significados diferentes para distintas personas. La conclusión es que los diversos participantes verán una arquitectura desde puntos de vista diferentes motivados por varios conjuntos de preocupaciones. Esto implica que una descripción arquitectónica en realidad es un conjunto de productos del trabajo que reflejan puntos de vista distintos del sistema. Por ejemplo, el arquitecto de un gran edificio de oficinas debe trabajar con distintos participantes. La preocupación principal del propietario de la edificación (un participante) es garantizar el placer estético y que brinde suficiente espacio de oficinas e infraestructura para garantizar su rentabilidad. Por tanto, el arquitecto debe desarrollar una descripción con el empleo de pers-


14/1/10 15:44:36

C AP Í T UL O 9


209

pectivas del edificio que se apeguen a las preocupaciones del dueño. Los puntos de vista empleados son dibujos del edificio en tres dimensiones (para ilustrar el aspecto estético) y un conjunto de planos en dos dimensiones que expliquen la preocupación por el espacio de oficinas y la infraestructura. Pero el espacio de oficinas tiene muchos otros participantes, incluido el fabricante de acero CONSEJO

estructural que proveerá dicho material para la estructura del edificio. Necesita información

El esfuerzo debe centrarse en representaciones de la arquitectura que guiarán todos los demás aspectos del diseño. Hay que dedicar tiempo a revisar con cuidado la arquitectura. Un error aquí tendrá un efecto negativo a largo plazo.

arquitectónica detallada sobre el acero que soportará al edificio, incluso de las vigas tipo I, sus dimensiones, conectividad, materiales y muchos otros detalles. A estas preocupaciones se abocan diferentes productos del trabajo que representan distintos puntos de vista de la arquitectura. Los planos especializados (otro punto de vista) de la estructura de acero de la edificación se centran sólo en una de las muchas preocupaciones del fabricante. La descripción de la arquitectura de un sistema basado en software debe tener características análogas a las mencionadas para el edificio de oficinas. Tyree y Ackerman [Tyr05] recalcan esto así: “Los desarrolladores desean lineamientos claros y decisivos sobre la forma de proceder con el diseño. Los consumidores desean la comprensión clara de los cambios ambientales que deben ocurrir y las garantías de que la arquitectura satisfará las necesidades de negocios. Otros arquitectos desean una comprensión clara y notable de los aspectos clave de la arquitectura.” Cada uno de estos “deseos” se refleja en un punto de vista diferente representado con el uso de una perspectiva distinta. IEEE Computer Society hizo la propuesta IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, [IEE00], con los siguientes objetivos: 1) establecer un marco conceptual con un vocabulario que se use durante el diseño de la arquitectura del software, 2) proporcionar lineamientos detallados para representar una descripción arquitectónica y 3) estimular las mejores prácticas del diseño arquitectónico. El estándar IEEE define una descripción arquitectónica (DA) como “un conjunto de productos para documentar una arquitectura”. La descripción en sí se representa con el uso de perspectivas múltiples, donde cada perspectiva es “una representación del sistema completo desde el punto de vista de un conjunto de preocupaciones relacionadas [de un participante]”. Una perspectiva se crea de acuerdo con reglas y convenciones definidas en un punto de vista: “especificación de las convenciones para construir y usar una perspectiva” [IEE00]. En este capítulo se estudian varios productos del trabajo que se utilizan para desarrollar distintas perspectivas de la arquitectura del software.

9.1.4

Decisiones arquitectónicas

Cada perspectiva desarrollada como parte de una descripción arquitectónica se aboca a una preocupación de un participante específico. Para desarrollar cada perspectiva (y la descripción arquitectónica en su conjunto), el arquitecto del sistema considera varias alternativas y decide en última instancia las características arquitectónicas específicas que satisfagan del mejor modo la preocupación. Entonces, las decisiones arquitectónicas en sí mismas se consideran una perspectiva de la arquitectura. Las razones por las que se tomaron las decisiones dan una visión de un sistema y su concordancia con las preocupaciones del participante. Como arquitecto simbólico, el lector puede usar el formato sugerido en el recuadro para documentar cada decisión importante. Al hacerlo, presenta la racionalidad de su trabajo y deja un registro histórico que será útil cuando deban hacerse modificaciones del diseño.

9. 2

GÉNEROS

ARQUITECTÓNICOS

Aunque los principios subyacentes del diseño arquitectónico se aplican a todos los tipos de la arquitectura, con frecuencia será el género arquitectónico el que dicte el enfoque específico para la estructura que deba construirse. En el contexto del diseño arquitectónico, el género implica


14/1/10 15:44:36

210

PAR T E DOS

MO D E LADO

I NFOR MACIÓN Formato para la descripción de una decisión arquitectónica Toda decisión arquitectónica de importancia puede documentarse para que posteriormente la revisen los participantes que deseen entender la descripción de la arquitectura propuesta. El formato que se presenta en este recuadro es una versión adaptada y abreviada de otro, propuesto por Tyree y Ackerman [Tyr05]. Aspecto del diseño: Resolución: Categoría:

Suposiciones: Restricciones:

PU

Se describen los aspectos del diseño arquitectónico que se van a abordar. Se establece el enfoque escogido para abordar el aspecto de diseño. Se especifica la categoría de diseño a que se aboca el aspecto y la resolución (por ejemplo, diseño de datos, estructura del contenido, estructura del componente, integración, presentación, etcétera). Se indican cualesquiera suposiciones que ayuden a dar forma a la decisión. Se especifican todas las restricciones ambientales que ayuden a conformar la decisión (como los estándares tecnológicos, patrones disponibles y aspectos relacionados con el diseño).

Alternativas:

Argumento: Implicaciones:

Decisiones relacionadas: Preocupaciones relacionadas: Productos finales: Notas:

Se describen con brevedad las alternativas de diseño arquitectónico que se consideraron y la razón por la que se rechazaron. Se establece por qué se eligió la resolución sobre las demás alternativas. Se indican las consecuencias que tendrá la toma de la decisión en el diseño. ¿Cómo afectará la resolución a otros aspectos del diseño de la arquitectura? ¿La resolución restringe de algún modo al diseño? ¿Qué otros documentos se relacionan con esta decisión? ¿Qué otros requerimientos se relacionan con esta decisión? Se indica dónde se reflejará esta decisión en la descripción arquitectónica. Se hace referencia a las anotaciones del equipo u otra clase de documentación que se haya empleado para tomar la decisión.

una categoría específica dentro del dominio general del software. Dentro de cada categoría hay

NT

O

CLAVE

Diversos estilos arquitectónicos pueden aplicarse a un género específico (también conocido como dominio de aplicación).

varias subcategorías. Por ejemplo, dentro del género edificios, se encuentran los siguientes estilos generales: casas, condominios, edificios de departamentos, edificios de oficinas, edificios industriales, bodegas, etc. Dentro de cada estilo general habrá estilos más específicos (véase la sección 9.3). Cada estilo tendrá una estructura que puede describirse con el uso de un conjunto de patrones predecibles. En su texto evolutivo Handbook of Software Architecture [Boo08], Grady Booch sugiere los siguientes géneros arquitectónicos para sistemas basados en software:

• Inteligencia artificial: Sistemas que simulan o incrementan la cognición humana, su locomoción u otros procesos orgánicos.

• Comerciales y no lucrativos: Sistemas que son fundamentales para la operación de una empresa de negocios.

• Comunicaciones: Sistemas que proveen la infraestructura para transferir y manejar datos, para conectar usuarios de éstos o para presentar datos en la frontera de una infraestructura.

• Contenido de autor: Sistemas que se emplean para crear o manipular artefactos de texto o multimedios.

• Dispositivos: Sistemas que interactúan con el mundo físico a fin de brindar algún servicio puntual a un individuo.

• Entretenimiento y deportes: Sistemas que administran eventos públicos o que proveen una experiencia grupal de entretenimiento.

• Financieros: Sistemas que proporcionan la infraestructura para transferir y manejar dinero y otros títulos.

• Juegos: Sistemas que dan una experiencia de entretenimiento a individuos o grupos.


14/1/10 15:44:36

C AP Í T UL O 9

211


• Gobierno: Sistemas que dan apoyo a la conducción y operaciones de una institución

Cita:

política local, estatal, federal, global o de otro tipo.

“Programar sin una arquitectura o diseño general en mente es como explorar una caverna sólo con una linterna: no sabes dónde has estado, a dónde vas ni dónde estás.”

• Industrial: Sistemas que simulan o controlan procesos físicos.

Danny Thorpe

• Sistemas operativos: Sistemas que están inmediatamente instalados en el hardware

• Legal: Sistemas que dan apoyo a la industria jurídica. • Médicos: Sistemas que diagnostican, curan o contribuyen a la investigación médica. • Militares: Sistemas de consulta, comunicaciones, comando, control e inteligencia (o C4I), así como de armas ofensivas y defensivas. para dar servicios de software básico.

• Plataformas: Sistemas que se encuentran en los sistemas operativos para brindar servicios avanzados.

• Científicos: Sistemas que se emplean para hacer investigación científica y aplicada. • Herramientas: Sistemas que se utilizan para desarrollar otros sistemas. • Transporte: Sistemas que controlan vehículos acuáticos, terrestres, aéreos o espaciales. • Utilidades: Sistemas que interactúan con otro software para brindar algún servicio específico. Desde el punto de vista del diseño arquitectónico, cada género representa un desafío único. Por ejemplo, considere la arquitectura del software de un sistema de juego. Esta clase de sistemas, en ocasiones llamados aplicaciones interactivas de inmersión, requieren el cómputo de algoritmos intensivos, gráficas avanzadas en computadora, fuentes de datos continuas en multimedios, interactividad en tiempo real a través de dispositivos de entrada convencionales y no convencionales, y otras preocupaciones especializadas. Alexander Francois [Fra03] sugiere una arquitectura del software para inmerpresencia1 que se aplica a un ambiente de juegos. Él describe la arquitectura de la manera siguiente: La ASI (Arquitectura de Software de Inmerpresencia) es un modelo nuevo de arquitectura de software para diseñar, analizar e implementar aplicaciones que realizan un procesamiento distribuido, asíncrono y paralelo de flujos de datos generales. El objetivo de la ASI es proveer un marco universal para la implementación distribuida de algoritmos y su fácil integración en sistemas complejos […] El modelo de procesamiento de datos extensibles subyacentes y el modelo de procesamiento híbrido (depósito y transmisión de mensajes compartidos), asíncrono y en paralelo permiten la manipulación natural y eficiente de flujos de datos generales con el uso indistinto de librerías ya existentes o código original. La modularidad del estilo facilita el desarrollo de código distribuido, pruebas y reutilización, así como el diseño e integración rápida del sistema y su mantenimiento y evolución.

El análisis detallado del ASI queda fuera del alcance de este libro. No obstante, es importante reconocer que el género de sistemas de juegos puede abordarse con un estilo arquitectónico (véase la sección 9.3) diseñado específicamente para resolver preocupaciones de sistemas de juego. Si el lector tiene especial interés, consulte [Fra03].

9. 3

ESTILOS

ARQUITECTÓNICOS

Cuando un constructor usa la frase “vestíbulo central colonial” para describir una casa, la mayor parte de personas familiarizadas con viviendas en Estados Unidos se hará una imagen general de ella y de cuál es su probable distribución. El constructor usó un estilo arquitectónico como mecanismo descriptivo para diferenciar la casa de otros estilos (por ejemplo, de dos aguas, finca

1


Francois utiliza el término inmerpresencia para denotar aplicaciones interactivas de inmersión.

14/1/10 15:44:37

212

PAR T E DOS

MO D E LADO

campestre, Cabo Cod, etc.). Pero, lo que es más importante, el estilo arquitectónico también es

Cita:

una plantilla para la construcción. Deben definirse más detalles, especificar sus dimensiones

“En el fondo de la mente de todo artista hay un patrón o tipo de arquitectura.” G. K. Chesterton

finales, agregar características personalizadas, determinar los materiales de construcción, pero el estilo (un “vestíbulo central colonial”) orienta al constructor en su trabajo. El software construido para sistemas basados en computadora también tiene uno de muchos estilos arquitectónicos. Cada estilo describe una categoría de sistemas que incluye 1) un conjunto de componentes (como una base de datos o módulos de cómputo) que realizan una función requerida por el sistema, 2) un conjunto de conectores que permiten la “comunicación,

?

¿Qué es un estilo arquitectónico?

coordinación y cooperación” entre los componentes, 3) restricciones que definen cómo se integran los componentes para formar el sistema y 4) modelos semánticos que permiten que un diseñador entienda las propiedades generales del sistema al analizar las propiedades conocidas de sus partes constituyentes [Bas03].

WebRef Los estilos arquitectónicos basados en atributos (ABAS) pueden usarse como bloques de construcción para las arquitecturas de software. En la dirección www.sei.cmu.edu/ architecture/abas.html, hay información al respecto.

Un estilo arquitectónico es una transformación que se impone al diseño de todo el sistema. El objetivo es establecer una estructura para todos los componentes del sistema. En el caso en el que ha de hacerse la reingeniería de una arquitectura ya existente (véase el capítulo 29), la imposición de un estilo arquitectónico dará como resultado cambios fundamentales en la estructura del software, incluida la reasignación de las funciones de los componentes [Bos00]. Un patrón arquitectónico, como un estilo de arquitectura, impone la transformación del diseño de una arquitectura. Sin embargo, un patrón difiere de un estilo en varias formas fundamentales: 1) el alcance del patrón es menos amplio y se centra en un aspecto de la arquitectura más que en el total de ésta, 2) un patrón impone una regla a la arquitectura, describe la manera en la que el software manejará ciertos aspectos de su funcionalidad en el nivel de la infraestructura (por ejemplo, la concurrencia) [Bos00], 3) los patrones arquitectónicos (véase la sección 9.4) tienden a abocarse a aspectos específicos del comportamiento en el contexto de la arquitectura (por ejemplo, cómo manejarán la sincronización o las interrupciones las aplicaciones en tiempo real). Los patrones se utilizan junto con un estilo arquitectónico para dar forma a la estructura

I NFOR MACIÓN Estructuras arquitectónicas canónicas En esencia, la arquitectura del software representa una estructura en la que cierta colección de entidades (con frecuencia llamados componentes) está conectada por un conjunto de relaciones definidas (usualmente llamadas conectores). Tanto las componentes como los conectores están asociados con un conjunto de propiedades que permiten que el diseñador diferencie los tipos de componentes y conectores que pueden usarse. Pero, ¿qué clases de estructuras (componentes, conectores y propiedades) se utilizan para describir una arquitectura? Bass y Kazman [Bas03] sugieren cinco estructuras canónicas o fundamentales: Estructura funcional. Los componentes representan entidades de función o procesamiento. Los conectores representan interfaces que proveen la capacidad de “usar” o “pasar datos a” un componente. Las propiedades describen la naturaleza de los componentes y la organización de las interfaces. Estructura de implementación. “Los componentes son paquetes, clases, objetos, procedimientos, funciones, métodos, etc., que son vehículos para empacar funciones en varios niveles de abstracción” [Bas03]. Los conectores incluyen la capacidad de pasar datos y control, compartir datos, “usar” y “ser una instancia de”. Las propiedades se centran en las características de la calidad (por ejemplo, facili-


dad de recibir mantenimiento, ser reutilizables, etc.) que surgen cuando se implementa la estructura. Estructura de concurrencia. Los componentes representan “unidades de concurrencia” que están organizadas como tareas o trayectorias paralelas. “Las relaciones [conectores] incluyen sincronizarsecon, tiene-mayor-prioridad-que, envía-datos-a, no-corre-sin y no-corre-con. Las propiedades relevantes para esta estructura incluyen prioridad, anticipación y tiempo de ejecución” [Bas03]. Estructura física. Esta estructura es similar al modelo de despliegue desarrollado como parte del diseño. Los componentes son el hardware físico en el que reside el software. Los conectores son las interfaces entre los componentes del hardware y las propiedades incluyen la capacidad, ancho de banda y rendimiento, entre otros atributos. Estructura de desarrollo. Esta estructura define los componentes, productos del trabajo y otras fuentes de información que se requieren a medida que avanza la ingeniería de software. Los conectores representan las relaciones entre los productos del trabajo; las propiedades identifican las características de cada aspecto. Cada una de estas estructuras presenta un punto de vista de la arquitectura del software y expone información que es útil para el equipo de software a medida que realiza la modelación y construcción.

14/1/10 15:44:37

C AP Í T UL O 9

213


general de un sistema. En la sección 9.3.1 se consideran los estilos y patrones arquitectónicos comunes para el software.

9.3.1

Breve taxonomía de estilos de arquitectura

Aunque en los últimos 60 años se han creado millones de sistemas basados en computadoras,

Cita:

la gran mayoría se clasifica en un número relativamente pequeño de estilos de arquitectura:

“El uso de patrones y estilos de diseño está presente en todas las disciplinas de la ingeniería.”

Arquitecturas centradas en los datos.

Mary Shaw y David Garlan

del almacenamiento. La figura 9.1 ilustra un estilo común centrado en datos. El software cliente

En el centro de esta arquitectura se halla un alma-

cenamiento de datos (como un archivo o base de datos) al que acceden con frecuencia otros componentes que actualizan, agregan, eliminan o modifican los datos de cierto modo dentro accede a un repositorio (depósito) central. En ciertos casos éste es pasivo. Es decir, el software cliente accede a los datos en forma independiente de cualesquiera cambios que éstos sufran o de las acciones del software de otro cliente. Una variante de este enfoque transforma el depósito en un “pizarrón” que envía notificaciones al software cliente cuando hay un cambio en datos de interés del cliente. Las arquitecturas centradas en datos promueven la integrabilidad [Bas03]. Es decir, los componentes del software pueden ser cambiados y agregarse otros nuevos, del cliente, a la arquitectura sin problemas con otros clientes (porque los componentes del cliente operan en forma independiente). Además, pueden pasarse datos entre clientes con el uso de un mecanismo de pizarrón (el componente pizarrón sirve para coordinar la transferencia de información entre clientes). Los componentes del cliente ejecutan los procesos con independencia. Arquitecturas de flujo de datos.

Esta arquitectura se aplica cuando datos de entrada van a

transformarse en datos de salida a través de una serie de componentes computacionales o manipuladores. Un patrón de tubo y filtro (véase la figura 9.2) tiene un conjunto de componentes, llamados filtros, conectados por tubos que transmiten datos de un componente al siguiente. Cada filtro trabaja en forma independiente de aquellos componentes que se localizan arriba o abajo del flujo; se diseña para esperar una entrada de datos de cierta forma y produce datos de salida (al filtro siguiente) en una forma especificada. Sin embargo, el filtro no requiere ningún conocimiento de los trabajos que realizan los filtros vecinos. Si el flujo de datos degenera en una sola línea de transformaciones, se denomina lote secuencial. Esta estructura acepta un lote de datos y luego aplica una serie de componentes secuenciales (filtros) para transformarlos.

FIGURA 9.1 Arquitectura centrada en datos

Software cliente

Software cliente

Software cliente

Software cliente

Almacenamiento de datos (repositorio o pizarrón)

Software cliente


Software cliente

Software cliente

Software cliente

14/1/10 15:44:37

214

PAR T E DOS

MO D E LADO

FIGURA 9.2 Tubos

Arquitectura de flujo de datos Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Filtro

Tubos y filtros

Arquitecturas de llamar y regresar. Este estilo arquitectónico permite obtener una estructura de programa que es relativamente fácil de modificar y escalar. Dentro de esta categoría existen varios subestilos [Bas03]:

• Arquitecturas de programa principal/subprograma. Esta estructura clásica de programa descompone una función en una jerarquía de control en la que un programa “principal” invoca cierto número de componentes de programa que a su vez invocan a otros. La figura 9.3 ilustra una arquitectura de este tipo.

• Arquitecturas de llamada de procedimiento remoto. Los componentes de una arquitectura de programa principal/subprograma están distribuidos a través de computadoras múltiples en una red. Arquitecturas orientadas a objetos. Los componentes de un sistema incluyen datos y las operaciones que deben aplicarse para manipularlos. La comunicación y coordinación entre los componentes se consigue mediante la transmisión de mensajes. Arquitecturas en capas. En la figura 9.4 se ilustra la estructura básica de una arquitectura en capas. Se define un número de capas diferentes; cada una ejecuta operaciones que se aproximan progresivamente al conjunto de instrucciones de máquina. En la capa externa, los compo-

FIGURA 9.3 Programa principal

Arquitectura de programa principal/ subprograma

Subprograma controlador

Subprograma de aplicación










14/1/10 15:44:38

C AP Í T UL O 9

FIGURA 9.4


215

Componentes

Arquitectura en capas

Capa de la interfaz de usuario Capa de aplicación Capa de utilerías Capa núcleo

nentes atienden las operaciones de la interfaz de usuario. En la interna, los componentes realizan la interfaz con el sistema operativo. Las capas intermedias proveen servicios de utilerías y funciones de software de aplicación. Estos estilos arquitectónicos tan sólo son un pequeño subconjunto de los que están disponibles.2 Una vez que la ingeniería de requerimientos revela las características y restricciones del sistema que se va a elaborar, se elige el estilo arquitectónico o la combinación de patrones que se ajusten mejor a esas características y restricciones. En muchos casos, más de un patrón es apropiado y es posible diseñar y evaluar estilos arquitectónicos alternativos. Por ejemplo, en muchas aplicaciones de bases de datos se combina un estilo en capas (apropiado para la mayoría de sistemas) con una arquitectura centrada en datos.

9.3.2

Patrones arquitectónicos

A medida que se desarrolle el modelo de requerimientos, se observará que el software debe

Cita: “Tal vez está en la planta baja. Déjame subir a revisar.”

enfrentar cierto número de problemas amplios que abarcan toda la aplicación. Por ejemplo, el modelo de requerimientos para virtualmente cualquier aplicación de comercio electrónico se enfrenta con el siguiente problema: ¿Cómo ofrecer una amplia variedad de bienes a un grupo extenso de consumidores y permitir que los adquieran en línea?

M. C. Escher

El modelo de requerimientos también define un contexto en el que debe responderse esta pregunta. Por ejemplo, un negocio de comercio electrónico que venda equipo de golf de consumo operará en un contexto diferente que otro que venda equipo industrial de precio alto a corporaciones medianas y pequeñas. Además, hay varias limitantes y restricciones que afectan la manera en la que se aborda este problema para resolverlo. Los patrones arquitectónicos se abocan a un problema de aplicación específica dentro de un contexto dado y sujeto a limitaciones y restricciones. El patrón propone una solución arquitectónica que sirve como base para el diseño de la arquitectura. En una sección anterior, se dijo que la mayor parte de aplicaciones caen dentro de un dominio o género específico, y que para éstas son apropiados uno o más estilos de arquitectura. Por ejemplo, el estilo de arquitectura general para una aplicación podría ser el de llamar y regresar o el que está orientado a objeto. Pero dentro de ese estilo se encontrará un conjunto de problemas comu-

2

Para un estudio detallado de estilos y patrones arquitectónicos, véase [Bus07], [Gor06], [Roz05], [Bas03], [Bos00] y [Hof00].


14/1/10 15:44:38

216

PAR T E DOS

MO D E LADO

C ASA S EGURA 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 visualizar 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.

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.

Jamie (sonríe): Amorfo, ¿eh?

nes que se abordan mejor con patrones arquitectónicos específicos. En el capítulo 12 se presentan algunos de estos problemas y se hace un estudio más completo de los patrones de arquitectura.

9.3.3

Organización y refinamiento

Debido a que es frecuente que el proceso de diseño permita varias alternativas de arquitectura, es importante establecer un conjunto de criterios de diseño que se usan para evaluar el diseño arquitectónico obtenido. Las preguntas que siguen [Bas03] dan una visión del estilo de arquitectura:

?

Control. ¿Cómo se administra el control dentro de la arquitectura? ¿Existe una jerarquía

¿Cómo se evalúa el estilo arquitectónico que se haya obtenido?

de control distinta? Si es así, ¿cuál es el papel de los componentes dentro de esta jerarquía de control? ¿Cómo transfieren el control los componentes dentro del sistema? ¿Cómo lo comparten? ¿Cuál es la topología del control (por ejemplo, la forma geométrica que adopta el control)? ¿El control está sincronizado o los componentes operan en forma asincrónica? Datos. ¿Cómo se comunican los datos entre los componentes? ¿El flujo de datos es continuo o los objetos de datos pasan al sistema en forma esporádica? ¿Cuál es el modo de transferencia de datos (pasan de un componente a otro o se dispone de ellos globalmente para compartirse entre los componentes del sistema)? ¿Existen componentes de datos (como un pizarrón o depósito) y, si así fuera, cuál es su papel? ¿Cómo interactúan los componentes funcionales con los componentes de datos? ¿Los componentes de datos son pasivos o activos (el componente de datos actúa activamente con otros componentes del sistema)? ¿Cómo interactúan los datos y el control dentro del sistema?

3

Podría afirmarse que la arquitectura de CasaSegura debe considerarse en un nivel más alto que la que se comenta. CasaSegura tiene varios subsistemas: vigilancia de las funciones del hogar, vigilancia del sitio de la empresa y el subsistema que corre en la PC del propietario. Dentro de los subsistemas son comunes los procesos concurrentes (por ejemplo, los que vigilan sensores) y los que manejan eventos. En este nivel, algunas decisiones de arquitectura se toman durante la ingeniería del producto, pero el diseño arquitectónico dentro de la ingeniería de software muy bien debe considerar estos aspectos.


14/1/10 15:44:38

C AP Í T UL O 9

217


Estas preguntas dan al diseñador una evaluación temprana de la calidad del diseño y proporcionan el fundamento para hacer análisis más detallados de la arquitectura.

9. 4

DISEÑO

ARQUITECTÓNICO

Cuando comienza el diseño arquitectónico, el software que se va a desarrollar debe situarse en

Cita: “Un doctor puede sepultar sus errores, pero un arquitecto sólo puede aconsejar a su cliente que siembre enredaderas.” Frank Lloyd Wright

contexto, es decir, el diseño debe definir las entidades externas (otros sistemas, dispositivos, personas, etc.) con las que interactúa el software y la naturaleza de dicha interacción. Esta información por lo general se adquiere a partir del modelo de los requerimientos y de toda la que se reunió durante la ingeniería de éstos. Una vez que se ha modelado el contexto y descrito todas las interfaces externas del software, se identifica un conjunto de arquetipos de arquitectura. Un arquetipo es una abstracción (similar a una clase) que representa un elemento de comportamiento del sistema. El conjunto de arquetipos provee una colección de abstracciones que deben modelarse en cuanto a la arquitectura si el sistema ha de construirse, pero los arquetipos por sí mismos no dan suficientes detalles para la implementación. Por tanto, el diseñador especifica la estructura del sistema, definiendo y refinando los componentes del software que implementan cada arquetipo. Este proceso sigue en forma iterativa hasta que se obtiene una estructura arquitectónica completa. En las secciones que siguen se estudia cada una de estas tareas de diseño arquitectónico con un poco más de detalle.

9.4.1 PU

Representación del sistema en contexto

En el nivel de diseño arquitectónico, el arquitecto del software usa un diagrama de contexto ar-

NT

O

CLAVE

El contexto arquitectónico representa la manera en la que el software interactúa con las entidades externas a sus fronteras.

quitectónico (DCA) para modelar la manera en la que el software interactúa con entidades más allá de sus fronteras. La estructura general del diagrama de contexto arquitectónico se ilustra en la figura 9.5. En relación con dicha figura, los sistemas que interactúan con el sistema objetivo (aquel para el que va a desarrollarse un diseño arquitectónico) están representados como sigue:

• Sistemas superiores: aquellos que utilizan al sistema objetivo como parte de algún esquema de procesamiento de alto nivel.

?

¿Cómo interactúan los sistemas uno con el otro?

• Sistemas subordinados: los que son usados por el sistema objetivo y proveen datos o procesamiento que son necesarios para completar las funciones del sistema objetivo.

• Sistemas entre iguales: son los que interactúan sobre una base de igualdad (por ejemplo, la información se produce o consume por los iguales y por el sistema objetivo).

• Actores: entidades (personas, dispositivos, etc.) que interactúan con el sistema objetivo mediante la producción o consumo de información que es necesaria para el procesamiento de los requerimientos. Cada una de estas entidades externas se comunica con el sistema objetivo a través de una interfaz (rectángulos pequeños sombreados). Para ilustrar el empleo del DCA, considere la función de seguridad del hogar del producto CasaSegura. El controlador general del producto CasaSegura y el sistema basado en internet son superiores respecto de la función de seguridad y se muestran por arriba de la función en la figura 9.6. La función de vigilancia es un sistema entre iguales y en las versiones posteriores del producto usa (es usada por) la función de seguridad del hogar. El propietario y los paneles de control son actores que producen y consumen información usada o producida por el software de seguridad. Por último, los sensores se utilizan por el software de seguridad y se muestran como subordinados a éste.


14/1/10 15:44:39

218

PAR T E DOS

MO D E LADO

FIGURA 9.5

Sistemas superiores

Diagrama de contexto arquitectónico Fuente: Adaptado de [Bos00].

Usados por

Sistema objetivo Usos Pares

Usos Actores Depende de

Sistemas subordinados

Como parte del diseño arquitectónico, tendrían que especificarse los detalles de cada interfaz mostrada en la figura 9.6. En esta etapa deben identificarse todos los datos que fluyen hacia dentro y fuera del sistema objetivo.

9.4.2 PU

Definición de arquetipos

Un arquetipo es una clase o un patrón que representa una abstracción fundamental de impor-

NT

O

CLAVE

Los arquetipos son los bloques constructivos de un diseño arquitectónico.

tancia crítica para el diseño de una arquitectura para el sistema objetivo. En general, se requiere de un conjunto relativamente pequeño de arquetipos a fin de diseñar sistemas incluso algo complejos. La arquitectura del sistema objetivo está compuesta de estos arquetipos, que representan elementos estables de la arquitectura, pero que son implementadas en muchos modos diferentes con base en el comportamiento del sistema. En muchos casos, los arquetipos se obtienen con el estudio de las clases de análisis definidas como parte del modelo de los requerimientos. Al continuar el análisis de la función de seguridad de CasaSegura, se definirán los arquetipos siguientes:

FIGURA 9.6 Producto CasaSegura

Diagrama de contexto arquitectónico para la función de seguridad de CasaSegura

Panel de control

Propietario

Sistema basado en internet

Sistema objetivo: función de seguridad

Usos

Función de vigilancia Pares

Usos

Usos Sensores


Sensores

14/1/10 15:44:39

C AP Í T UL O 9

FIGURA 9.7

219


Controlador

Relaciones de UML para los arquetipos de la función de seguridad de CasaSegura Fuente: Adaptado de [Bos00].

Se comunica con

Nodo

Detector

Indicador

• Nodo. Representa una colección cohesiva de elementos de entrada y salida de la función de seguridad del hogar. Por ejemplo, un nodo podría comprender 1) varios sensores y 2) varios indicadores de alarma (salida).

• Detector. Abstracción que incluye todos los equipos de detección que alimentan con información al sistema objetivo.

• Indicador. Abstracción que representa todos los mecanismos (como la sirena de la alarma, luces, campana, etc.) que indican que está ocurriendo una condición de alarma.

• Controlador. Abstracción que ilustra el mecanismo que permite armar o desarmar un nodo. Si los controladores residen en una red, tienen la capacidad de comunicarse entre sí. En la figura 9.7 se muestra cada uno de estos arquetipos con el empleo de notación UML. Recuerde que los arquetipos constituyen la base de la arquitectura, pero son abstracciones que deben refinarse a medida que avanza el diseño arquitectónico. Por ejemplo, Detector se refinaría en una jerarquía de clase de sensores.

9.4.3

Refinamiento de la arquitectura hacia los componentes

Conforme la arquitectura se refina hacia los componentes, comienza a emerger la estructura del

Cita: “La estructura de un sistema de software provee la ecología en la que el código nace, crece y muere. Un hábitat bien diseñado permite la evolución exitosa de todos los componentes necesarios en un sistema de software.” R. Pattis

sistema. Pero, ¿cómo se eligen estos componentes? Para responder esta pregunta se comienza con las clases descritas como parte del modelo de requerimientos.4 Estas clases de análisis representan entidades dentro del dominio de aplicación (negocio) que deben enfrentarse dentro de la arquitectura del software. Entonces, el dominio de aplicación es una fuente para la obtención y refinamiento de los componentes. Otra fuente es el dominio de la infraestructura. La arquitectura debe albergar muchas componentes de la infraestructura que hagan posible los componentes de la aplicación, pero que no tengan conexión con el dominio de ésta. Por ejemplo, los componentes de administración de memoria, de comunicación, de base de datos y de administración de tareas con frecuencia están integrados en la arquitectura del software. Las interfaces ilustradas en el diagrama de contexto de la arquitectura (sección 9.4.1) implican uno o más componentes especializados que procesan los datos que fluyen a través de la

4

Si se elige un enfoque convencional (no orientado a objeto), los componentes se obtienen a partir de los datos del modelo del flujo. Este enfoque se estudia brevemente en la sección 9.6.


14/1/10 15:44:39

220

PAR T E DOS

MO D E LADO

interfaz. En ciertos casos (por ejemplo, una interfaz de usuario gráfica) debe diseñarse una arquitectura completa con muchos componentes para el subsistema. Al seguir con el ejemplo de la función de seguridad de CasaSegura, debe definirse el conjunto de componentes de alto nivel que se aboque a las funciones siguientes:

• Administración de la comunicación externa: coordina la comunicación de la función de seguridad con entidades externas, tales como otros sistemas basados en internet y la notificación externa de una alarma.

• Procesamiento del panel de control: administra toda la funcionalidad del panel de control. • Administración de detectores: coordina el acceso a todos los detectores del sistema. • Procesamiento de alarmas: verifica y actúa en todas las condiciones de alarma. Cada uno de estos componentes de alto nivel tendría que elaborarse en forma iterativa para después posicionarlo dentro de la arquitectura general de CasaSegura. Para cada uno se definirían las clases de diseño (con los atributos y operaciones apropiadas). Sin embargo, es importante observar que los detalles de diseño de todos los atributos y operaciones no se especificarían hasta abordar el diseño en el nivel de componentes (véase el capítulo 10). La estructura arquitectónica general (representada como diagrama de componentes UML) se ilustra en la figura 9.8. Las transacciones son adquiridas por administración de la comunicación externa a medida que se mueven desde los componentes que procesan la GUI de CasaSegura y la interfaz de internet. Esta información es administrada por un componente ejecutivo de CasaSegura que selecciona la función apropiada del producto (la seguridad, en este caso). El componente procesamiento en el panel de control interactúa con el propietario para activar o desactivar la función de seguridad. El componente administración de detectores prueba los sensores para detectar una condición de alarma y el componente procesamiento de alarmas produce la salida cuando se detecta una alarma.

9.4.4

Descripción de las instancias del sistema

El diseño arquitectónico modelado hasta este momento todavía es de nivel relativamente alto. Se ha representado el contexto del sistema, se definieron los arquetipos que indican las abstracciones importantes dentro del dominio del problema, es visible la estructura general del sistema

FIGURA 9.8 Estructura arquitectónica general para los componentes de alto nivel de CasaSegura

Ejecutivo de CasaSegura Selección de función Administración de la comunicación externa

-

GUI

Vigilancia

Administración del hogar

Interfaz de internet

Procesamiento en el panel de control


Seguridad

Administración de detectores

Procesamiento de alarmas

14/1/10 15:44:39

C AP Í T UL O 9

221


y están identificadas las componentes principales del software. Sin embargo, es necesario más refinamiento (recuerde que todo el diseño es iterativo). Para lograr esto, se desarrollan instancias de la arquitectura. Esto significa que la arquitectura se aplica a un problema específico con objeto de demostrar que tanto ella como sus componentes son apropiados. La figura 9.9 ilustra instancias de la arquitectura de CasaSegura para el sistema de seguridad. Los componentes ilustrados en la figura 9.8 se elaboraron para mostrar más detalles. Por ejemplo, el componente administración de detectores interactúa con un componente de infraestructura programador que implementa la prueba de cada objeto sensor usado por el sistema de seguridad. Una elaboración similar se lleva a cabo para cada uno de los componentes representados en la figura 9.8.

H ERRAMIENTAS

DE SOFTWARE

Diseño arquitectónico Objetivo: Las herramientas de diseño arquitectónico modelan la estructura general del software mediante la representación de la interfaz de los componentes, de sus dependencias y relaciones, así como de sus interacciones. Mecánica: La mecánica de las herramientas varía. En la mayoría de casos, la capacidad de diseño de la arquitectura es parte de las funciones provistas por herramientas automatizadas para el modelado del análisis y el diseño. Herramientas representativas:5 Adalon, desarrollada por Synthis Corp. (www.synthis.com), es una herramienta de diseño especializada para diseñar y construir arquitecturas de componentes específicos basados en web.

9. 5

EVALUACIÓN

ObjectiF, desarrollada por microTOOL GmbH (www.microtool. de/objectiF/en/), es una herramienta de diseño basada en UML que conduce a arquitecturas (como Coldfusion, J2EE, Fusebox, etc.) adecuadas para la ingeniería de software basada en componentes (véase el capítulo 29). Rational Rose, desarrollada por Rational (www-306.ibm.com/ software/rational/), es una herramienta de diseño basada en UML que proporciona apoyo a todos los aspectos del diseño de la arquitectura.

DE LOS DISEÑOS ALTER NATIVOS PARA LA ARQUITECTURA

En su libro sobre evaluación de las arquitecturas de software, Clements et al. [Cle03] afirman lo siguiente: Para decirlo sin rodeos, una arquitectura es una apuesta, una adivinanza sobre el éxito de un sistema. ¿No sería agradable saber por adelantado si se apostó a un ganador en vez de esperar hasta que el sistema esté casi terminado para saber si cumplirá con los requerimientos o no? Si usted compra un sistema o paga por su desarrollo, ¿no querría tener alguna seguridad de que va por el camino correcto? Si usted mismo es el arquitecto, ¿no le gustaría tener una buena manera de validar sus intuiciones y experiencia para que pudiera dormir por la noche con la certeza de que la confianza puesta en su diseño está bien fundamentada?

En verdad, las respuestas a estas preguntas tendrían un valor. El diseño da como resultado varias alternativas de arquitectura, cada una de las cuales se evalúa para determinar cuál es la más apropiada para el problema por resolver. En las secciones que siguen se presentan dos enfoques diferentes para la evaluación de diseños arquitectónicos alternativos. El primero utiliza un método iterativo para evaluar negociaciones en el diseño. El segundo aplica una técnica seudocuantitativa para evaluar la calidad del diseño.

5

Las herramientas mencionadas aquí no son obligatorias; sólo son una muestra en esta categoría. En la mayoría de casos, sus nombres son marcas registradas por sus desarrolladores respectivos.


14/1/10 15:44:39

222

PAR T E DOS

MO D E LADO

FIGURA 9.9 Ejecutivo de CasaSegura

Instancias de la función de seguridad con la elaboración de componentes Administración de la comunicación externa

Seguridad GUI

Interfaz de internet Procesamiento en el panel de control Procesamiento en el teclado

Administración de detectores

Programador

Procesamiento de alarmas

Comunicación telefónica

Funciones en la pantalla CP

Alarma Sensor

9.5.1 WebRef En la dirección www.sei.cmu. edu/activities/architecture/ ata_method.html, puede obtenerse mucha información sobre el ATAM.

Método de la negociación para analizar la arquitectura

El Instituto de Ingeniería de Software (SEI, por sus siglas en inglés) desarrolló el método de la negociación para analizar la arquitectura (Architecture trade-off analysis method -ATAM) [Kaz98], que establece un proceso de evaluación iterativo para arquitecturas de software. Las actividades de análisis del diseño que se mencionan a continuación se llevan a cabo en forma iterativa: 1. Escenarios de investigación. Se desarrolla un conjunto de casos de uso (véanse los capítulos 5 y 6) para representar al sistema desde el punto de vista del usuario. 2. Obtención de los requerimientos y restricciones, y descripción del ambiente. Esta información se determina como parte de la ingeniería de requerimientos y se utiliza para estar seguros de que se han detectado todas las preocupaciones de los participantes. 3. Descripción de los estilos o patrones de arquitectura elegidos para abordar los escenarios y requerimientos. Debe describirse el estilo arquitectónico con el empleo de las siguientes perspectivas arquitectónicas:

• Perspectiva modular para el análisis de las asignaciones de trabajo con componentes y grado en el que se logra el ocultamiento de información.

• Perspectiva del proceso para el análisis del desempeño del sistema. • Perspectiva del flujo de datos para analizar el grado en el que la arquitectura satisface los requerimientos funcionales. 4. Evaluación de los atributos de calidad, considerando cada atributo por separado. El número de atributos de la calidad elegidos para el análisis es una función del tiempo disponible para la revisión y el grado en el que los atributos de calidad son relevantes para el sistema en cuestión. Los atributos de calidad para evaluar el diseño arquitectónico


14/1/10 15:44:40

C AP Í T UL O 9

223


incluyen confiabilidad, desempeño, seguridad, facilidad de mantenimiento, flexibilidad, facilidad de hacer pruebas, portabilidad, reutilización e interactuación. 5. Identificación de la sensibilidad de los atributos de calidad de varios atributos arquitectónicos para un estilo de arquitectura específico. Eso se lleva a cabo haciendo cambios pequeños en la arquitectura a fin de determinar la sensibilidad que tiene un atributo de calidad, por ejemplo, el desempeño ante el cambio. Cualesquiera atributos que se vean afectados en forma significativa por la variación de la arquitectura se denominan puntos sensibles. 6. Crítica de las arquitecturas candidatas (desarrollado en el paso 3) con el uso del análisis de sensibilidad realizado en el paso 5. El SEI describe este enfoque de la manera siguiente [Kaz98]: Una vez determinados los puntos sensibles de la arquitectura, la detección de puntos de negociación es simplemente la identificación de los elementos de la arquitectura a los que atributos múltiples son sensibles. Por ejemplo, el desempeño de una arquitectura cliente-servidor podría ser muy sensible al número de servidores (aumenta el desempeño, en cierto rango, con el incremento del número de servidores) […] Entonces, el número de servidores es un punto de negociación con respecto de esta arquitectura.

Estos seis pasos representan la primera iteración ATAM. Con base en los resultados de los pasos 5 y 6, se eliminan algunas arquitecturas alternativas o se modifican una o varias de las restantes a fin de representarlas con más detalle para después volver a aplicar el ATAM.6

C ASA S EGURA 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?

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.

Ed: Estoy trabajando en un estilo de llamada y regreso, luego alguno de los dos, Jamie o yo, derivará a una arquitectura OO.

Doug: Hablas de un escenario de calidad o de un escenario de cambio, ¿verdad?

Doug: Muy bien. ¿Y cómo podemos elegir?

Vinod: Los hay, pero son algo académicos. Miren, pienso que podemos evaluarlos y escoger el correcto con el uso de casos y escenarios.

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.

Doug: ¿No es lo mismo?

Jamie: Y los aplicamos a las alternativas.

Vinod: No si hablas de evaluar la arquitectura. Ya tenemos un conjunto completo de casos de uso. Así que los aplicaremos a las dos

Vinod: Exacto. Elegiremos el estilo que mejor maneje los casos de uso y los escenarios.

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.

6

El Método de Análisis de la Arquitectura del Software (MAAS) es una alternativa al ATAM y es de mucha utilidad para los lectores interesados en el análisis arquitectónico. Puede descargarse un artículo sobre el MAAS de la dirección www.sei.cmu.edu/publications/articles/saam-metho-propert-sas.html


14/1/10 15:44:40

224

PAR T E DOS

9.5.2

MO D E LADO

Complejidad arquitectónica

Una técnica útil para evaluar la complejidad general de una arquitectura propuesta es considerar las dependencias entre los componentes dentro de la arquitectura. Estas dependencias están motivadas por el flujo de la información o por el control dentro del sistema. Zhao [Zha98] sugiere tres tipos de dependencias: Las dependencias compartidas representan relaciones entre consumidores que usan los mismos recursos o productores que producen para los mismos consumidores. Por ejemplo, para dos componentes u y v, si u y v se refieren a los mismos datos globales, entonces existe una relación de dependencia compartida entre u y v. Las dependencias de flujo representan relaciones de dependencia entre productores y consumidores de recursos. Por ejemplo, para dos componentes u y v, si u debe completarse para que el control pase a v (prerrequisito), o si u se comunica con v por medio de parámetros, entonces existe una relación de dependencia de flujo entre u y v. Las dependencias de restricción representan restricciones en el flujo relativo del control entre un conjunto de actividades. Por ejemplo, si dos componentes u y v no pueden ejecutarse al mismo tiempo (son mutuamente excluyentes), entonces existe una relación de dependencia de restricción entre u y v.

Las dependencias compartidas y el flujo propuestos por Zhao son similares al concepto de acoplamiento estudiado en el capítulo 8. El acoplamiento es un importante concepto de diseño aplicable en el nivel arquitectónico y de componente. En el capítulo 23 se estudian criterios de medida sencillos para evaluar el acoplamiento.

9.5.3

Lenguajes de descripción arquitectónica

El arquitecto de una casa tiene un conjunto de herramientas y notación estandarizadas que permiten que el diseño se represente sin ambigüedades y que sea comprensible. Aunque el arquitecto de software dispone de la notación UML, para un enfoque más formal de la especificación del diseño arquitectónico se necesitan otras formas de diagramas y algunas herramientas relacionadas. El lenguaje de descripción arquitectónica (LDA) provee la semántica y sintaxis para describir una arquitectura de software. Hofmann et al. [Hof01] sugieren que un LDA debe brindar al diseñador la capacidad de desintegrar los componentes arquitectónicos, integrar componentes in-

H ERRAMIENTAS

DE SOFTWARE

Lenguajes de descripción arquitectónica El resumen siguiente de varios LDA importantes fue preparado por Richard Land (Lan02) y se publica con el permiso de su autor. Debe observarse que los primeros cinco LDA fueron desarrollados con fines de investigación y no son productos comerciales. Rapide (http://poset.stanford.edu/rapide/) construye a partir del concepto de conjuntos parcialmente ordenados, con lo que genera estructuras de programación muy nuevas (pero aparentemente poderosas). UniCon (www.cs.cmu.edu/~UniCon) es “un lenguaje de descripción arquitectónica que busca ayudar a los diseñadores a definir arquitecturas de software en términos de abstracciones que les parezcan útiles”. Aesop (www.cs.cmu.edu/~able/aesop/) aborda el problema de la reutilización del estilo. Con este lenguaje es posible definir estilos y usarlos cuando se construye un sistema real.


Wright (www.cs.cmu.edu/~able/wright/) es un lenguaje formal que incluye los elementos siguientes: componentes con puertos, conectores con roles y pegamento para unir roles con puertos. Los estilos arquitectónicos se formalizan en el lenguaje con predicados, lo que permite revisiones estáticas para determinar la consistencia y completitud de una arquitectura. Acme (www.cs.cmu.edu/~acme/) puede considerarse como un LDA de segunda generación, ya que su objetivo es identificar una clase de mínimo común denominador de los LDA. UML (www.uml.org/) incluye muchos de los artefactos necesarios para hacer descripciones arquitectónicas: procesos, nodos, perspectivas, etc. UML es apropiado para hacer descripciones informales tan sólo porque se trata de un estándar ampliamente comprendido. Sin embargo, carece de toda la fortaleza que se necesita para hacer una descripción arquitectónica adecuada.

14/1/10 15:44:40

C AP Í T UL O 9


225

dividuales en bloques arquitectónicos más grandes y representar las interfaces (mecanismos de conexión) que hay entre los componentes. Una vez establecidas las técnicas descriptivas basadas en lenguaje para el diseño de la arquitectura, es más probable que, a medida que el diseño evoluciona, se obtengan métodos de evaluación eficaces para las arquitecturas.

9. 6

MAPEO

DE LA ARQUITECTURA CON EL USO DEL FLUJO DE DATOS

Los estilos arquitectónicos analizados en la sección 9.3.1 representan arquitecturas radicalmente distintas. Por ello, no sorprende que no exista un mapeo exhaustivo que efectúe la transición del modelo de requerimientos a varios estilos de arquitectura. En realidad, no hay un mapeo práctico para ciertos estilos y el diseñador debe enfocar la traducción de los requerimientos a su diseño con el empleo de las técnicas descritas en la sección 9.4. Para ilustrar un enfoque al mapeo arquitectónico, considere la arquitectura denominada de llamada y regreso, estructura muy común para muchos tipos de sistemas. La arquitectura de llamada y regreso reside dentro de otras más sofisticadas que ya se analizaron en este capítulo. Por ejemplo, la arquitectura de uno o más componentes de una arquitectura cliente-servidor podría denominarse de llamada y regreso. Una técnica de mapeo llamada diseño estructurado [You79] se caracteriza con frecuencia como método de diseño orientado al flujo porque provee una transición conveniente de un diagrama de flujo de datos (véase el capítulo 7) a la arquitectura del software.7 La transición del flujo de la información (representada con el diagrama de flujo de datos o DFD) a estructura de programa se consigue como parte de un proceso de seis pasos: 1) se establece el tipo de flujo de información, 2) se indican las fronteras del flujo, 3) se mapea el DFD en la estructura del programa, 4) se define la jerarquía del control, 5) se refina la estructura resultante con el empleo de criterios de medición para el diseño y heurísticos, y 6) se mejora y elabora la descripción arquitectónica. Como ejemplo breve del mapeo de flujo de datos, se presenta uno de “transformación” paso a paso para una pequeña parte de la función de seguridad CasaSegura.8 Con objeto de realizar el mapeo, debe determinarse el tipo de flujo de la información. Un tipo de flujo de información se llama flujo de transformación si presenta una cualidad lineal. Los datos fluyen al sistema con una trayectoria de flujo de entrada en la que se transforman de una representación del mundo exterior a una forma internalizada. Una vez internalizados, se procesan en un centro de transformación. Por último, salen del sistema por una trayectoria de flujo de salida que transforma los datos a una forma del mundo exterior.9

9.6.1

Mapeo de transformación

El mapeo de transformación es un conjunto de pasos de diseño que permite mapear un DFD con características de flujo de transformación en un estilo arquitectónico específico. Para ilustrar este enfoque, de nuevo consideraremos la función de seguridad de CasaSegura.10 Un elemento del modelo de análisis es un conjunto de diagramas de flujo de datos que describen el flujo de información dentro de la función de seguridad. Para mapear estos diagramas de flujo de datos en una arquitectura de software deben darse los siguientes pasos de diseño:

7

Debe observarse que durante el método de mapeo también se utilizan otros elementos del modelo de requerimientos.

8 9

En el sitio web del libro se presenta un análisis más detallado del diseño estructurado. En este ejemplo no se considera otro tipo importante de flujo de información, pero se aborda en el ejemplo de diseño estructurado que se presenta en el sitio web del libro.

10 Sólo se considera la parte de la función de seguridad de CasaSegura que utiliza el panel de control. Aquí no se incluyen otras características analizadas en el libro.


14/1/10 15:44:40

226

PAR T E DOS

MO D E LADO

FIGURA 9.10 Diagrama de flujo de datos para la función de seguridad de CasaSegura

Panel de control

Comandos y datos de usuario

Software de CasaSegura

Estado de sensores

Sensores

Pantalla del panel de control

Despliegue de información Tipo de alarma

Alarma


Línea de teléfono

Paso 1. Revisión del modelo del sistema fundamental. El modelo del sistema fundamental o diagrama de contexto ilustra la función de seguridad como una transformación única, y representa a los productores y consumidores externos de los datos que fluyen hacia dentro y fuera de la función. La figura 9.10 ilustra un modelo de contexto de nivel 0, y la figura 9.11 muestra el flujo de datos refinado para la función de seguridad. CONSEJO

Si en este momento se mejora más el diagrama de flujo de datos, trate de obtener burbujas que presenten mucha cohesión.

Paso 2. Revisar y mejorar los diagramas de flujos de datos para el software. La información obtenida del modelo de requerimientos se refina para producir más detalles. Por ejemplo, se estudia el DFD de nivel 2 para vigilar sensores (véase la figura 9.12) y se obtiene el diagrama de flujo de datos de nivel 3 que se presenta en la figura 9.13. En el nivel 3, cada transformación en el diagrama de flujo de datos presenta una cohesión relativamente grande (consulte el capítulo 8). Es decir, el proceso implícito por una transformación realiza una sola y distintiva función que se implementa como componente en el software de CasaSegura. Entonces, el DFD de la figura 9.13 contiene detalles suficientes para hacer un “primer corte” en el diseño de la arquitectura del subsistema vigilar sensores, y se continúa con más refinamiento.

FIGURA 9.11 Diagrama de flujo de datos de nivel 1 para la función de seguridad de CasaSegura

Panel de control Comandos y datos de usuario Configurar el sistema Interactúa con el usuario Clave

Configurar solicitud Iniciar y detener

Procesar la clave

Sensores


Estado de sensores

Activar o desactivar el sistema

Mensaje de identificación válida Datos de configuración Vigilar sensores

Datos de configuración Información de configuración Datos de

Mensaje configuración de activar o desactivar

Mostrar mensajes y estado

Despliegue de información

Información de sensores Tipo de alarma Tonos del número telefónico

Pantalla del panel de control Alarma

Línea de telephone teléfono line

14/1/10 15:44:41

C AP Í T UL O 9

227


FIGURA 9.12 Diagrama de flujo de datos de nivel 2 que mejora la transformación vigilar sensores

Genera Identificación, señal tipo y ubicación de alarma de sensor Datos de Datos Evaluar configuración contra la pre- de alarma paración Número telefónico Identificación Leer y tipo de sensor Marcar sensores teléfono

Información de configuración

Estado de sensores

PU

Información de sensores

Formato para pantalla

Tipo de alarma


Paso 3. Determinar si el DFD tiene características de flujo de transformación o de

NT

O

CLAVE

Será frecuente encontrar varios tipos de flujo de datos dentro del mismo modelo orientado al flujo. Los flujos se dividen y la estructura del programa se obtiene con el uso del mapeo apropiado.

transacción.11

Al evaluar el DFD (véase la figura 9.13) se observa que los datos entran al

software por una trayectoria de ingreso y lo abandonan por tres trayectorias de salida. Por tanto, se adoptará una característica general de transformación para el flujo de la información. Paso 4. Aísle el centro de transformación, especificando las fronteras de entrada y salida del flujo. Los datos de entrada fluyen por una trayectoria en la que la información pasa de su forma externa a su forma interna; el flujo de salida convierte los datos internalizados a su forma externa. Las fronteras de los flujos de entrada y salida quedan abiertas a la interpretación.

FIGURA 9.13 Diagrama de flujo de datos de nivel 3 para vigilar sensores con fronteras del flujo

Información de configuración

Identificación, tipo y ubicación Datos de configuración formateados

Estado de sensores

Leer sensores

Identificación y preparación de sensores

Tipo de identificación del sensor, ubicación

Adquirir información de respuesta

Lista de números

Información del sensor

Formatear pantalla Generar señal de alarma

Tipo de alarma

Datos de alarma

Establecer condiciones de alarma

Código de condición de alarma, identificación del sensor, información de tiempo

Generar pantalla

Seleccionar número telefónico Número telefónico

Preparar la conexión a la red telefónica Generar Preparar pulsos hacia tonos del la línea número telefónico Tonos del número telefónico

11 En el flujo de transacción, un solo concepto de datos, llamado transacción, ocasiona que el flujo de datos se ramifique a través de cierto número de trayectorias definidas por la naturaleza de la transacción.


14/1/10 15:44:41

228

CONSEJO

En un esfuerzo por explorar estructuras alternativas para el programa, varíe las fronteras del flujo. Esto toma poco tiempo y da una perspectiva importante.

PAR T E DOS

MO D E LADO

Es decir, diferentes diseñadores tal vez seleccionen como ubicación de la frontera diferentes puntos en el flujo. De hecho, es posible obtener soluciones alternativas al diseño si se varía la colocación de las fronteras del flujo. Aunque debe tenerse cuidado al seleccionar las fronteras, la variación de una burbuja a lo largo de la trayectoria del flujo tendrá por lo general poco efecto en la estructura final del programa. Para el ejemplo, en la figura 9.13 se ilustran las fronteras del flujo como curvas sombreadas que corren de arriba abajo a través del flujo. Las transformaciones (burbujas) que constituyen el centro de transformación quedan dentro de esas dos fronteras sombreadas. Es posible dar argumentos para reajustar una frontera (por ejemplo, podría proponerse una frontera para el flujo de entrada que separara leer sensores de adquirir información de respuesta). En este diseño, el énfasis en esta etapa de diseño debe estar en la selección de fronteras razonables y no en la iteración extensa en la colocación de las divisiones. Paso 5. Realizar el “rediseño de primer nivel”. La arquitectura del programa obtenida con este mapeo da como resultado una distribución del control de arriba abajo. El rediseño lleva a una estructura de programa en la que los componentes de alto nivel ejecutan la toma de decisiones y los de bajo nivel realizan la mayor parte del trabajo de entrada, computación y salida. Los componentes de nivel medio llevan a cabo cierto control y moderan las cantidades de trabajo. Cuando se encuentra una transformación, se mapea un diagrama de flujo de datos para una estructura específica (una de llamar y regresar) que provea control para el procesamiento de información de entrada, transformación y salida. En la figura 9.14 se ilustra este rediseño de primer nivel para el subsistema vigilar sensores. Un controlador principal (llamado ejecutivo de vigilancia de sensores) reside en la parte superior de la estructura del programa y coordina las siguientes funciones de control subordinadas:

• Un controlador del procesamiento de la información de entrada, llamado controlador de entradas de los sensores, coordina la recepción de todos los datos que llegan.

• Un controlador del flujo de transformación, llamado controlador de condiciones de la alarma, supervisa todas las operaciones sobre los datos en forma internalizada (por ejemplo, un módulo que invoque varios procedimientos de transformación de datos.

FIGURA 9.14 Rediseño de primer nivel para vigilar sensores

Ejecutivo de vigilancia de sensores

Controlador de entradas de los sensores


Controlador de condiciones de alarma

Controlador de salidas de la alarma

14/1/10 15:44:41

C AP Í T UL O 9

CONSEJO

En esta etapa no se debe ser dogmático. Tal vez sea necesario establecer dos o más controladores para el procesamiento de las entradas o la computación, con base en la complejidad del sistema que se va a elaborar. Si el sentido común sugiere este enfoque, ¡adelante!

229


• Un controlador de procesamiento de información de salida, llamado controlador de salidas de la alarma, coordina la producción de información de salida. Aunque la figura 9.14 sugiere una estructura de tres dientes, los flujos complejos que hay en sistemas grandes tal vez requieran dos o más módulos de control para cada una de las funciones de control generales descritas con anterioridad. El número de módulos en el primer nivel debe limitarse al mínimo necesario para ejecutar las funciones de control y mantener buenas características de independencia de funciones. Paso 6. Realizar “rediseño de segundo nivel”.

El rediseño de segundo nivel se logra con

el mapeo de transformaciones individuales (burbujas) de un diagrama de flujo de datos en módulos apropiados dentro de la arquitectura. Se comienza en la frontera del centro de transformación y se avanza hacia afuera a lo largo de las trayectorias de entrada y salida; las transformaciones se mapean en niveles subordinados de la estructura del software. En la figura 9.15 CONSEJO

Hay que eliminar los módulos de control redundantes. Es decir, si un módulo de control no hace nada más que controlar a otro módulo, su función controladora debe llevarse a un módulo de nivel más alto.

se presenta el enfoque general del rediseño de segundo nivel. Aunque la figura 9.15 ilustra un mapeo uno a uno entre las transformaciones del diagrama de flujo y los módulos de software, es frecuente que haya distintos mapeos. Es posible combinar y representar dos o incluso tres burbujas como un solo componente, o una sola burbuja puede expandirse a dos o más componentes. Son consideraciones prácticas y mediciones de calidad del diseño las que dictan el resultado del rediseño de segundo nivel. La revisión y refinamiento tal vez produzcan cambios en esta estructura, pero sirven como diseño de “primera iteración”. El rediseño de segundo nivel para el flujo de entrada se presenta de la misma manera. El rediseño se logra de nuevo avanzando hacia afuera a partir de la frontera del centro de trans-

FIGURA 9.15 Rediseño de segundo nivel para vigilar sensores

Generar pantalla Formatear pantalla


Controlador de sensor de entradas

Preparar conexión a la red telefónica

Generar pulsos a Frontera del flujo la línea de transformación


Controlador de salida de la alarma

Formatear pantalla

Generar señal de alarma

Generar pantalla




Generar pulsos a la línea

14/1/10 15:44:41

230

PAR T E DOS

MO D E LADO

FIGURA 9.16


Estructura de primera iteración para vigilar sensores Controlador de sensor de entradas

Adquirir información de respuesta



Seleccionar número telefónico

Leer sensores

CONSEJO

Conserve módulos “trabajadores” en un nivel bajo de la estructura del programa. Esto llevará a una arquitectura fácil de mantener.

Controlador de salida de alarma

Formatear pantalla

Generar pantalla


Establecer conexión a la red telefónica


formación en el lado del flujo de entrada. El centro de transformación del software del subsistema vigilar sensores se mapea de modo un poco distinto. Cada conversión de datos o transformación de cálculo de la parte de transformación del diagrama de flujo de datos se mapea en un módulo subordinado al controlador de la transformación. En la figura 9.16 se presenta la arquitectura completa de primera iteración. Los componentes así mapeados que se aprecian en la figura 9.16 representan un diseño inicial de la arquitectura del software. Aunque los componentes reciben su nombre de manera que se implique la función, para cada uno debe escribirse una narración breve (adaptada de la especificación del proceso desarrollada para la transformación de datos y que se generó durante el modelado de los requerimientos). La narración describe la interfaz del componente, las estructuras internas de los datos, un relato de las funciones y el análisis breve de las restricciones y otros rasgos especiales (como los archivos de entrada y salida, características que dependen del hardware, requerimientos especiales de tiempo, etcétera). Paso 7. Refinar la arquitectura de primera iteración con el empleo de heurísticos

Cita: “Hacerlo tan sencillo como sea posible. Pero no más.” Albert Einstein

de diseño para mejorar la calidad del software.

Siempre es posible refinar la arquitectu-

ra de primera iteración, aplicando conceptos de independencia de funciones (véase el capítulo 8). Los componentes hacen explosión o implosión para producir un rediseño sensible, la separación de problemas, buena cohesión, acoplamiento mínimo y, lo más importante, una estructura que puede implementarse sin dificultad, probar sin confusión y mantener sin grandes problemas. Los refinamientos son impuestos por el análisis y los métodos de evaluación descritos en la sección 9.5, así como por consideraciones prácticas y el sentido común. Por ejemplo, hay ocasiones en las que el controlador para el flujo de datos de entrada es totalmente innecesario, cuando se requiere algún procesamiento de las entradas en un componente subordinado al controlador de la transformación, cuando no es posible evitar mucho acoplamiento debido a datos globales o cuando no se logran características estructurales óptimas. El arbitraje final lo constituyen los requerimientos del software acoplados con el criterio humano. El objetivo de los siete pasos anteriores es desarrollar una representación arquitectónica del software. Es decir, una vez definida la estructura, se evalúa y mejora considerándola como un todo. Las modificaciones que se hacen en este momento exigen poco trabajo adicional, pero tienen un efecto profundo en la calidad del software. Debe hacerse una pausa y considerar la diferencia entre el enfoque de diseño descrito y el proceso de “escribir programas”. Si el código es la única representación del software, usted y


14/1/10 15:44:42

C AP Í T UL O 9

231


C ASA S EGURA 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: ¿Como qué?

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.

Jamie: Bueno, ¿por qué usaste el componente controlador de sensores de entrada?

Ed (dibuja): Entonces, ¿esto es lo que piensas que debemos hacer?

Ed: Porque se necesita un controlador para el mapeo.

Jamie: Es un buen comienzo.

[Muestra a Jamie la figura 9.17.]

sus colegas tendrán grandes dificultades para evaluarlo o mejorarlo en un nivel global u holístico y, en verdad, tendrán dificultades porque “los árboles no los dejarán ver el bosque”.

9.6.2

?

¿Qué pasa después de que se generó la arquitectura?

Refinamiento del diseño arquitectónico

Cualquier análisis del refinamiento del diseño debería ir precedido de este comentario: “Recuerde que un ‘diseño óptimo’ que no funcione tiene un mérito cuestionable.” Debe ocuparse de desarrollar una representación del software que satisfaga todos los requerimientos funcionales y de desempeño, y darle mérito según sus mediciones y heurísticos de diseño. Debe estimularse el refinamiento de la arquitectura del software durante las primeras etapas del diseño. Como ya se dijo en este capítulo, hay estilos alternativos para la arquitectura que es posible obtener, refinar y evaluar en busca del “mejor” enfoque. Éste, dirigido a la optimización,

FIGURA 9.17


Estructura refinada del programa para vigilar sensores Adquirir información de respuesta

Leer sensores


Producir pantalla

Controlador de salida de la alarma





14/1/10 15:44:42

232

PAR T E DOS

MO D E LADO

es uno de los verdaderos beneficios que se logran con el desarrollo de una representación de la arquitectura del software. Es importante observar que la sencillez estructural con frecuencia refleja tanto elegancia como eficiencia. El refinamiento del diseño debe perseguir el menor número de componentes que sea consistente con la modularidad efectiva y la estructura de datos menos compleja que cumpla de modo adecuado con los requerimientos de información.

9. 7

RESUMEN La arquitectura del software proporciona una visión holística del sistema que se va a construir. Ilustra la estructura y organización de los componentes del software, sus propiedades y conexiones. Los componentes del software incluyen módulos de programa y las distintas representaciones de datos que manipula éste. Por tanto, el diseño de los datos es parte integral de la generación de la arquitectura del software. Ésta subraya las primeras decisiones respecto del diseño y provee un mecanismo para considerar los beneficios de las estructuras alternativas para el sistema. Dentro de un género arquitectónico dado, hay varios estilos y patrones diferentes disponibles para el ingeniero de software. Cada estilo describe una categoría de sistemas que agrupa un conjunto de componentes que realizan una función requerida por el sistema; un grupo de conectores que permiten comunicación, coordinación y cooperación entre los componentes; restricciones que definen cómo pueden integrarse éstos para formar el sistema y modelos semánticos que permiten que un diseñador entienda las propiedades generales del sistema. En un sentido general, el diseño arquitectónico se obtiene con el empleo de cuatro pasos. En primer lugar, el sistema debe representarse en contexto. Es decir, el diseñador debe definir las entidades externas con las que interactúa el software y la naturaleza de la interacción. Una vez especificado el contexto, el diseñador debe identificar un conjunto de abstracciones de alto nivel, llamadas arquetipos, que representan elementos fundamentales del comportamiento o función del sistema. Ya que se definieron las abstracciones, el diseño comienza a avanzar cerca del dominio de la implementación. Se identifican los componentes y se representan dentro del contexto de una arquitectura que les da apoyo. Por último, se desarrollan instancias específicas de la arquitectura para “probar” el diseño en el contexto del mundo real. Como ejemplo sencillo del diseño arquitectónico, el método del mapeo presentado en este capítulo usa las características del flujo de datos para obtener un estilo arquitectónico de uso muy común. El diagrama de flujo de datos se mapea en la estructura del programa con el uso del enfoque del mapeo de la transformación. Éste se aplica a un flujo de información que presente fronteras distintas entre los datos de entrada y los de salida. El diagrama de flujo de datos se mapea en una estructura que asigna el control a la entrada, al procesamiento y a la salida junto con tres jerarquías de módulos diseñados por separado. Una vez que se tiene la arquitectura, se elabora y analiza mediante criterios de calidad.

PROBLEMAS


9.1. Con el uso de la arquitectura de una casa o edificio como metáfora, establezca comparaciones con la arquitectura del software. ¿En qué se parecen las disciplinas de la arquitectura clásica y la del software? ¿En qué difieren? 9.2. Diga dos o tres ejemplos de aplicaciones para cada uno de los estilos arquitectónicos mencionados en la sección 9.3.1. 9.3. Algunos de los estilos arquitectónicos citados en la sección 9.3.1 tienen naturaleza jerárquica, mientras que otros no. Elabore una lista de cada tipo. ¿Cómo se implementarían los estilos arquitectónicos que no son jerárquicos?


14/1/10 15:44:42

C AP Í T UL O 9


233

9.4. Los términos estilo arquitectónico, patrón arquitectónico y marco (que no se estudia en este libro) surgen con frecuencia en los análisis de la arquitectura del software. Investigue y describa en qué difiere cada uno de ellos de los demás. 9.5. Seleccione una aplicación con la que esté familiarizado. Responda cada una de las preguntas planteadas para el control y los datos de la sección 9.3.3. 9.6. Investige el ATAM (en [Kaz98]) y presente un análisis detallado de los seis pasos presentados en la sección 9.5.1. 9.7. Si no lo ha hecho, termine el problema 6.6. Use los métodos de diseño descritos en este capítulo para desarrollar una arquitectura del software para el SSRB. 9.8. Utilice un diagrama de flujo y una narración del procesamiento para describir un sistema basado en computadora que tenga distintas características de transformación del flujo. Defina las fronteras del sistema y mapee el diagrama de flujo de los datos en una arquitectura del software con el empleo de la técnica descrita en la sección 9.6.1.

LECTURAS


La bibliografía sobre arquitectura del software ha crecido mucho en la última década. Los libros escritos por Gorton (Essential Software Architecture, Springer, 2006), Reekie y McAdam (A Software Architecture Primer, Angophora Press, 2006), Albin (The Art of Software Architecture, Wiley, 2003) y Bass et al. (Software Architecture in Practice, 2a. ed., Addison-Wesley, 2002), presentan introducciones útiles a un área del conocimiento con muchos retos intelectuales. Buschman et al. (Pattern-Oriented Software Architecture, Wiley, 2007) y Kuchana (Software Architecture Design Patterns in Java, Auerbach, 2004) estudian aspectos orientados al patrón del diseño arquitectónico. Rozanski y Woods (Software Systems Architecture, Addison-Wesley, 2005), Fowler (Patterns of Enterprise Application Architecture, Addison-Wesley, 2003), Clements et al. (Documenting Software Architecture: View and Beyond, Addison-Wesley, 2002), Bosch [Bos00] y Hofmeister et al. [Hof00] hacen análisis profundos de la arquitectura del software. Hennesey y Patterson (Computer Architecture, 4a. ed., Morgan-Kaufmann, 2007) adoptan un punto de vista notable, por ser cuantitativo, para los aspectos del diseño de la arquitectura del software. Clements et al. (Evaluating Software Architectures, Addison-Wesley, 2002) analizan los aspectos asociados con la evaluación de alternativas arquitectónicas y la selección de la mejor arquitectura para un dominio dado de problemas. Los libros dedicados a la implementación sobre la arquitectura abordan el diseño arquitectónico dentro de un ambiente o tecnología específicos de desarrollo. Marks y Bell (Sevice-Oriented Architecture, Wiley, 2006) estudian el enfoque de diseño que relaciona los negocios y los recursos computacionales con los requerimientos definidos por los clientes. Stahl et al. (Model-Driven Software Development, Wiley, 2006) analizan la arquitectura dentro del contexto de los enfoques de modelado dirigidos al dominio. Radaideh y Al-Ameed (Architecture of Reliable Web Applications Software, GI Global, 2007) consideran arquitecturas apropiadas para webapps. Clements y Norhrop (Software Product Lines: Practices and Patterns, Addison-Wesley, 2001) estudian el diseño de arquitecturas que dan apoyo a líneas de productos de software. Shanley (Protected Mode Software Architecture, Addison-Wesley, 1996) proporciona una guía del diseño arquitectónico para cualquier persona que diseñe sistemas basados en PC que operen en tiempo real, o para sistemas operativos de tareas múltiples o manejadores de dispositivos. La investigación actual sobre arquitectura del software se documenta cada año en Proceedings of the International Workshop on Software Architecture, publicación patrocinada por ACM y otras organizaciones de cómputo, y en Proceedings of the International Conference on Software Engineering. En internet se encuentra una amplia variedad de fuentes de información sobre el diseño arquitectónico. En el sitio web del libro, www.mhhe.com/engcs/compsci/pressman/professional/olc/ser.htm, se halla una lista actualizada de referencias que hay en la red mundial, relevantes para el diseño de la arquitectura.


14/1/10 15:44:42

CAPÍTULO

10 CONCEPTOS

DISEÑO

EN EL NIVEL

DE COMPONENTES

CLAVE

acoplamiento . . . . . . . . . . . 244 cohesión . . . . . . . . . . . . . . . 243

l diseño en el nivel de componentes tiene lugar una vez terminado el diseño de la arqui-

E

tectura. En esta etapa se ha establecido la estructura general de los datos y del programa del software. El objetivo es traducir el modelo del diseño a software operativo. Pero el

componentes adaptación . . . . . . . . . . . 258 calificación . . . . . . . . . . . 257 clasificación . . . . . . . . . . 260 combinación . . . . . . . . . . 259 orientación a objetos . . . . . . . . . . . . 235 tradicional . . . . . . . . . . . 252 webapp . . . . . . . . . . . . . 251

nivel de abstracción del modelo de diseño existente es relativamente alto y el del programa

desarrollo basado en componentes . . . . . . . . . 256

encontrar un medio para evitar de inicio la mayoría de los posibles errores; como resultado, el proceso

diseño del contenido . . . . . . 251

depurando errores: no deben introducirlos al arrancar.

operativo es bajo. La traducción es difícil y está abierta a la introducción de errores sutiles que son difíciles de detectar y de corregir en las etapas posteriores del proceso del software. En una conferencia famosa, Edsgar Dijkstra, investigador importante que ha contribuido mucho a nuestra comprensión del diseño de software, dijo [Dij72]: El software parece ser diferente de muchos otros productos en los que la regla es que a mejor calidad se da un mayor precio. Aquellos que desean un software en verdad confiable descubrirán que deben de programación se hace más barato [...] los programadores eficaces no tienen que perder su tiempo

ingeniería del dominio . . . . . 257 lineamientos de diseño . . . . 242 notación del diseño tabular . . . . . . . . . . . . . . . . 254

Aunque estas palabras fueron expresadas hace muchos años, siguen siendo ciertas. Al traducir el modelo del diseño a código fuente, deben seguirse principios de diseño que no sólo hagan la traducción sino que también eviten la “introducción de errores desde el principio”. Es posible representar el diseño en el nivel del componente con el uso de un lenguaje de programación. En esencia, el programa se crea con el empleo del modelo de diseño arquitectónico como guía. Un enfoque alternativo consiste en representar el diseño en el nivel de los componentes con alguna representación intermedia (gráfica, tabular o basada en texto) que se traduzca con facilidad a código fuente. Sin que importe el mecanismo utilizado para representar

UNA ¿Qué es? Durante el diseño arquitectónico, se define un conjunto completo de componentes RÁPIDA de software. Pero las estructuras internas de datos y detalles de procesamiento de cada componente no están representadas en un nivel de abstracción cercano al código. El diseño en el nivel de componentes define las estructuras de datos, algoritmos, características de la interfaz y mecanismos de comunicación asignados a cada componente del software. ¿Quién lo hace? Un ingeniero de software es quien realiza el diseño en el nivel de componentes. ¿Por qué es importante? Antes de elaborar el software, se tiene que ser capaz de determinar si funcionará. El diseño en el nivel de componentes lo representa en forma tal que permite revisar los detalles del diseño para garantizar su corrección y su consistencia con otras representaciones del diseño (por ejemplo, los datos y el diseño de la arquitectura y la interfaz). Esto proporciona un medio para evaluar si funcionarán las estructuras de datos, interfaces y algoritmos. ¿Cuáles son los pasos? Las representaciones de diseño de datos, arquitectura e interfaces constituyen el funda-

MIRADA

mento para el diseño en el nivel de componentes. La definición de clase o narrativa de procesamiento de cada componente se traduce a un diseño detallado que utiliza formas de diagrama o basadas en texto que especifican las estructuras de datos internas, los detalles de la interfaz local y la lógica del procesamiento. La notación del diseño incluye diagramas UML y formatos complementarios. Se especifica el diseño del procedimiento con el empleo de construcciones de programación estructurada. Con frecuencia es posible obtener componentes de software reutilizable ya existentes, en lugar de construir nuevos. ¿Cuál es el producto final? El producto principal que se genera en esta etapa es el diseño de cada componente, representado con notación gráfica, tabular o basada en texto. ¿Cómo me aseguro de que lo hice bien? Se efectúa la revisión del diseño. Esto se hace para determinar durante las primeras etapas de diseño si las estructuras de datos, interfaces, secuencias de procesamiento y condiciones lógicas son correctas y si producirán los datos apropiados o la transformación del control asignado al componente.

234


26/1/10 17:33:16

C AP Í T UL O 10

DISEÑO EN EL NIV EL DE COMPONENT ES

235

a éste, las estructuras de datos, interfaces y algoritmos definidos deben apegarse a varios lineamientos de diseño bien establecidos que ayudan a evitar los errores conforme evoluciona el diseño del procedimiento. En este capítulo se estudian estos lineamientos y los métodos disponibles para cumplirlos.

10. 1

¿QUÉ

ES UN COMPONENTE?

Un componente es un bloque de construcción de software de cómputo. Con más formalidad, la

Cita: “Los detalles no son detalles. Son el diseño.” Charles Eames

Especificación OMG del Lenguaje de Modelado Unificado [OMG03a] define un componente como “una parte modular, desplegable y sustituible de un sistema, que incluye la implantación y expone un conjunto de interfaces”. Como se dijo en el capítulo 9, los componentes forman la arquitectura del software y, en consecuencia, juegan un papel en el logro de los objetivos y de los requerimientos del sistema que se va a construir. Como los componentes se encuentran en la arquitectura del software, deben comunicarse y colaborar con otros componentes y con entidades (otros sistemas, dispositivos, personas, etc.) que existen fuera de las fronteras del software. El verdadero significado del término componente difiere en función del punto de vista del ingeniero de software que lo use. En las secciones que siguen, se estudian tres visiones importantes de lo que es un componente y cómo se emplea en el desarrollo de la modelación del diseño.

10.1.1 PU

Una visión orientada a objetos

En el contexto de la ingeniería de software orientada a objetos, un componente contiene un

NT

O

CLAVE

Desde un punto de vista orientado a objetos, un componente es un conjunto de clases que colaboran.

conjunto de clases que colaboran.1 Cada clase dentro de un componente se elabora por completo para que incluya todos los atributos y operaciones relevantes para su implantación. Como parte de la elaboración del diseño, también deben definirse todas las interfaces que permiten que las clases se comuniquen y colaboren con otras clases de diseño. Para lograr esto, se comienza con el modelo de requerimientos y se elaboran clases de análisis (para los componentes que se relacionan con el dominio del problema) y clases de infraestructura (para los componentes que dan servicios de apoyo para el dominio del problema). Para ilustrar el proceso de la elaboración del diseño, considere el software que se va a elaborar para un taller de impresión avanzada. El objetivo general del software es obtener los requerimientos que plantea el cliente en el mostrador, presupuestar un trabajo de impresión y después pasar éste a una instalación automatizada de producción. Durante la ingeniería de requerimientos se obtuvo una clase de análisis llamada ImprimirTrabajo. En la parte superior de la figura 10.1 aparecen los atributos y operaciones definidos durante el análisis. En el diseño de la arquitectura se definió ImprimirTrabajo como un componente dentro de la arquitec-

CONSEJO

Recuerde que el modelado del análisis y del diseño son acciones iterativas. Es probable que la elaboración de la clase de análisis original requiera de etapas adicionales, que con frecuencia van seguidas de etapas de modelado del diseño que representan la clase de diseño elaborada (los detalles del componente).


tura del software y está representado con la notación abreviada UML2 que se muestra en la parte media derecha de la figura. Observe que ImprimirTrabajo tiene dos interfaces, CalcularTrabajo, que provee la capacidad de obtener el costo del trabajo, e IniciarTrabajo, que pasa el trabajo a través de las instalaciones de producción. Éstas se encuentran representadas con los símbolos de “paleta” que aparecen en el lado izquierdo de la caja del componente. El diseño en el nivel del componente comienza en este punto. Deben elaborarse los detalles del componente ImprimirTrabajo para que den información suficiente que guíe la implantación. La clase de análisis original se lleva a cabo para dar cuerpo a todos los atributos y operaciones requeridos para implantar la clase así como el componente ImprimirTrabajo. En la parte inferior derecha de la figura 10.1, la clase de diseño elaborada ImprimirTrabajo contiene

1

En ciertos casos, un componente contiene una sola clase.

2

Los lectores que no estén familiarizados con la notación UML deben consultar el apéndice 1.

26/1/10 17:33:17

236

PAR T E DOS

MO D E LADO

FIGURA 10.1 Clase de análisis

Elaboración de un componente de diseño

ImprimirTrabajo NúmerodePáginas NúmerodeLados TipodePapel Escala CaracterísticasdeProducción CalcularCostodelTrabajo( ) PasarTrabajoaImpresora( )

Componente de diseño

CalcularTrabajo

ImprimirTrabajo

IniciarTrabajo

<> CalcularTrabajo CalcularCostoporPágina( ) CalcularCostodePapel( ) CalcularCostodeProducción( )

<> IniciarTrabajo CalcularCostoTotaldelTrabajo( ) ElaborarOrdendeTrabajo( ) VerificarPrioridad( ) PasarTrabajoaProducción( )

Clase de diseño elaborada ImprimirTrabajo NúmerodePáginas NúmerodeLados TipodePapel PesodelPapel TamañodelPapel ColordelPapel Escala Ampliación RequerimientosdeColor CaracterísticasdeProducción OpcionesdeRecopilación OpcionesdeVinculación InventariodeCubiertas Extracción Prioridad CostoTotaldelTrabajo NúmeroWO CalcularCostoporPágina( ) CalcularCostodelPapel( ) CalcularCostodeProducción( ) CalcularCostoTotaldelTrabajo( ) ElaborarOrdendeTrabajo( ) VerificarPrioridad( ) PasarTrabajoaProducción( )

información más detallada de los atributos, así como una descripción amplia de las operaciones que se necesitan para implantar el componente. Las interfaces CalcularTrabajo e IniciarTrabajo implican comunicación y colaboración con otros componentes (que no se muestran). Por ejemplo, la operación CalcularCostoporPágina ( ) (que forma parte de la interfaz CalcularTrabajo) podría colaborar con un componente llamado TabladeValuación que contuviera información sobre los precios del trabajo. La operación VerificarPrioridad ( ) (parte de la interfaz IniciarTrabajo) quizá colabore con un componente de nombre FiladeTrabajos para determinar los tipos y prioridades de trabajos que están en espera de su producción. Esta actividad de elaboración se aplica a cada componente definido como parte del diseño de la arquitectura. Una vez concluida, se aplica más elaboración a cada atributo, operación e interfaz. Deben especificarse las estructuras de datos apropiadas para cada atributo. Además, se diseñan los detalles algorítmicos requeridos para implantar la lógica del procesamiento asociada con cada operación. Este diseño del procedimiento se analiza más adelante, en este capítulo. Por último, se diseñan los mecanismos requeridos para implantar la interfaz. Para el software orientado a objetos, esto incluye la descripción de todos los mensajes que se requieren para efectuar la comunicación dentro del sistema.

10.1.2

La visión tradicional

En el contexto de la ingeniería de software tradicional, un componente es un elemento funcional de un programa que incorpora la lógica del procesamiento, las estructuras de datos internas que


26/1/10 17:33:17

C AP Í T UL O 10

237


se requieren para implantar la lógica del procesamiento y una interfaz que permite la invocación

Cita: “Invariablemente se observa que un sistema complejo que funciona ha evolucionado a partir de un sistema sencillo que funcionaba.” John Gall

del componente y el paso de los datos. Dentro de la arquitectura del software se encuentra un componente tradicional, también llamado módulo, que tiene tres funciones importantes: 1) como componente de control que coordina la invocación de todos los demás componentes del dominio del problema, 2) como componente del dominio del problema que implanta una función completa o parcial que requiere el cliente y 3) como componente de infraestructura que es responsable de las funciones que dan apoyo al procesamiento requerido en el dominio del problema. Igual que los componentes orientados a objetos, los componentes tradicionales del software provienen del modelo de análisis. Sin embargo, en este caso, el elemento de datos orientado al flujo del modelo de análisis sirve de base para su obtención. Cada transformación (burbuja) representada en los niveles más bajos del diagrama de flujo de datos se mapea (véase la sección 9.6) en una jerarquía de módulos. Cerca de la parte superior de la jerarquía (arquitectura del programa) se hallan los componentes del control (módulos) y hacia la parte inferior de ella tienden a encontrarse los del dominio del problema. Para lograr una modularidad efectiva, cuando se elaboran los componentes se aplican conceptos de diseño, como la independencia de funciones (véase el capítulo 8). Para ilustrar este proceso de elaboración del diseño de componentes tradicionales, considere otra vez el software que debe elaborarse para un taller de impresión avanzada. Durante el modelado de los requerimientos se obtendrá un conjunto de diagramas de flujo de datos. Suponga que éstos se mapean en la arquitectura que se aprecia en la figura 10.2. Cada rectángulo representa un componente del software. Observe que los que están sombreados son equivalentes en su función y operaciones a los definidos para la clase ImprimirTrabajo que se analizó en la sección 10.1.1. Sin embargo, en este caso, cada operación se representa como módulo aislado que se invoca como se indica en la figura. Para controlar el procesamiento se utilizan otros módulos, por lo que son componentes de control. Cada módulo de la figura 10.2 se elabora durante el diseño en el nivel de componentes. La interfaz del módulo se define explícitamente. Es decir, se representa todo objeto de datos o

FIGURA 10.2 Sistema de administración del trabajo

Gráfica de la estructura de un sistema tradicional

Leer datos del trabajo de impresión

Desarrollar el costo del trabajo

Calcular costo por página


Calcular el costo del papel

Seleccionar función de administración del trabajo

Elaborar orden de trabajo

Calcular el costo de producción

Enviar el trabajo a producción

Verificar prioridad

Pasar el trabajo a producción

26/1/10 17:33:17

238

PAR T E DOS

MO D E LADO

control que fluya a través de la interfaz. Se definen las estructuras de datos que se utilicen en el

CONSEJO

interior del módulo. El algoritmo que permite que el módulo cumpla su función prevista se di-

Conforme se elabora el diseño para cada componente del software, la atención pasa al diseño de estructuras de datos específicas y al diseño del procedimiento para manipularlas. Sin embargo, no hay que olvidar la arquitectura que debe albergar los componentes o las estructuras de datos globales que den servicio a muchos componentes.

seña con el empleo del enfoque de refinamiento por etapas que se estudió en el capítulo 8. El comportamiento del módulo se representa en ocasiones con un diagrama de estado. Para ilustrar este proceso, considere el módulo CalcularCostoporPágina. El objetivo de este módulo es calcular el costo de impresión por página con base en las especificaciones dadas por el cliente. Los datos requeridos para realizar esta función son: número de páginas en el documento, número total de documentos que se va a producir, impresión por uno o dos lados, requerimientos de color y requerimientos de tamaño. Estos datos se pasan a CalcularCostoporPágina a través de la interfaz del mó-

dulo. CalcularCostoporPágina usa estos datos para determinar el costo por página con base en el tamaño y complejidad del trabajo, que es función de todos los datos proporcionados al módulo a través de la interfaz. El costo por página es inversamente proporcional al tamaño del trabajo y directamente proporcional a su complejidad. La figura 10.3 representa el diseño en el nivel de componentes con el uso de notación UML modificada. El módulo CalcularCostoporPágina accede a los datos invocando el módulo ObtenerDatosdelTrabajo, que permite que todos los datos relevantes pasen al componente, y una interfaz de base de datos, AccederBDdeCostos, que permite que el módulo acceda a una base de datos que contiene todos los costos de impresión. A medida que avanza el diseño, se elabora el módulo CalcularCostoporPágina para que provea los detalles del algoritmo y de la interfaz (véase la figura 10.3). Los detalles del algoritmo se representan con el uso del texto de seudocódigo que aparece en la figura, o con un diagrama de actividades UML. Las interfaces se representan como una colección de objetos de datos o conceptos de entrada y salida. La elaboración del diseño continúa hasta que haya detalles suficientes que guíen la construcción del componente.

FIGURA 10.3

ObtenerDatosdelTrabajo

Diseño en el nivel de componentes para CalcularCostopor Página

Componente del diseño

CalcularCostoporPágina

AccederaBDdeCostos Módulo elaborado

CostoporPágina entra: NúmerodePáginas entra: NúmerodeDocumentos entra: lados = 1, 2 entra: color = 1, 2, 3, 4 entra: tamaño de página = A, B, C, D sale: costo de página entra: tamaño del trabajo entra: color = 1, 2, 3, 4 entra: TamañodePágina = A, B, C, D sale: costo base por página (CBP) sale: factor de tamaño (FT) ObtenerDatosdelTrabajo (NúmerodePáginas, NúmerodeDocumentos, lados, color, TamañodePágina, CostoporPágina) AccederaBDdeCostos (TamañodelTrabajo, color, TamañodePágina, CBP, FT) CalcularCostoporPágina( )


tamaño del trabajo (TT) = NúmerodePáginas*NúmerodeDocumentos; buscar costo base por página (CBP) -> AccederaBDdeCostos (TT, color); buscar factor de tamaño (FT) -> AccederaBDde costos (TT, color, tamaño) factor de complejidad del trabajo (FCT) = 1 + [(lados-1)*CostoporLado+FT CostoporPágina= CBP*FCT

26/1/10 17:33:17

C AP Í T UL O 10

10.1.3

239


Visión relacionada con el proceso

La visión orientada a objetos y la tradicional del diseño en el nivel de componentes, presentadas en las secciones 10.1.1 y 10.1.2, suponen que el componente se diseña desde la nada. Es decir, que se crea un nuevo componente con base en las especificaciones obtenidas del modelo de requerimientos. Por supuesto, existe otro enfoque. En las últimas dos décadas, la comunidad de la ingeniería de software ha puesto el énfasis en la necesidad de elaborar sistemas que utilicen componentes de software o patrones de diseño ya existentes. En esencia, a medida que avanza el trabajo de diseño se dispone de un catálogo de diseño probado o de componentes en el nivel de código. Conforme se desarrolla la arquitectura del software, se escogen del catálogo componentes o patrones de diseño y se usan para construir la arquitectura. Como estos componentes fueron construidos teniendo en mente lo reutilizable, se dispone totalmente de la descripción de su interfaz, de las funciones que realizan y de la comunicación y colaboración que requieren. En la sección 10.6 se estudian algunos aspectos importantes de la ingeniería de software basada en componentes.

I NFOR MACIÓN Estándares y marcos basados en componentes Uno de los elementos clave que conducen al éxito o fracaso de la ingeniería de estándares basados en componentes es su disponibilidad, que en ocasiones recibe el nombre de middleware. El middleware es una colección de componentes de infraestructura que permiten que los componentes del dominio del problema se comuniquen entre sí a través de una red o dentro de un sistema complejo. Los ingenieros de software que deseen usar el desarrollo basado en componentes como proceso de software pueden elegir entre los estándares siguientes:

10. 2

DISEÑO

OMG CORBA-www.corba.org/ Microsoft COM-www.microsoft.com/com/tech/complus. asp Microsoft.NET-http://msdn2.microsoft.com/en-us/ netframework/default.aspx Sun JavaBeans-http://java.sun.com/products/ejb/ Estos sitios web tienen una amplia variedad de métodos de enseñanza, documentos en limpio, herramientas y recursos generados con dichos estándares importantes de middleware.

DE COMPONENTES BASADOS EN CLASE

Como ya se dijo, el diseño en el nivel de componentes se basa en la información desarrollada como parte del modelo de requerimientos (capítulos 6 y 7) y se representa como parte del modelo arquitectónico (véase el capítulo 9). Cuando se escoge un enfoque de ingeniería orientado al software, el diseño en el nivel de componentes se centra en la elaboración de clases específicas del dominio del problema y en el refinamiento de las clases de infraestructura contenidas en el modelo de requerimientos. La descripción detallada de los atributos, operaciones e interfaces que emplean dichas clases es el detalle de diseño que se requiere como precursor de la actividad de construcción.

10.2.1

Principios básicos del diseño

Hay cuatro principios básicos que son aplicables al diseño en el nivel de componentes y que han sido ampliamente aceptados para la aplicación de la ingeniería de software orientada a objetos. La motivación subyacente para aplicar estos principios es crear diseños que sean más factibles de cambiar, así como reducir la propagación de efectos colaterales cuando se hagan cambios. Estos principios pueden usarse como guía cuando se desarrolle cada componente del software. Principio Abierto-Cerrado (PAC).

“Un módulo [componente] debe ser abierto para la exten-

sión pero cerrado para la modificación” [Mar00]. Este enunciado parece ser una contradicción, pero representa una de las características más importantes de un buen diseño en el nivel de


26/1/10 17:33:18

240

PAR T E DOS

MO D E LADO

FIGURA 10.4 <> Sensor leer( ) activar( ) desactivar( ) probar( )

Seguimiento del PAC

Ventana/ SensordePuerta

Detector

SensordeHumo

Detectorde Movimiento

SensordeCalor

SensordeCO2

componentes. Dicho en pocas palabras, debe especificarse el componente en forma tal que permita extenderlo (dentro del dominio funcional a que está dirigido) sin necesidad de hacerle modificaciones internas (en el nivel del código o de la lógica). Para lograr esto, se crean abstracciones que sirven como búfer entre la funcionalidad que sea probable extender y la clase de diseño en sí. Por ejemplo, suponga que la función de seguridad CasaSegura utiliza la clase Detector que debe revisar el estado de cada tipo de sensor de seguridad. Es probable que, conforme pase el tiempo, crezca el número y tipos de sensores de seguridad. Si la lógica de procesamiento interno se implementa como una secuencia de comandos si-entonces-en otro caso, cada uno dirigido a un tipo diferente de sensor, cuando se agregue uno nuevo se requerirá una lógica de procesamiento interno adicional (otro si-entonces-en otro caso). Esto sería una violación del PAC.

C ASA S EGURA 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.

Vinod: No, no. Doug quiere saber cuánto tiempo nos llevaría agregar eso a la función de seguridad.

Shakira (con sonrisa cómplice): No otra vez, por favor…

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: Sí… y no vas a creer con lo que salieron…

Vinod: Entonces diré a Doug que no hay problema.

Shakira: Sorpréndeme.

Shakira: Conociendo a Doug, nos estará vigilando; yo no le daría el asunto del perrito hasta la siguiente entrega.

La conversación: Vinod: Me acaba de llamar Doug [gerente del equipo]. Dice que mercadotecnia quiere agregar un nuevo sensor.

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 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.

26/1/10 17:33:18

C AP Í T UL O 10


241

En la figura 10.4 se ilustra una forma de seguir el PAC para la clase Detector. La interfaz sensor presenta una consistente visión de los componentes sensores para los detectores. Si se agregara un nuevo tipo de sensor, no se requeriría hacer ningún cambio para la clase Detector (componente). Se preservaría el PAC. Principio de sustitución de Liskov (PSL). “Las subclases deben ser sustituibles por sus clases de base” [Mar00]. Este principio de diseño, originalmente propuesto por Barbara Liskov [Lis88], sugiere que un componente que use una clase de base debe funcionar bien si una clase derivada de la clase base pasa al componente. El PSL demanda que cualquier clase derivada de una clase de base debe respetar cualquier contrato implícito entre la clase de base y los componentes que la usan. En el contexto de este análisis, un “contrato” es una precondición que debe ser verdadera antes de que el componente use una clase de base y una poscondición que debe ser verdadera después de ello. Cuando se crean clases derivadas hay que asegurarse de que respeten la precondición y la poscondición. CONSEJO

Si omite el diseño y pasa al código, sólo recuerde que el diseño es la última “concreción”. Estaría violando el PID.

Principio de Inversión de la Dependencia (PID). “Dependa de las abstracciones. No dependa de las concreciones” [Mar00]. Como se vio en el estudio del PAC, las abstracciones son el lugar en el que es posible ampliar un diseño sin muchas dificultades. Entre más dependa un componente de otros componentes concretos (y no de abstracciones tales como una interfaz), más difícil será ampliarlo. Principio de segregación de la interfaz (PSI). “Es mejor tener muchas interfaces específicas del cliente que una sola de propósito general” [Mar00]. Hay muchas instancias en las que múltiples componentes del cliente usan las operaciones que provee una clase servidor. El PSI sugiere que debe crearse una interfaz especializada que atienda a cada categoría principal de clientes. En la interfaz de ese cliente, sólo deben especificarse aquellas operaciones que sean relevantes para una categoría particular de clientes. Por ejemplo, considere la clase PlanodelaCasa que se usó en las funciones de seguridad y vigilancia de CasaSegura (véase el capítulo 6). Para las funciones de seguridad, PlanodelaCasa se utiliza sólo durante las actividades de configuración y emplea las operaciones SituarDispositivo( ), MostrarDispositivo( ), AgruparDispositivo( ) y QuitarDispositivo( ) para situar, mostrar, agrupar y quitar sensores del plano de la casa. La función de vigilancia de CasaSegura usa las cuatro operaciones mencionadas para la seguridad, pero también requiere operaciones especiales para administrar cámaras: MostrarFOV( ) y MostrarIdentificacióndeDispositivo( ). Entonces, el PSI sugiere que los componentes cliente de las dos funciones de CasaSegura tienen interfaces especializadas definidas para ellas. La interfaz para la seguridad incluiría sólo las operaciones SituarDispositivo( ), MostrarDispositivo( ), AgruparDispositivo( ) y QuitarDispositivo( ). La interfaz para vigilancia incorporaría esas mismas operaciones pero también MostrarFOV( ) y MostrarIdentificacióndeDispositivo( ). Aunque los principios de diseño en el nivel de componentes son una guía útil, los componentes no existen en el vacío. En muchos casos, los componentes o clases individuales están organizados en subsistemas o paquetes. Es razonable preguntar cómo debe ocurrir esta actividad de agrupamiento. ¿Exactamente cómo deben organizarse los componentes conforme avanza el diseño? Martin [Mar00] propone principios adicionales de agrupamiento que son aplicables al

PU

NT

diseño en el nivel de componentes:

CLAVE

Principio de equivalencia de la liberación de la reutilización (PER). “El gránulo de reuti-

O

Para que los componentes sean reutilizables, su diseño requiere algo más que un buen diseño técnico. También exige mecanismos efectivos de configuración (véase el capítulo 22).


lización es el gránulo de liberación” [Mar00]. Cuando las clases o componentes se diseñan para ser reutilizables, existe un contrato implícito que se establece entre el desarrollador de la entidad reutilizable y las personas que la emplearán. El desarrollador se compromete a establecer un sistema que controle la liberación para que dé apoyo y mantenimiento a las versiones anteriores de la entidad mientras los usuarios se actualizan poco a poco con la versión más nueva.

26/1/10 17:33:18

242

PAR T E DOS

MO D E LADO

En lugar de abordar cada clase individual, es frecuente que sea mejor agrupar las que sean reutilizables en paquetes que puedan manejarse y controlar a medida que evolucionen las nuevas versiones. Principio de cierre común (PCC). “Las clases que cambian juntas pertenecen a lo mismo” [Mar00]. Las clases deben empacarse en forma cohesiva. Es decir, cuando las clases se agrupan como parte de un diseño, deben estar dirigidas a la misma área de funciones o comportamiento. Cuando deba cambiar alguna característica de dicha área, es probable que sólo aquellas clases que haya dentro del paquete requieran modificación. Esto lleva a un control de cambios y a un manejo de la liberación más eficaces. Principio de la reutilización común (PRC). “Las clases que no se reutilizan juntas no deben agruparse juntas” [Mar00]. Cuando cambia una o más clases dentro de un paquete, cambia el número de liberación del paquete. Entonces, todas las demás clases o paquetes que permanecen en el paquete que cambió deben actualizarse con la liberación más reciente y someterse a pruebas a fin de garantizar que la nueva versión opera sin problemas. Si las clases no se agrupan de manera cohesiva, es posible que se cambie una clase sin relación junto con las demás que hay dentro del paquete. Esto generará integración y pruebas innecesarias. Por esta razón, sólo las clases que se reutilicen juntas deben incluirse dentro de un paquete.

10.2.2

Lineamientos de diseño en el nivel de componentes

Además de los principios estudiados en la sección 10.2.1, conforme avanza el diseño en el nivel de componentes se aplican lineamientos prácticos a los componentes, a sus interfaces y a las características de dependencia y herencia que tengan algún efecto en el diseño resultante. Ambler [Amb02b] sugiere los lineamientos siguientes:

?

¿Qué es lo que hay que tomar en cuenta al dar nombre a los componentes?

Componentes. Deben establecerse convenciones para dar nombre a los componentes que se especifique que forman parte del modelo arquitectónico, para luego mejorarlos y elaborarlos como parte del modelo en el nivel de componentes. Los nombres de los componentes arquitectónicos deben provenir del dominio del problema y significar algo para todos los participantes que vean el modelo arquitectónico. Por ejemplo, el nombre de la clase PlanodelaCasa tiene un significado para todos los que lo lean, aunque no tengan formación técnica. Por otro lado, los componentes de infraestructura o clases elaboradas en el nivel de componentes deben recibir un nombre que tenga un significado específico de la implantación. Si como parte de la implantación de PlanodelaCasa va a administrarse una lista vinculada, es apropiada la operación AdministrarLista( ), aun si una persona sin capacitación técnica pudiera interpretarlo mal.3 Pueden usarse estereotipos para ayudar a identificar la naturaleza de los componentes en el nivel de diseño detallado. Por ejemplo, <> debiera usarse para identificar un componente de infraestructura, <> podría emplearse para identificar una base de datos que dé servicio a una o más clases de diseño o a todo el sistema; se usaría <> para identificar una tabla dentro de una base de datos. Interfaces. Las interfaces dan información importante sobre la comunicación y la colaboración (también nos ayudan a cumplir el PAC). Sin embargo, la representación sin restricciones de las interfaces tiende a complicar los diagramas de componentes. Ambler [Amb02c] recomienda que 1) si los diagramas aumentan en complejidad, en lugar del enfoque formal del UML con recuadro y flecha, debe representarse la interfaz con una paleta; 2) en aras de la consistencia, las interfaces deben fluir a partir del lado izquierdo del recuadro del componente; 3) sólo deben aparecer aquellas interfaces que sean relevantes para el componente que se está considerando,

3

No es probable que alguien de mercadotecnia o de la organización cliente (de tipo no técnico) analice la información de diseño detallado.


26/1/10 17:33:19

C AP Í T UL O 10

243


aun si estuvieran disponibles otras. Estas recomendaciones buscan simplificar la naturaleza visual de los diagramas UML de componentes. Dependencias y herencia. Para tener una mejor legibilidad, es buena idea modelar las dependencias de izquierda a derecha y la herencia de abajo (clases obtenidas) hacia arriba (clases base). Además, las interdependencias de componentes deben representarse por medio de interfaces y no con la dependencia componente a componente. Según la filosofía del PAC, esto ayudará a hacer que sea más fácil dar mantenimiento al sistema.

10.2.3 Cohesión En el capítulo 8 se describió la cohesión como la “unidad de objetivo” de un componente. En el contexto del diseño en el nivel de componentes para los sistemas orientados a objetos, la cohesión implica que un componente o clase sólo contiene atributos y operaciones que se relacionan de cerca uno con el otro y con la clase o componente en sí. Lethbridge y Laganiére [Let01] definen varios tipos diferentes de cohesión (se listan en función del nivel de cohesión):4 Funcional. Lo tienen sobre todo las operaciones; este nivel de cohesión ocurre cuando un componente realiza un cálculo y luego devuelve el resultado. De capa. Lo tienen los paquetes, componentes y clases; este tipo de cohesión ocurre

CONSEJO

cuando una capa más alta accede a los servicios de otra más baja, pero ésta no tiene ac-

Aunque es instructivo entender los distintos niveles de cohesión, es más importante tener presente el concepto general cuando se diseñen componentes. Mantenga la cohesión tan grande como sea posible.

ceso a las superiores. Por ejemplo, considere el requerimiento de la función de seguridad de CasaSegura para hacer una llamada telefónica si se detecta una alarma. Podría definirse un conjunto de paquetes en capas, como se aprecia en la figura 10.5. Los paquetes sombreados contienen componentes de infraestructura. Es posible realizar el acceso del paquete del panel de control hacia abajo. De comunicación. Todas las operaciones que acceden a los mismos datos se definen dentro de una clase. En general, tales clases se centran únicamente en los datos en cuestión, acceden a ellos y los guardan. Las clases y componentes que tienen cohesión funcional, de capa y comunicación son relativamente fáciles de implantar, probar y mantener. Siempre que sea posible, deben alcanzarse estos niveles de cohesión. Sin embargo, es importante notar que en ocasiones hay aspectos pragmáticos del diseño y de la implantación que obligan a optar por niveles de cohesión más bajos.

FIGURA 10.5 Cohesión de capa

Panel de control

Detector

Teléfono

Módem

Telecomunicaciones

4

En general, entre más alto sea el nivel de cohesión, el componente es más fácil de implantar, probar y mantener.


26/1/10 17:33:19

244

PAR T E DOS

MO D E LADO

C ASA S EGURA 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 que me dijeras algo.

Ed (frunce el señ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.

(Con señas, Jamie lo invita a que continúe.)

Jamie: ¿Y qué pasa si decidimos cambiar la forma en la que representamos el campo de visión?

Ed: Originalmente definimos cinco operaciones para cámara. Mira…

Ed: Sólo se pasa a la operación MostrarCámara( ) y se hace la modificación.

DeterminarTipo( ) dice el tipo de cámara.

Jamie: ¿Qué hay con los efectos colaterales?

CambiarUbicación( ) permite mover la cámara por el plano de la casa.

Ed: ¿Qué quieres decir?

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.

10.2.4

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.

Acoplamiento

En el estudio anterior del análisis y el diseño, se dijo que la comunicación y la colaboración eran elementos esenciales de cualquier sistema orientado a objetos. Sin embargo, esta característica tan importante (y necesaria) tiene un lado oscuro. A medida que aumentan la comunicación y colaboración (es decir, conforme se eleva la “conectividad” entre las clases), la complejidad del sistema también se incrementa. Y si la complejidad aumenta, también crece la dificultad de implantar, probar y dar mantenimiento al software. El acoplamiento es la medición cualitativa del grado en el que las clases se conectan una con CONSEJO

A medida que se elabora el diseño de cada componente del software, la atención pasa al diseño de las estructuras específicas de los datos y al diseño de procedimientos para manipularlas. Sin embargo, no hay que olvidar la arquitectura que debe albergar los componentes de las estructuras globales de los datos, que tal vez atiendan a muchos componentes.


otra. Conforme las clases (y componentes) se hacen más interdependientes, el acoplamiento crece. Un objetivo importante del diseño en el nivel de componente es mantener el acoplamiento tan bajo como sea posible. El acoplamiento de las clases se manifiesta de varias maneras. Lethbridge y Laganiére [Let01] definen las siguientes categorías de acoplamiento: Acoplamiento de contenido. Tiene lugar cuando un componente “modifica subrepticiamente datos internos en otro componente” [Let01]. Esto viola el ocultamiento de la información, concepto básico del diseño. Acoplamiento común. Sucede cuando cierto número de componentes hacen uso de una variable global. Aunque a veces esto es necesario (por ejemplo, para establecer valores de-

26/1/10 17:33:19

C AP Í T UL O 10

245


finidos que se utilizan en toda la aplicación), el acoplamiento común lleva a la propagación incontrolada del error y a efectos colaterales imprevistos cuando se hacen los cambios. Acoplamiento del control. Tiene lugar si la operación A( ) invoca a la operación B( ) y pasa una bandera de control a B. La bandera “dirige” entonces el flujo de la lógica dentro de B. El problema con esta forma de acoplamiento es que un cambio no relacionado en B puede dar como resultado la necesidad de cambiar el significado de la bandera de control que pasa A. Si esto se pasa por alto ocurrirá un error. Acoplamiento de molde. Se presenta cuando se declara a ClaseB como un tipo para un argumento de una operación de ClaseA. Como ClaseB ahora forma parte de la definición de ClaseA, la modificación del sistema se vuelve más compleja. Acoplamiento de datos. Ocurre si las operaciones pasan cadenas largas de argumentos de datos. El “ancho de banda” de la comunicación entre clases y componentes crece y la complejidad de la interfaz se incrementa. Se hace más difícil hacer pruebas y dar mantenimiento. Acoplamiento de rutina de llamada. Tiene lugar cuando una operación invoca a otra. Este nivel de acoplamiento es común y con frecuencia muy necesario. Sin embargo, aumenta la conectividad del sistema. Acoplamiento de tipo de uso. Ocurre si el componente A usa un tipo de datos definidos en el componente B (esto ocurre siempre que “una clase declara una variable de instancia o una variable local como si tuviera otra clase para su tipo” [Let01]). Si cambia la definición de tipo, también debe cambiar todo componente que la utilice. Acoplamiento de inclusión o importación. Pasa cuando el componente A importa o incluye un paquete o el contenido del componente B. Acoplamiento externo. Sucede si un componente se comunica o colabora con componentes de infraestructura (por ejemplo, funciones del sistema operativo, capacidad de la base de datos, funciones de telecomunicación, etc.). Aunque este tipo de acoplamiento es necesario, debe limitarse a un número pequeño de componentes o clases dentro de un sistema. El software debe tener comunicación interna y externa. Por tanto, el acoplamiento es un hecho de la vida. Sin embargo, el diseñador debe trabajar para reducirlo siempre que sea posible, y entender las ramificaciones que tiene el acoplamiento abundante cuando no puede evitarse.

C ASA S EGURA El acoplamiento en acción La escena: Cubículo de Shakira.

Vinod (sonríe): Por eso se llaman sensores, Shakira.

Participantes: Vinod y Shakira, miembros del equipo de software de CasaSegura, que trabajan en la función de seguridad.

Shakira (exasperada): Sarcasmo, Vinod, tienes que mejorar tus habilidades interpersonales.

La conversación:

Shakira: Bien, de cualquier modo, me pregunté… por qué no crear 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.

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: ¿Decías?

Vinod (pensativo): Quieres decir, ¿eso en vez de hacer que esa colaboración ocurra fuera de un componente como PaneldeControl o algún otro?

26/1/10 17:33:20

246

PAR T E DOS

MO D E LADO

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

10. 3

REALIZACIÓN

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í.

DEL DISEÑO EN EL NIVEL DE COMPONENTES

Antes, en este capítulo, se dijo que el diseño en el nivel de componentes es de naturaleza ela-

Cita: “Si hubiera tenido más tiempo habría escrito una carta más breve.” Blas Pascal

borativa. Debe transformarse la información de los modelos de requerimientos y arquitectónico a una representación de diseño que dé suficientes detalles para guiar la actividad de construcción (codificación y pruebas). Los pasos siguientes representan un conjunto de tareas comunes para el diseño en el nivel de componentes cuando se aplica a un sistema orientado a objetos. Paso 1. Identificar todas las clases de diseño que correspondan al dominio del problema. Con el uso del modelo de requerimientos y arquitectónico, se elabora cada clase de análisis y componente de la arquitectura según se describió en la sección 10.1.1.

CONSEJO

Si se trabaja en un ambiente sin espías, los primeros tres pasos se dirigen a refinar los objetos de datos y las funciones de procesamiento (transformaciones) identificadas como parte del modelo de requerimientos.

Paso 2. Identificar todas las clases de diseño que correspondan al dominio de la infraestructura. Estas clases no están descritas en el modelo de los requerimientos y con frecuencia se pierden a partir del modelo arquitectónico; sin embargo, deben describirse en este punto. Como se dijo, las clases y componentes en esta categoría incluyen componentes de la interfaz gráfica de usuario (con frecuencia disponibles como componentes reutilizables), componentes del sistema operativo y componentes de administración de objetos y datos. Paso 3. Elaborar todas las clases de diseño que no sean componentes reutilizables. La elaboración requiere que se describan en detalle todas las interfaces, atributos y operaciones necesarios para implantar la clase. Mientras se realiza esta tarea, deben considerarse los heurísticos del diseño (como la cohesión y el acoplamiento del componente). Paso 3a. Especificar detalles del mensaje cuando colaboren clases o componentes.

El

modelo de requerimientos utiliza un diagrama de colaboración para mostrar la forma en la que las clases de análisis colaboran una con la otra. A medida que avanza el diseño en el nivel de componentes, en ocasiones es útil mostrar los detalles de estas colaboraciones especificando las estructuras de los mensajes que pasan entre los objetos de un sistema. Aunque esta actividad de diseño es opcional, se usa como precursor de la especificación de interfaces que muestren el modo en el que se comunican y colaboran los componentes del sistema. La figura 10.6 ilustra un diagrama sencillo de colaboración para el sistema de impresión que ya se mencionó. Los objetos TrabajodeProducción, OrdendeTrabajo y FiladeTrabajos colaboran para preparar un trabajo de impresión a fin de ejecutar una secuencia de producción. Los mensajes entre los objetos se transmiten como lo ilustran las flechas en la figura. Durante la modelación de los requerimientos, los mensajes se especifican como se aprecia. Sin embargo, conforme el diseño avanza, cada mensaje se elabora expandiendo su sintaxis de la manera siguiente [Ben02]: [condición de guardia] expresión de secuencia (devuelve valor) := nombre del mensaje (lista de argumentos)


26/1/10 17:33:20

C AP Í T UL O 10

247


FIGURA 10.6 Diagrama de colaboración con mensajería

:Trabajode Producción 1: ElaborarTrabajo (número de orden de trabajo)

2: EnviarTrabajo (número de orden de trabajo)

:OrdendeTrabajo :FiladeTrabajos

donde [condición de guardia] se escribe en Lenguaje de Restricción de Objetos (LRO)5 y especifica cualesquiera condiciones que deban cumplirse antes de que pueda enviarse el mensaje; expresión de secuencia es un valor entero (u otro indicador de ordenación, por ejemplo, 3.1.2) que

indica el orden secuencial en el que se envía el mensaje; (devuelve valor) es el nombre de la información que devuelve la operación invocada por el mensaje; nombre del mensaje identifica la operación que va a invocarse y (lista de argumentos) es la lista de atributos que se pasan a la operación. Paso 3b. Identificar interfaces apropiadas para cada componente. En el contexto del diseño en el nivel de componentes, una interfaz UML es un “grupo de operaciones visibles externamente (para el público). La interfaz no contiene estructura interna, ni atributos ni asociaciones…” [Ben02]. Dicho con más formalidad, una interfaz es el equivalente de una clase abstracta que provee una conexión controlada entre clases de diseño. En la figura 10.1 se ilustra la elaboración de interfaces. En esencia, las operaciones definidas para la clase de diseño se clasifican en una o más clases abstractas. Cada operación dentro de la clase abstracta (la interfaz) debe ser cohesiva, es decir, debe tener un procesamiento que se centre en una función o subfunción limitada. En relación con la figura 10.1, puede afirmarse que la interfaz IniciarTrabajo no tiene suficiente cohesión. En realidad, ejecuta tres subfunciones diferentes: elaborar una orden de trabajo, verificar la prioridad del trabajo y pasar el trabajo a producción. La interfaz debe rediseñarse. Un enfoque podría consistir en volver a estudiar las clases de diseño y definir una nueva, OrdendeTrabajo, que se haría cargo de todas las actividades asociadas con la formación de una orden de trabajo. La operación ElaborarOrdendeTrabajo( ) se vuelve parte de esa clase. De manera similar, se definiría una clase FiladeTrabajos que incorporaría la operación VerificarPrioridad( ). Una clase TrabajodeProducción podría incorporar toda la información asociada con un trabajo que pasara a las instalaciones de producción. La interfaz IniciarTrabajo podría adoptar la forma que se muestra en la figura 10.7. Ahora la interfaz IniciarTrabajo es cohesiva y se centra en una función. Las interfaces asociadas con TrabajodeProducción, OrdendeTrabajo y FiladeTrabajos también tienen un solo objetivo. Paso 3c. Elaborar atributos y definir tipos y estructuras de datos requeridos para implantarlos. En general, las estructuras y tipos de datos usados para definir atributos se definen en el contexto del lenguaje de programación que se va a usar para la implantación. El UML define un tipo de datos del atributo que usa la siguiente sintaxis: nombre : tipo-de-expresión = valor-inicial {cadena de propiedades}

5


En el apéndice 1 se analiza brevemente el LRO.

26/1/10 17:33:20

248

PAR T E DOS

MO D E LADO

FIGURA 10.7

CalcularTrabajo

Rediseño de interfaces y definiciones de clase para ImprimirTrabajo

IniciarTrabajo

ObtenerDescripción delTrabajo

OrdendeTrabajo

atributos apropiados

Elaborar Trabajo

ElaborarOrdendeTrabajo( )

FiladeTrabajos

ImprimirTrabajo

<> IniciarTrabajo Trabajode Producción

PasarTrabajoaProducción( )

Enviar Trabajo

atributos apropiados VerificarPrioridad( )

donde nombre es el nombre del atributo, tipo-de-expresión es el tipo de datos, valor-inicial es el valor que toma el atributo cuando se crea un objeto y cadena de propiedades define una propiedad o característica del atributo. Durante la primera iteración del diseño en el nivel de componentes, los atributos normalmente se describen por su nombre. De nuevo, en la figura 10.1, la lista de atributos para ImprimirTrabajo sólo enlista los nombres de los atributos. No obstante, a medida que avanza la elaboración del diseño, cada atributo se define con el formato de atributos UML mencionado. Por ejemplo, Tipodepapel-peso se define del modo siguiente: Tipodepapel-peso: cadena = “A” {contiene 1 de 4 valores – A, B, C o D}

que define a Tipodepapel-peso como una variable de cadena que se inicializa en el valor A y que puede adoptar uno de cuatro valores del conjunto {A, B, C, D}. Si un atributo aparece en forma repetida en varias clases de diseño y tiene una estructura relativamente compleja, es mejor crear una clase separada para que lo albergue. Paso 3d. Describir en detalle el flujo del procesamiento dentro de cada operación. Esto se logra con el uso de seudocódigo basado en lenguaje de programación o con un diagrama UML de actividades. Cada componente del software se elabora a través de cierto número de iteraciones que apliquen paso a paso el concepto de refinamiento (capítulo 8). La primera iteración define cada operación como parte de la clase de diseño. En cada caso, la operación debe caracterizarse en forma tal que asegure que haya mucha cohesión; es decir, la operación debe estar dirigida a la ejecución de una sola función o subfunción. La siguiente iteración no hace más que expandir el nombre de la operación. Por ejemplo, la operación CalcularCostodelPapel( ) que aparece en la figura 10.1 se expande de la manera siguiente: CalcularCostodelPapel (peso, tamaño, color): numérico

Esto indica que CalcularCostodelPapel( ) requiere como entrada los atributos peso, tamaño y color, CONSEJO

Para refinar el diseño del componente, utilice una elaboración stepwise. Siempre pregunte, “¿hay una forma de simplificar esto y que aun así se logre el mismo resultado?”


y da como salida un valor numérico (valor en dólares). Si el algoritmo requerido para implantar CalcularCostodelPapel( ) es sencillo y entendido por todos, tal vez no sea necesaria una mayor elaboración del diseño. El ingeniero de software que haga la codificación proveerá los detalles necesarios para implantar la operación. Sin embargo, si el algoritmo fuera más complejo o difícil de entender, se requeriría elaborar más el diseño. La figura 10.8 ilustra un diagrama UML de actividades para CalcularCostodelPapel( ). Cuando se usan diagramas de actividades para especificar el diseño en el nivel de componentes, por lo

26/1/10 17:33:21

C AP Í T UL O 10


249

FIGURA 10.8 Diagrama de actividades UML para calcular CostodelPapel( )

Validar entrada de atributos

AccederaBDPapel (peso) devuelve CostoBaseporPágina CostoporPáginadePapel = CostoBaseporPágina Tamaño = B

CostoporPáginadePapel = CostoporPáginadePapel*1.2

Tamaño = C


Tamaño = D


El color es estándar


El color es estándar Devuelve (CostoporPáginadePapel)

general se representan en un nivel de abstracción que es algo mayor que el código fuente. En la sección 10.5.3 se estudia un enfoque alternativo: el uso de seudocódigo para hacer las especificaciones del diseño. Paso 4. Describir las fuentes persistentes de datos (bases de datos y archivos) e identificar las clases requeridas para administrarlos. Es normal que las bases de datos y archivos trasciendan la descripción del diseño de un componente individual. En la mayoría de casos, estos almacenamientos persistentes de datos se especifican al inicio como parte del diseño de la arquitectura. No obstante, a medida que avanza la elaboración del diseño, es frecuente que sea útil dar detalles adicionales sobre la estructura y organización de dichas fuentes persistentes de datos. Paso 5. Desarrollar y elaborar representaciones del comportamiento para una clase o componente. Los diagramas de estado UML fueron utilizados como parte del modelo de los requerimientos para representar el comportamiento observable desde el exterior del sistema y el más localizado de las clases de análisis individuales. Durante el diseño en el nivel de componentes, en ocasiones es necesario modelar el comportamiento de una clase de diseño. El comportamiento dinámico de un objeto (instancias de una clase de diseño cuando el programa se ejecuta) se ve afectado por eventos externos a él y por el estado en curso (modo de comportamiento) del objeto. Para entender el comportamiento dinámico de un objeto, deben estudiarse todos los casos de uso que sean relevantes para la clase de diseño a lo largo de su

<

Ingenieria Del Software. Un Enfoque Practico - Roger Pressman 7th.ed

Overview

More details