Anlisis de modelado

Soy un Foo (entidad informtica) con un nombre, si pudiera recordarlo.

- Un programador con muy poco cerebro

El resultado del anlisis en un modelo del sistema pretende ser correcto, completo, consistente e inequvoca. Los Desarrolladores formalizan la especificacin de requisitos que se produce durante la bsqueda de requisitos y examinan en ms detalle las condiciones lmites y los casos excepcionales. Los Desarrolladores validan, corrigen y aclaran la especificacin de requisitos, si errores o ambigedades se encuentran. El cliente y el usuario estn a menudo involucrados en esta actividad cuando la especificacin de los requisitos debe cambiarse y cuando la informacin adicional debe ser recogida.

En el anlisis orientado a objetos, los desarrolladores construyen un modelo que describe el dominio de aplicacin. Por ejemplo, el modelo de anlisis de un reloj describe cmo el reloj representa el tiempo: El reloj sabe sobre los aos bisiestos? Tiene conocimiento sobre el da de la semana? Tiene conocimiento acerca de las fases de la luna? El modelo de anlisis se extiende luego a describir cmo los actores y la sistema interactan para manipular el modelo de dominio de aplicacin: Cmo funciona el reinicio del tiempo en el reloj? Cmo funciona el reinicio del da de la semana? Los desarrolladores utilizan el anlisis del modelo, junto con los requisitos no funcionales, para preparar la arquitectura del sistema desarrollado durante el diseo de alto nivel (Captulo 6, Diseo de Sistemas: La descomposicin del sistema).

En este captulo, se discuten las actividades de anlisis con ms detalle. Nos centramos en el identificacin de los objetos, su comportamiento, sus relaciones, su clasificacin, as como su organizacin. Se describen los problemas de gestin relacionados con el anlisis en el contexto de un proyecto de desarrollo multi-equipo. Finalmente, se discute en ms detalle los temas de anlisis y soluciones de compromiso utilizando el caso de estudio ARENA.

5.1 Introduccin: una ilusin ptica

En 1915, Rubin mostr un dibujo parecido a la Figura 5-1 para ilustrar el concepto de imgenes multi-estables. Qu ves? Dos caras que se miran el uno al otro? Si usted se centra ms estrechamente en el rea blanca, se puede ver un jarrn en su lugar. Una vez que son capaces de percibir las dos formas de forma individual, se es ms fcil cambiar hacia adelante y hacia atrs entre el jarrn y las caras.

Figura 5-1 La ambigedad: qu ves?

Si el dibujo de la figura 5-1 fuera una especificacin de requisitos, que modelo debes construir? Las especificaciones, como las imgenes mltiples estables, contienen ambigedades provocadas por las imprecisiones inherentes al lenguaje natural y por los supuestos de la especificacin de los autores. Por ejemplo, una cantidad determinada sin unidades es ambigua (por ejemplo, el ejemplo "pies o millas?" en la seccin 4.1), un hora sin zona horaria es ambigua (por ejemplo, el cdigo de rea de una llamada telefnica entre los diferentes pases).

La formalizacin ayuda a identificar reas de ambigedad, as como inconsistencias y omisiones en una especificacin de requisitos. Una vez que los desarrolladores identifican problemas con el pliego de condiciones, hay que abordarlos mediante la obtencin de ms informacin de los usuarios y el cliente. La Obtencin de requerimientos y el anlisis son actividades iterativos e incrementales que se producen al mismo tiempo.

5.2 Una visin general de anlisis

El anlisis se concentra en la produccin de un modelo del sistema, llamado el modelo de anlisis, que es correcto, completo, consistente y verificable. El anlisis es diferente de la obtencin de requisitos en el que los desarrolladores se centran en la estructuracin y formalizacin de los requisitos generados por los usuarios (Figura 5-2). Esta formalizacin conduce a nuevas ideas y el descubrimiento de errores en los requisitos.

Figura 5-2 Productos de obtencin de requisitos y anlisis (diagrama de actividades UML).

A medida que el modelo de anlisis no es comprensible para los usuarios y el cliente, los desarrolladores necesitan actualizar la especificacin de requisitos para reflejar los conocimientos adquiridos durante el anlisis, a continuacin, se revisan los cambios con el cliente y los usuarios. Al final, los requisitos, por grande que sea, deben ser comprensibles por el cliente y los usuarios. Hay una tendencia natural para los usuarios y desarrolladores de posponer decisiones difciles hasta ms tarde en el proyecto. La decisin puede ser difcil debido a la falta de conocimiento del dominio, la falta de conocimiento tecnolgico, o simplemente debido a los desacuerdos entre los usuarios y los desarrolladores. El aplazamiento de las decisiones permite al proyecto seguir adelante sin problemas y evita la confrontacin con la realidad o los compaeros. Desafortunadamente, las decisiones difciles, finalmente se deben hacer, a menudo a un costo mayor cuando se descubren problemas intrnsecos durante la prueba, o peor an, durante la evaluacin de los usuarios. La traduccin de una especificacin de requisitos en un modelo formal o semiformal obliga a los desarrolladores identificar y resolver problemas difciles al principio del desarrollo.

El modelo de anlisis se compone de tres modelos distintos: el modelo funcional, representado por los casos de uso y escenarios, el modelo de objetos de anlisis, representado por las clases y diagramas de objetos, y el modelo dinmico, representado por mquina de estados y diagramas de secuencia (Figura 5-3). En el captulo anterior, se describe la forma de obtener los requerimientos de los usuarios y describirlos como los casos de uso y escenarios. En este captulo, se describe la forma de perfeccionar el

modelo funcional y derivar hacia los objetos y el modelo dinmico. Esto conduce a una especificacin ms precisa y completa cuando los detalles se aaden al modelo de anlisis. Concluimos el captulo describiendo las actividades de gestin relacionadas con el anlisis. En la siguiente seccin, se define los principales conceptos de anlisis.

Figura 5-3 El modelo de anlisis est compuesto por el modelo funcional, el modelo de objetos, y el modelo dinmico. En UML, el modelo funcional est representado con diagramas de casos de uso, el modelo de objetos por diagramas de clase, y el modelo dinmico por los diagramas de mquina de estados y los diagramas de secuencia.

5.3 Conceptos de Anlisis

En esta seccin, se describen los principales conceptos de anlisis utilizados en este captulo. En particular, se describe:

Modelos de anlisis de objetos y modelos dinmicos (Seccin 5.3.1)

Los objetos de entidad, de lmites y de control (Seccin 5.3.2)

La Generalizacin y especializacin (Seccin 5.3.3).

5.3.1 Modelos de anlisis de objetos y modelos dinmicos

El modelo de anlisis representa el sistema en desarrollo desde el punto de vista del usuario. El modelo de anlisis de objetos es una parte del modelo de anlisis y se centra en los conceptos individuales que son manipulados por el sistema, sus propiedades y sus relaciones. El modelo de anlisis de objetos, es representado con diagramas de clases UML, incluye clases, atributos y operaciones. El modelo de anlisis de objetos es un diccionario visual de los principales conceptos visibles para el usuario.

El modelo dinmico se centra en el comportamiento del sistema. El modelo dinmico se representa con los diagramas de secuencia y con mquina de estados. Los diagramas de secuencia representan las interacciones entre un conjunto de objetos en un solo caso de uso. La mquina de estados representan el comportamiento de un solo objeto (o un grupo de objetos muy fuertemente acoplados). El modelo dinmico sirve para asignar responsabilidades a las clases individuales y, en el proceso, para identificar nuevas clases, asociaciones, y los atributos que se aaden al modelo de anlisis de objetos. Cuando se trabaja con el modelo de anlisis de objetos o el modelo dinmico, es esencial recordar que estos modelos representan conceptos de nivel usuario, no clases de software actuales o componentes. Por ejemplo, las clases, tales como bases de datos, subsistema, sesin de administrador, Red, no deben aparecer en el modelo de anlisis porque el usuario debe estar totalmente protegido de esos conceptos.

Tenga en cuenta que la mayora de las clases en el modelo de anlisis de objetos se corresponden a uno o ms clases de software en el cdigo fuente. Sin embargo, las clases de software incluyen muchos ms atributos y asociaciones que sus homlogos de anlisis. En consecuencia, las clases de anlisis deben ser vistos como abstracciones de alto nivel que se realizarn con mucho ms detalle ms adelante. La Figura 5-4 representa buenos y malos ejemplos de anlisis de objetos para el ejemplo SatWatch.

Figura 5-4 Ejemplos y contraejemplos de las clases del modelo de objetos de anlisis de SatWatch.

5.3.2 Objetos de tipo Entidad, Lmite y Control

El modelo de anlisis de objetos consiste en objetos entidad, lmite, y de control [Jacobson et al., 1999]. Los Objetos Entity (Entidad) representan la informacin persistente rastreada por el sistema. Los Objetos Boundary (Lmite) representan las interacciones entre los actores y el sistema. Los Objetos Control (Control) estn en cargo de la realizacin de casos de uso. En el ejemplo 2Bwatch, Ao, Mes y Da son objetos de entidad; Button y LCDDisplay son objetos lmite; ChangeDateControl es un objeto de control que representa la actividad de cambio de la fecha pulsando combinaciones de botones.

El modelando del sistema con objetos entidad, lmite, y control ofrece a los desarrolladores heursticas simples para distinguir diferentes conceptos relacionados. Por ejemplo, la hora que muestra un reloj tiene propiedades diferentes que la pantalla que muestra la hora. Diferenciando entre los objetos lmite y entidad forzamos esa distincin: La hora del reloj est representado por el objeto de Tiempo. La pantalla est representada por el objeto LCDDisplay. Este enfoque con tres tipos de objetos resulta en objetos ms pequeos y ms especializados. El enfoque de tipo de objetos en estas tres clasificaciones tambin conduce a modelos que son ms resistentes al cambio: la interfaz con el sistema (representado por los objetos de lmite) es ms probable que cambie su funcionalidad bsica (representado por los objetos de entidad y de control). Mediante la separacin de la interfaz de la funcionalidad bsica, somos capaces de mantener la mayor parte de un modelo sin tocar cuando, por ejemplo, la interfaz de usuario cambia, pero los objetos de entidad no lo hacen.

Para distinguir entre los diferentes tipos de objetos, UML proporciona el mecanismo estereotipo que permita al desarrollador fijar tal meta-informacin para los elementos de modelado. Para ejemplo, en la figura 5-5, se aade el estereotipo control al objeto ChangeDateControl. Adems de los estereotipos, tambin podemos utilizar las convenciones de nombres para una mayor claridad y se recomienda distinguir los tres tipos diferentes de los objetos de una base sintctica: objetos de control pueden tener el sufijo control anexado a su nombre; objetos de lmite pueden ser nombrados para denotar claramente una funcin de interfaz (por ejemplo, mediante la inclusin del sufijo, Form, Button, Display, o Boundary); los objetos entidad generalmente no tienen ningn sufijo anexado a su nombre. Otro beneficio de esta convencin de nombres es que el tipo de la clase se representa incluso cuando el estereotipo de UML es no disponible, por ejemplo, cuando se examina slo el cdigo fuente.

Figura 5-5 clases de anlisis para el ejemplo 2Bwatch.

5.3.3 Generalizacin y especializacin

Como vimos en el captulo 2, Modelado con UML, la herencia nos permite organizar conceptos en jerarquas. La parte superior de la jerarqua es un concepto general (por ejemplo, un incidente, Figura 5-6), y en la parte inferior de la jerarqua son los conceptos ms especializados (por ejemplo, CatInTree, TrafficAccident, BuildingFire, EarthQuake, ChemicalLeak). Puede haber cualquier nmero de niveles intermedios en el medio, que abarca conceptos ms o menos generalizados (por ejemplo, LowPriorityIncident, Emergency, Disaster). Tales jerarquas nos permiten referirnos a muchos conceptos precisos. Cuando usamos el trmino de Incidentes, nos referimos a todas las instancias de todos los tipos de Incidentes. Cuando usamos el trmino emergencia, solo se refiere a un incidente que requiera una respuesta inmediata.

La generalizacin es la actividad de modelado que identifica los conceptos abstractos de nivel inferior requeridos. Por ejemplo, suponemos que estamos haciendo ingeniera inversa de un sistema de gestin de emergencias y descubrimos las pantallas de gestin de accidentes de trfico e incendios. Al darse cuenta de las caractersticas comunes entre estos tres conceptos, se crea un concepto abstracto llamado emergencia (y en general) para describir las caractersticas comunes de los accidentes de trfico e incendios. La especializacin es la actividad que identifica conceptos ms especficos que el alto nivel. Por ejemplo, suponemos que estamos construyendo un sistema de gestin de emergencia a partir de cero y que estamos hablando de su funcionalidad con el cliente. El cliente primero nos introduce con el concepto de un incidente, a continuacin se describen tres tipos de incidentes: Desastres, que requieren la colaboracin de varias agencias, Emergencias, que requieren un manejo inmediato, pero puede haber manejado por un solo organismo, e Incidentes de baja prioridad, que no requieren muchos recursos en comparacin con los incidentes de mayor prioridad.

Figura 5-6 Un ejemplo de una jerarqua de generalizacin (diagrama de clases UML). La parte superior de la jerarqua representa el concepto ms general, mientras que los nodos inferiores representan los conceptos ms especializados.

En ambos casos, la generalizacin y la especializacin dan como resultado la especificacin de las relaciones de herencia entre los conceptos. En algunos casos, los modeladores llaman a las relaciones de herencia relaciones de generalizacin-especializacin. En este libro, se utiliza el trmino "herencia" para denotar la relacin y los trminos "generalizacin" y "especializacin" para denotar las actividades que se encuentran en las relaciones de herencia.

5.4 Anlisis de Actividades: De los casos de uso a los objetos

En esta seccin, se describen las actividades que transforman los casos de uso y escenarios producidos durante la obtencin de requisitos en un modelo de anlisis. Las actividades de anlisis incluyen:

Identificar a los objetos entidad (Seccin 5.4.1)

Identificar a los objetos lmite (Seccin 5.4.2)

Identificar a los objetos control (Seccin 5.4.3)

Mapeo de Casos de uso a los objetos por medio de los diagramas de secuencia (Seccin 5.4.4)

Modelando de interaccin de objetos con tarjetas CRC (Seccin 5.4.5)

Identificar Asociaciones (Seccin 5.4.6)

Identificar Agregacin (Seccin 5.4.7)

Identificar atributos (Seccin 5.4.8)

Modelado de estados de comportamiento dependiente de objetos individuales (Seccin 5.4.9)

Modelado de relaciones de herencia (seccin 5.4.10)

Revisar el modelo de anlisis (seccin 5.4.11).

Para ilustrar cada actividad, nos centraremos en el caso de uso de ReportEmergency del sistema FRIEND descrito en el captulo 4, la obtencin de requisitos. Dichas actividades estn guiadas por la heurstica. La calidad de su resultado depende de la experiencia del desarrollador en la aplicacin de estas heursticas y mtodos. Los mtodos y heurstica que se presentan en esta seccin son una adaptacin de [De Marco, 1978], [Jacobson et al., 1999], [Rumbaugh et al., 1991], y [Wirfs-Brock et al., 1990].

5.4.1 Identificacin de objetos de entidad

Los Objetos (ver Seccin 4.4.6) participantes forman la base del modelo de anlisis. Como se describe en Captulo 4, la obtencin de requisitos, los objetos que participan se encuentran examinando cada caso de uso e identificando a los objetos candidatos. El anlisis del lenguaje natural [Abbott, 1983] es un conjunto intuitivo de heurstica para identificar objetos, atributos y asociaciones de una especificacin de requisitos.

La Heurstica de Abbott permite mapear partes del lenguaje (por ejemplo, sustantivos, verbos tener, verbos ser/estar, adjetivos) hacia componentes del modelo (por ejemplo, objetos, operaciones, relaciones de herencia, clases). Tabla 5-1 proporciona ejemplos de este tipo de asignaciones mediante el examen del caso de uso ReportEmergency (Figura 5-7).

El anlisis del lenguaje natural tiene la ventaja de centrarse en los trminos de los usuarios. Sin embargo, adolece de varias limitaciones. En primer lugar, la calidad del modelo de objetos depende en gran medida el estilo de la escritura del analista (por ejemplo, la consistencia de los trminos utilizados, sustantivos como verbos). El lenguaje natural es una herramienta imprecisa, y un modelo de objetos derivado literalmente del texto corre el riesgo de ser impreciso. Los desarrolladores pueden hacer frente a esta limitacin reformulando y aclarando la especificacin de requisitos ya que identifican y estandarizan los objetos y los trminos.

Tabla 5-1 Heurstica Abbott para mapeo del lenguaje para modelar piezas componentes [Abbott, 1983].Parte de lenguajeComponente del modelo

ejemplos Sustantivo propio Instancia

Alice

Sustantivo Comn Clase

FieldOfficerVerbo hacer

Operacin

Crea, enva, selecciona

Verbo ser/estar

Herencia

Es una especie de, es uno de cualquiera

Verbo tener

Agregacin

Tiene, consiste de, incluye

Verbo modal

Restriccin

Debe ser

Adjetivo

Atributo

Descripcin del Incidente

Nombre del caso ReportEmergency

Condiciones de entrada 1. El FieldOfficer activa la funcin "Informe de emergencia" de su terminal.

Flujo de eventos 2. FRIEND responde mediante la presentacin de un formulario para el oficial. El formulario incluye un men de tipo de emergencia (emergencia general, fuego, transporte), una ubicacin, descripcin del incidente, solicitud de recursos, y los campos de materiales peligrosos.

3. El FieldOfficer completa el formulario especificando mnimamente la situacin de emergencia en los campos de tipo y descripcin. El FieldOfficer tambin puede describir posible respuestas a la situacin de emergencia y solicitar recursos especficos. Una vez que la forma se ha completado, el FieldOfficer enva el formulario pulsando el botn "Enviar Informe ", y en ese momento, se notifica al Dispatcher.

4. El Dispatcher revisa la informacin presentada por el FieldOfficer y crea un incidente en la base de datos invocando el caso de uso OpenIncident. Toda la informacin contenida en el formulario del FieldOfficer es automticamente incluido en el incidente. El Dispatcher selecciona una respuesta mediante la asignacin de recursos del incidente (con el caso de uso AllocateResources) y reconoce el informe de emergencia mediante el envo de un FRIENDgram al FieldOfficer.

Condicin la salida 5. El FieldOfficer recibe el reconocimiento y la respuesta seleccionada. Figura 5-7 Un ejemplo de caso de uso, ReportEmergency (formato de una columna).

Una segunda limitacin del recurso natural del lenguaje en el anlisis es que hay muchos ms nombres que los sectores interesados. Muchos nombres corresponden a atributos o sinnimos de otros sustantivos. La clasificacin a travs de todos los nombres de un gran especificacin de los requisitos es una actividad que consume tiempo. En general, la heurstica de Abbott trabaja as para la generacin de una lista de objetos candidatos iniciales a partir de descripciones cortas, tales como el flujo de acontecimientos de un escenario o un caso de uso. Las siguientes heursticas pueden ser utilizados en conjuncin con Heurstica de Abbott:

Heurstica para la identificacin de objetos de entidad

Los trminos que los desarrolladores o usuarios necesitan ser claros para entender el caso de uso

Los nombres recurrentes en los casos de uso (por ejemplo, Incident)

Las entidades del mundo real que el sistema necesita para realizar un seguimiento (por ejemplo, FieldOfficer, Dispatcher, Resource)

Las actividades del mundo real que el sistema necesita para realizar un seguimiento (por ejemplo, EmergencyOperationsPlan)

Las fuentes o salidas de datos (por ejemplo, Printer).

Los nombres de los Desarrolladores describen brevemente los objetos, sus atributos y sus responsabilidades, ya que estn identificados. Excepcionalmente nombrar objetos promueve un terminologa estndar. Para objetos de entidad se recomienda siempre empezar con los nombres utilizados por los usuarios finales y especialistas de dominio de la aplicacin. Describiendo objetos, aunque sea brevemente, permite a los desarrolladores aclarar los conceptos que utilizan y evitar malentendidos (por ejemplo, el uso de un objeto por dos diferentes conceptos relacionados). Los desarrolladores no necesitan, sin embargo, pasar un montn de tiempo en detallar objetos o atributos dado que el modelo de anlisis se encuentra todava en el flujo. Los desarrolladores deben documentar atributos y las responsabilidades si no son obvias; de lo contrario un nombre provisional y una breve descripcin de cada objeto es suficiente. Habr un montn de iteraciones durante el cual los objetos pueden ser revisados. Sin embargo, una vez que el modelo de anlisis es estable, la descripcin de cada objeto puede ser lo detallada como sea necesario (vase el apartado 5.4.11).

Por ejemplo, despus de un primer examen del caso de uso ReportEmergency (Figura 5-7), se utilizo el conocimiento y dominio de la aplicacin de entrevistas con los usuarios para identificar los objetos Dispatcher, EmergencyReport, FieldOfficer, e Incident. Tenga en cuenta que la EmergencyReport objeto no se menciona explcitamente por su nombre en el caso de uso ReportEmergency. El paso 4 del caso de uso se refiere al informe de emergencia como la "informacin presentada por el FieldOfficer." Despus de revisar con el cliente, descubrimos que esta informacin se refiere generalmente como la "emergencia informe" y deciden nombrar el objeto correspondiente EmergencyReport.

La definicin de los objetos de entidad para el modelo de anlisis inicial se describe en la Tabla 5-2. Tenga en cuenta que este modelo est lejos de ser una descripcin completa del sistema de la aplicacin del caso de uso ReportEmergency. En la siguiente seccin, se describe la identificacin de los objetos lmite.

Tabla 5-2 Entidad objetos para el caso de uso ReportEmergency.

DispatcherEl oficial de polica que maneja incidentes. El Dispatcher, abre documentos y cierra Incidentes en respuesta a los informes de emergencia y otro tipo de comunicacin con FieldOfficers. Los Dispatcher son identificados por nmero de placa.

EmergencyReport Informe inicial sobre un Incidente de un FieldOfficer a un Dispatcher. Un EmergencyReport generalmente desencadena la creacin de un incidente por el Dispatcher. Un EmergencyReport se compone de un nivel de emergencia, un tipo (Incendio, accidente de trfico, otros), una ubicacin y una descripcin.

FieldOfficer Polica u oficial de bomberos de guardia. A FieldOfficer puede asignarse a, como mximo, un Incidente en un momento. FieldOfficers se identifican por nmero de placa.

Incident Situacin que requieran la atencin de un FieldOfficer. Un incidente puede ser reportado en el sistema por un FieldOfficer o cualquier otra persona externa al sistema. Un incidente se compone de una descripcin, una respuesta, un estado (abierto, cerrado, documentado), una ubicacin y un nmero de FieldOfficer.

5.4.2 La identificacin de lmites Objetos

Los objetos lmite representan la interfaz del sistema con los actores. En cada caso de uso, cada actor interacta con al menos un objeto lmite. El objeto lmite recoge la informacin del actor y la traduce en una forma que puede ser utilizado tanto por objetos de entidad y de control. Los objetos lmite modelan la interfaz de usuario a un nivel grueso. No describen en detalle los aspectos visuales de la interfaz de usuario. Por ejemplo, la cobertura de objetos como "elemento de men" o "Barra de desplazamiento" son demasiado detalladas. En primer lugar, los desarrolladores pueden discutir detalles de la interfaz de usuario ms fcilmente con bocetos y pantallas. En segundo lugar, el diseo de la interfaz de usuario contina evolucionando como una consecuencia de las pruebas de usabilidad, incluso despus de la especificacin funcional del sistema se convierte en estable. La actualizacin del modelo de anlisis para cada cambio en la interfaz de usuario requiere mucho tiempo y hace no da ningn beneficio sustancial.

La heurstica para identificar los objetos de contorno

Identificar los controles de interfaz de usuario que el usuario necesita para iniciar el caso de uso (por ejemplo, ReportEmergencyButton).

Identificar las formas en que los usuarios tienen que introducir datos en el sistema (por ejemplo, EmergencyReportForm).

Identificar las notificaciones y mensajes que el sistema utiliza para responder al usuario (por ejemplo,

AcknowledgmentNotice).

Cuando hay varios actores estn involucrados en un caso de uso, identificar los terminales de actores (por ejemplo, DispatcherStation) para referirse a la interfaz de usuario que se trate.

No modelar los aspectos visuales de la interfaz con objetos de lmite (las pantallas de usuario son ms adecuadas para eso).

Siempre use trminos del usuario final para la descripcin de las interfaces; no use trminos de la solucin o dominio de la aplicacin.

Nos encontramos con los objetos lmite en la tabla 5-3 mediante el examen del caso de uso ReportEmergency.

Tabla 5-3 Objetos lmite para el caso de uso ReportEmergency.

AcknowledgmentNotice Aviso usado para mostrar reconocimiento del Dispatcher al FieldOfficer.

DispatcherStation

Computadora usada por el Dispatcher.

ReportEmergencyButton Botn utilizado por un FieldOfficer para iniciar el caso de uso ReportEmergency.

EmergencyReportForm Forma usada para la entrada de la ReportEmergency. Este formulario es presentado al FieldOfficer en la FieldOfficerStation cuando se selecciona la funcin "Informe de emergencia". La EmergencyReportForm contiene campos para especificar todos los atributos de un informe de emergencia y un botn (u otro control) para la presentacin del formulario completo.

FieldOfficerStation

Equipo mvil utilizado por el FieldOfficer.

IncidentForm Formulario usado para la creacin de incidentes. Esta forma se presenta al Dispatcher en el DispatcherStation cuando el EmergencyReport se recibe. El Dispatcher tambin utiliza esta forma para asignar recursos y reconocer el informe del FieldOfficer.

Tenga en cuenta que la IncidentForm no se menciona explcitamente en cualquier parte del caso de uso ReportEmergency. Identificamos este objeto mediante la observacin de que el despachador necesita una interfaz para ver el informe de emergencia presentado por el FieldOfficer y para enviar de vuelta un acuse de recibo. Los trminos utilizados para describir los objetos lmite en el modelo de anlisis debe seguir la terminologa del usuario, incluso si se tiene la tentacin de utilizar los trminos del dominio de aplicacin. Hemos avanzado en la descripcin el sistema. Ahora hemos incluido la interfaz entre el actor y el sistema. Sin embargo, todava faltan algunas piezas significativas de la descripcin, tales como el orden en que se producen las interacciones entre los actores y el sistema. En la siguiente seccin, se describe la identificacin de los objetos de control.

5.4.3 Identificacin de objetos de control

Los objetos de control son responsables de coordinar objetos lmite y entidad. Los objetos de control por lo general no tienen una contrapartida concreta en el mundo real. A menudo existe una estrecha relacin entre un caso de uso y un objeto de control; un objeto de control se crea normalmente en el comienzo de un caso de uso y deja de existir en su extremo. Es responsable de la recopilacin de informacin de los objetos lmite y de despacharla a los objetos entidad. Por ejemplo, los objetos de control describen el comportamiento asociado a la secuencia de las formas, deshacer y colas de historial, y el despacho de informacin en un sistema distribuido.

Inicialmente, vamos a modelar el flujo de control del caso de uso ReportEmergency con un objeto de control para cada actor: ReportEmergencyControl para el FieldOfficer y ManageEmergencyControl para el Dispatcher, respectivamente (Tabla 5-4).

La decisin para modelar el flujo de control del caso de uso ReportEmergency con control de dos objetos deriva del conocimiento de que el FieldOfficerStation y la DispatcherStation son en realidad dos subsistemas que se comunican a travs de un enlace asncrono. Esta decisin se ha aplazado hasta que la actividad de diseo del sistema. Por otra parte, haciendo este concepto visible en el modelo de anlisis nos permite centrarnos en tal comportamiento de excepcin, que es la prdida de la comunicacin entre las dos estaciones.

La heurstica para identificar los objetos de control

Identifique un objeto de control por cada caso de uso.

Identifique un objeto de control por cada actor en el caso de uso.

La vida til de un objeto de control debe cubrir la extensin del caso de uso o la extensin de la sesin de usuario. Si es difcil de identificar el principio y el final de la activacin de un objeto de control, para el caso de uso correspondiente, probablemente no tiene las condiciones de entrada y salida bien definidas

En el modelado del caso de uso ReportEmergency, modelamos la misma funcionalidad mediante el uso de objetos entidad, lmite, y de control. Al cambiar, desde la perspectiva de flujo de eventos a una perspectiva estructural, hemos aumentado el nivel de detalle de la descripcin y seleccionamos trminos estndar para referirse a las principales entidades del dominio de la aplicacin y el sistema. En la siguiente seccin, construimos un diagrama de secuencia utilizando el caso de uso ReportEmergency y los objetos que descubrimos para garantizar la integridad de nuestro modelo.

Tabla 5-4 Objetos de Control para el caso de uso ReportEmergency.

ReportEmergencyControl Administra la funcin de informe ReportEmergency en la FieldOfficerStation. Se crea este objeto cuando el FieldOfficer selecciona el botn "Reportar emergencia". A continuacin, crea un EmergencyReportForm y la presenta al FieldOfficer. Despus de la presentacin de la forma, este objeto a continuacin, recoge la informacin de la forma, crea una EmergencyReport, y lo reenva al despachador. El objeto de control espera entonces un reconocimiento al volver de la DispatcherStation. Cuando se recibe el acuse de recibo, el objeto ReportEmergencyControl crea una AcknowledgmentNotice y lo muestra al FieldOfficer.

ManageEmergencyControl Administra la funcin de informe ReportEmergency en el DispatcherStation. Se crea este objeto cuando un EmergencyReport se recibe. A continuacin, crea un IncidentForm y lo muestra al Dispatcher. Una vez que el Dispatcher ha creado un Incident, los recursos son asignados, y se presenta un reconocimiento, ManageEmergencyControl enva el acuse de recibo al FieldOfficerStation.

5.4.4 Asignacin de Casos de uso a los objetos con los diagramas de secuencia

Un diagrama de secuencia vincula casos de uso con objetos. Se muestra el comportamiento de un caso de uso (o escenario) y cmo se distribuye entre sus objetos participantes. Los diagramas de secuencia por lo general no son tan buen medio para la comunicacin con el usuario como son los casos de uso, debido a que los diagramas de secuencia requieren ms antecedentes acerca de su notacin. Para la comprensin de los clientes, usamos casos de uso que son intuitivos y puede ser ms precisos. En todos los casos, sin embargo, los diagramas de secuencia representan otro cambio de perspectiva y permiten a los desarrolladores encontrar objetos perdidos o zonas grises en la especificacin de requisitos. En esta seccin, vamos a modelar la secuencia de interacciones entre los objetos necesarios para realizar el caso de uso. Las figuras 5-8 hasta la 5-10 son diagramas de secuencia asociados con el caso de uso ReportEmergency. Las columnas de un diagrama de secuencia representan los objetos que participan en el caso de uso. La columna ms a la izquierda es el actor que inicia el caso de uso. Las flechas horizontales a travs de las columnas representan mensajes o estmulos, que son enviados de un objeto a otro. El tiempo se representa verticalmente de arriba a abajo. Por ejemplo, la primera flecha en la Figura 5-8 representa el mensaje press enviado por un FieldOfficer a un ReportEmergencyButton. La recepcin de un mensaje desencadena la activacin de una operacin. La activacin est representada por un rectngulo vertical que puede originar otros mensajes. La longitud del rectngulo representa el tiempo activo de la operacin. En la Figura 5-8, la operacin desencadenada por el mensaje press enva un mensaje create a la clase ReportEmergencyControl. Una operacin puede ser considerada como un servicio que el objeto proporciona a otros objetos. Los diagramas de secuencia tambin representan la duracin de los objetos.

Los objetos que ya existen antes de los primeros estmulos en el diagrama de secuencia se muestran en la parte superior del diagrama. Los objetos que se crean durante la interaccin se representan con el mensaje create que seala al objeto. Los casos que se destruyen durante la interaccin tienen una cruz que indica cuando el objeto deja de existir. Entre el rectngulo que representa el objeto y el cruce (o la parte inferior del diagrama, si el objeto sobrevive a la interaccin), una lnea de trazos representa el lapso de tiempo en que el objeto puede recibir mensajes. El objeto no puede recibir mensajes debajo del signo de la cruz. Por ejemplo, en la figura 5-8, un objeto de la clase ReportEmergencyForm se crea al momento que el objeto ReportEmergencyControl enva el mensaje create y se destruye una vez que el EmergencyReportForm se ha registrado.

Figura 5-8 Diagrama de secuencia para el caso de uso ReportEmergency.

En general, la segunda columna de un diagrama de secuencia representa un objeto lmite con que el actor interacta para iniciar el caso de uso (por ejemplo, ReportEmergencyButton). La tercera columna es un objeto de control que gestiona el resto del caso de uso (por ejemplo, ReportEmergency-Control). A partir de ah, el objeto de control crea otros objetos lmite y puede interactuar con otros objetos de control (por ejemplo, ManageEmergencyControl).

En la Figura 5-9, se descubre el objeto entidad Acknowledgement que olvidamos durante nuestra primer examen del caso de uso ReportEmergency (en la Tabla 5-2). El objeto Acknowledgement es diferente de un AcknowledgmentNotice: Acknowledgement contiene la informacin asociada con un reconocimiento y se crea antes de que el objeto lmite AcknowledgmentNotice. Al describir el objeto de Acknowledgement, tambin nos damos cuenta de que el caso de uso ReportEmergency original (que se describe en la Figura 5-7) est incompleto. Slo se menciona la existencia de un Acknowledgement y no describe la informacin asociada a l. En este caso, desarrolladores necesitan aclaraciones al cliente a definir qu informacin es necesaria en el Acknowledgement. Despus de la obtencin de dicha aclaracin, el Acknowledgement se aade objeto al modelo de anlisis (Tabla 5-5), y el caso de uso ReportEmergency se modifica para incluir el informacin adicional (Figura 5-11).

Figura 5-9 Diagrama de secuencia para el caso de uso ReportEmergency (continuacin de la Figura 5-8).

Figura 5-10 Diagrama de secuencia para el caso de uso ReportEmergency (continuacin de la Figura 5-9).

Mediante la construccin de diagramas de secuencia, no slo modelan el orden de la interaccin entre los objetos, sino que tambin distribuyen el comportamiento del caso de uso. Es decir, se le asigna responsabilidades a cada objeto en la forma de un conjunto de operaciones. Estas operaciones pueden ser compartidas por cualquier caso de uso en que un objeto dado participa. Tenga en cuenta que la definicin de un objeto que se comparte entre dos o ms casos de uso deben ser idnticos; es decir, si una operacin aparece en ms de un diagrama de secuencia, su comportamiento debe ser el mismo.

Nombre del caso de uso

ReportEmergency

Condiciones de entrada 1. El FieldOfficer activa la funcin "Informe de emergencia" de su terminal. Flujo de eventos 2. FRIEND responde mediante la presentacin de un formulario para el oficial. El formulario incluye un men de tipo de emergencia (emergencia general, fuego, transporte), una ubicacin, descripcin del incidente, solicitud de recursos, y los campos de materiales peligrosos.

3. El FieldOfficer completa el formulario especificando mnimamente los campos de descripcin y el tipo de emergencia. El FieldOfficer tambin puede describir las posibles respuestas a la situacin de emergencia y solicitar recursos especficos. Una vez completado el formulario, el FieldOfficer enva el formulario pulsando el botn "Enviar informe", en cuyo punto el Dispatcher se da por notificado.

4. El Dispatcher revisa la informacin presentada por el FieldOfficer y crea un Incidente en la base de datos invocando el caso de uso OpenIncident. Toda la informacin contenida en la forma del FieldOfficer es incluida automticamente en el Incident. El Dispatcher selecciona un respuesta mediante la asignacin de recursos para el Incidente (con el caso de uso AllocateResources) y reconoce el informe de emergencia por el envo de un FRIENDgram al FieldOfficer. El Reconocimiento indica a la FieldOfficer que el EmergencyReport se recibi, se cre un Incident, y los recursos asignados al Incident. El Acknowledgement incluye los recursos (por ejemplo, un camin de bomberos), y la hora de llegada estimada.

Condiciones de salida5. El FieldOfficer recibe el Acknowledgement y la respuesta seleccionada. Figura 5-11 Caso de uso ReportEmergency depurado. El descubrimiento y la adicin del Acknowledgement al compararlo al modelo de anlisis revel que el caso de uso original ReportEmergency no se hizo con precisin, se debe describir la informacin asociada con Acknowledgement. La depuracin se indica en negritas.

Tabla 5-5 Reconocimiento de objetos para el ReportEmergency caso de uso.

Acknowledgement Respuesta de un Dispatcher a un EmergencyReport del FieldOfficer. Por el envo de un acuse , el Dispatcher se comunica con el FieldOfficer que ha recibido la EmergencyReport , cre un Incident , y los recursos asignados a la misma. El Acknowledgement contiene los recursos asignados y su hora prevista de llegada.

Compartir operaciones a travs de casos de uso permite a los desarrolladores eliminar redundancias en el especificacin de los requisitos y de mejorar su consistencia. Tenga en cuenta que la claridad debe ser siempre prioridad a la eliminacin de la redundancia. La fragmentacin de la conducta a travs de muchas operaciones complica innecesariamente la especificacin de requisitos.

En el anlisis, los diagramas de secuencia se utilizan para ayudar a identificar nuevos objetos que participan y faltas en su comportamiento. Debido a que los diagramas de secuencia se centran en alto nivel de conducta, las cuestiones de implementacin como el rendimiento no deberan abordarse en este punto. Dado que la construccin de los diagramas pueden llevar mucho tiempo, los desarrolladores deben centrarse en problemticas o funcionalidad general primero. Los diagramas de secuencia de las partes del sistema que son simples o bien definidas podra no parecer una buena inversin de los recursos de anlisis, sino que tambin se debe hacer para evitar pasar por alto algunas de las decisiones clave. Heurstica para dibujar diagramas de secuencia

La primera columna debe corresponder al actor que inicia el caso de uso.

La segunda columna debe ser un objeto lmite (que el actor utiliza para iniciar el caso de uso).

La tercera columna debe ser el objeto de control que gestiona el resto de los casos de uso.

Los objetos de control son creados por objetos lmite iniciando el caso de uso.

Los objetos lmite son creados por objetos de control.

Los objetos de entidad son accesibles objetos de control y lmite.

Los objetos entidad nunca acceder a objetos lmite o de control; esto hace ms fcil compartir objetos entidad a travs de casos de uso.

5.4.5 Modelado interacciones entre objetos con tarjetas CRC

Una alternativa para la identificacin de las interacciones entre objetos son las tarjetas CRC [Beck y Cunningham, 1989]. La tarjetas CRC (CRC es sinnimo de clase, responsabilidades y colaboraciones) fueron inicialmente introducido como una herramienta para la enseanza de conceptos orientados a objetos para los principiantes y para desarrolladores experimentados que no estn familiarizados con la orientacin a objetos. Cada clase se representa con una tarjeta (Llamada tarjeta CRC). El nombre de la clase se representa en la parte superior, con sus responsabilidades en la columna izquierda, y los nombres de las clases que necesitan para llevar a cabo sus responsabilidades se representan en la columna de la derecha. La Figura 5-12 muestra dos tarjetas para las clases ReportEmergencyControl e Incident. Las tarjetas CRC pueden ser utilizados durante las sesiones de modelado con los equipos. Los participantes, tpicamente una mezcla de desarrolladores y expertos del dominio de aplicacin, irn a travs de un escenario e identificarn las clases que estn involucrados en la realizacin del escenario. Por ejemplo una tarjeta se pone sobre la mesa. A continuacin se le asignan responsabilidades, se asignan a cada clase el escenario en donde se despliega y los participantes negocian las responsabilidades de cada objeto. Los colaboradores llenan la columna conforme las dependencias con otras tarjetas se identifican. Las tarjetas se modifican o son dejadas a un lado mientras se exploran nuevas alternativas. Las tarjetas nunca se tiran, porque los bloques de construccin para las alternativas del pasado se pueden volver a utilizar cuando nuevas ideas se ponen sobre la mesa.

Figura 5-12 Ejemplos de tarjetas CRC para las clases ReportEmergencyControl e Incident.

Tarjetas CRC y los diagramas de secuencia son dos representaciones diferentes para el apoyo al mismo tipo de actividad. Los diagramas son una mejor herramienta para un modelador nico o para documentar una secuencia de interacciones, ya que son ms precisos y compactos. Las tarjetas CRC son una mejor herramienta para un grupo de desarrolladores depurando e iterando una estructura de objetos durante una tormenta de ideas, porque son ms fciles de crear y modificar.

5.4.6 Identificacin de las Asociaciones

Mientras que los diagramas de secuencia permiten a los desarrolladores representar las interacciones entre los objetos a travs del tiempo, los diagramas de clases permiten a los desarrolladores describir las interdependencias de los objetos. Describimos la Notacin UML de los diagramas de clases en el Captulo 2, Modelado con UML, y se usan en todo el libro para representar varios artefactos del proyecto (por ejemplo, actividades, entregas). En esta seccin, se discute el uso de diagramas de clases para representar las asociaciones entre objetos. En la Seccin 5.4.8, se discuten el uso de diagramas de clases para representar atributos de los objetos.

Una asociacin muestra una relacin entre dos o ms clases. Por ejemplo, un FieldOfficer escribe un EmergencyReport (ver Figura 5-13). La identificacin de asociaciones tiene dos ventajas. En primer lugar, aclara el modelo de anlisis, haciendo relaciones entre los objetos explcitos (Por ejemplo, un EmergencyReport puede ser creado por un FieldOfficer o un Dispatcher). En segundo lugar, se permite al desarrollador descubrir casos lmite asociados con los enlaces. Los casos lmite son excepciones que deben aclararse en el modelo. Por ejemplo, es intuitivo asumir que la mayora de los EmergencyReports son escritos por un FieldOfficer. Sin embargo, el sistema soportar EmergencyReports duplicados? El sistema permitir EmergencyReports annimos? Estas cuestiones deben ser investigadas durante el anlisis al discutirlos con el cliente o con los usuarios finales.

Figura 5-13 Un ejemplo de asociacin entre el EmergencyReport y los FieldOfficer clases.

Las asociaciones tienen varias propiedades:

Un nombre para describir la asociacin entre las dos clases (por ejemplo, writes en Figura 5-13). Los nombres de la Asociaciones son opcionales y no necesitan ser nicos.

Un rol en cada extremo, la identificacin de la funcin de cada clase con respecto a la asociacin (por ejemplo, el autor es el papel desempeado por FieldOfficer en la asociacin writes).

Una multiplicidad en cada extremo, la identificacin de la posible nmero de casos (por ejemplo, * indica una FieldOfficer puede escribir cero o ms EmergencyReports, mientras que 1 indica que cada EmergencyReport tiene exactamente un FieldOfficer como autor). Inicialmente, las asociaciones entre objetos entidad son los ms importantes, ya que revelan ms informacin sobre el dominio de aplicacin. De acuerdo a la heurstica de Abbott (vase Tabla 5-1), las asociaciones pueden ser identificados examinando verbos y frases verbales que denotan un estado (Por ejemplo, ha, es parte de, gestiona, informa, produce, aparece en el, habla, incluye). Cada asociacin debe tener nombre, y las funciones se deben asignar a cada extremo.

La heurstica para identificar asociaciones

Examinar las frases verbales.

Nombrar Asociaciones y Roles precisamente.

Utilice calificadores tan a menudo como sea posible para identificar nombres y atributos clave.

Eliminar cualquier forma de asociacin que se pueda obtener de otras asociaciones.

No te preocupes por la multiplicidad hasta que el conjunto de las asociaciones es estable.

Demasiadas asociaciones hacen un modelo ilegible.

El modelo de objetos incluir inicialmente demasiadas asociaciones si los desarrolladores incluyen todas

Las asociaciones identificadas tras el examen de las frases verbales. En la figura 5-14, por ejemplo, identificamos dos relaciones: la primera entre un Incident y el EmergencyReport que desencaden su creacin; la segunda entre el Incident y la presentacin de informes por el FieldOfficer. Teniendo en cuenta que el EmergencyReport y FieldOfficer ya tienen un modelado de asociacin de autora, el asociacin entre Incident y FieldOfficer no es necesario. La adicin innecesaria de asociaciones complica el modelo, lo que lleva a los modelos incomprensibles e informacin redundante.

La mayora de los objetos entidad tienen una caracterstica de identificacin usada por los actores para acceder a ellos. FieldOfficer y Dsipatcher tienen un nmero de placa. Incident y Reports se les asignan nmeros y se archivan por fecha. Una vez que el modelo de anlisis incluye la mayora de las clases y asociaciones, los desarrolladores deben ir a travs de cada clase y comprobar la forma en que es identificada por los actores y en qu contexto. Por ejemplo, Son los nmeros de placa de los FieldOfficer nicos en todo el universo? En toda la ciudad? En una estacin de polica? Si son nicos a travs de las ciudades, Puede el sistema FRIEND conocer informacin sobre FieldOfficer de varias ciudades? Este enfoque puede ser formalizado por examinar cada clase individual y la identificacin de la secuencia de las asociaciones que tienen que estar recorrido para acceder a una instancia especfica de esa clase.

Figura 5-14 Eliminacin de asociaciones redundantes. La recepcin de un EmergencyReport desencadena la creacin de un Incidente por un Dispatcher. Dado que el EmergencyReport tiene una asociacin con el FieldOfficer que lo escribi, no es necesario mantener una asociacin entre FieldOfficer e Incident.

5.4.7 Identificacin de Agregaciones

Las agregaciones son tipos especiales de asociaciones que denotan una relacin todo-parte. Por ejemplo, una estacin de bomberos est formada por una serie de bomberos, carros de bomberos, ambulancias, y un auto lder. Un Estado se compone de una serie de condados que estn, a su vez, compuestos por un nmero de los municipios (Figura 5-15). Una agregacin se muestra como una asociacin con un diamante en el lado del todo.

Hay dos tipos de agregacin, composicin y comparticin. Un diamante relleno denota composicin. Una composicin de agregacin indica que la existencia de las partes depende el conjunto. Por ejemplo, un condado de siempre forma parte exactamente de un Estado, un municipio es siempre parte de un Condado. Como las fronteras polticas no cambian a menudo, un municipio no ser parte de o estar compartido con otro Condado (al menos, en el tiempo de vida del sistema de respuesta de emergencia).

Un diamante hueco denota una relacin agregacin compartida, indica que la totalidad y las partes pueden existir independientemente. Por ejemplo, aunque un coche de bomberos es parte de a lo sumo un Bombero en el momento, puede ser reasignado a un Bombero diferente durante su tiempo de vida.

Figura 5-15 Ejemplos de agregaciones y composiciones (diagrama de clases UML). Un Estado se compone de muchos condados, los cuales a su vez se componen de muchos municipios. Una estacin de bomberos incluye bomberos, carros de bomberos, ambulancias, y un auto lder.

Las asociaciones de agregacin se utilizan en el modelo de anlisis para denotar conceptos todo-parte. Asociaciones de agregacin agregan informacin al modelo de anlisis sobre cmo la contencin conceptos en el dominio de aplicacin pueden ser organizados en una jerarqua o en un grafo dirigido. Las agregaciones se utilizan a menudo en la interfaz de usuario para ayudar al usuario navegar a travs de muchas instancias. Por ejemplo, en la figura 5-15, FRIEND podra ofrecer una representacin del rbol para el Dispatcher para encontrar los condados dentro de un Estado o los municipios de un condado especfico. Sin embargo, como sucede con muchos conceptos de modelado, es fcil sobresaturar al modelo. Si no est seguro de que la asociacin que est describiendo es un concepto todo-parte, es mejor modelarlo como una asociacin uno-a-muchos, y volver a l ms tarde, cuando usted tiene una mejor comprensin del dominio de la aplicacin.

5.4.8 Identificacin de atributosLos atributos son propiedades de los objetos individuales. Por ejemplo, un EmergencyReport, como se describe En la Tabla 5-2, tiene un tipo de emergencia, una ubicacin y una descripcin de la propiedad (vase la Figura 5-16). Estos se introducen por un FieldOfficer cuando reporta una emergencia y son posteriormente rastreado por el sistema. En la identificacin de propiedades de los objetos, slo los atributos relacionados con la sistema debe ser considerados. Por ejemplo, cada FieldOfficer tiene un nmero de seguro social que no es relevante para el sistema de informacin de emergencia. En lugar de ello, FieldOfficers se identifican por nmero de placa, que est representado por la propiedad badgeNumber.

Figura 5-16 Atributos de la clase EmergencyReport.

Las propiedades que estn representadas para los objetos no son atributos. Por ejemplo, cada EmergencyReport tiene un autor que est representada por una asociacin con la clase FieldOfficer. Los desarrolladores deben identificar tantas asociaciones como sea posible antes de la identificacin de los atributos para evitar confundir atributos y objetos. Los atributos tienen: Un nombre para identificarlas dentro de un objeto. Por ejemplo, un EmergencyReport puede tener un atributo reportType y un atributo emergencyType. El reportType describe el tipo de informe que se present (por ejemplo, el informe inicial, la solicitud de recursos, el ltimo informe). El emergencyType describe el tipo de emergencia (por ejemplo, fuego, trfico, otros). Para evitar la confusin, estos atributos no deben ser llamados tipo.

Una breve descripcin.

Un tipo que describe los valores legales que puede tomar. Por ejemplo, la descripcin del atributo EmergencyReport es una cadena. El atributo emergencyType es una enumeracin que puede tomar uno de tres valores: fuego, trfico, otros. Los tipos de atributos se basan en tipos bsicos predefinidos en UML. Los atributos se pueden identificar usando la heurstica de Abbott (vase la Tabla 5-1). En particular, una frase sustantivo seguido de una frase posesiva (por ejemplo, la descripcin de una emergencia) o una frase adjetivo (por ejemplo, la descripcin de emergencia) deben ser examinados. En el caso de objetos entidad, cualquier propiedad que debe ser almacenada por el sistema es un atributo candidato.

Tenga en cuenta que los atributos representan la parte menos estable del modelo de objetos. A menudo, son atributos descubiertos o aadidos tarde en el desarrollo cuando el sistema se evala por los usuarios. A menos que los atributos aadidos estn asociados con una funcionalidad adicional, los atributos aadidos no deben implicar cambios importantes en la estructura del objeto (y del sistema). Por estas razones, los desarrolladores necesitan no gastar demasiados recursos en la identificacin y detalle de los atributos que representan aspectos menos importantes del sistema. Estos atributos se pueden agregar ms tarde, cuando el modelo de anlisis o los bocetos de interfaz de usuario se validen.

Heurstica para la identificacin de los atributos

Examinar frases posesivas.

Representar estados almacenados como un atributo del objeto entidad.

Describir cada atributo.

No representar un atributo como un objeto; usar una asociacin en su lugar (vase la Seccin 5.4.6).

No pierda el tiempo describiendo los detalles finos antes de la estructura del objeto es estable.

5.4.9 Modelar el comportamiento dependiente de estados para objetos individuales

Los diagramas de secuencia se utilizan para distribuir el comportamiento a travs de los objetos e identificar operaciones. Los diagramas de secuencia representan el comportamiento del sistema desde la perspectiva de un solo caso de uso. Los diagramas de mquina de estados representan el comportamiento desde la perspectiva de un solo objeto.

Viendo el comportamiento desde la perspectiva de cada objeto le permite al desarrollador construir un mundo con una descripcin ms formal del comportamiento del objeto, y en consecuencia, para identificar casos de uso faltantes.

Al centrarse en los estados individuales, los desarrolladores pueden identificar nuevos comportamientos. Por ejemplo, al examinar cada transicin en el diagrama de mquina de estados que se desencadena por una accin del usuario, el desarrollador debe ser capaz de identificar el flujo en un caso de uso que describe la accin de transicin que el actor desencadena. Tenga en cuenta que no es necesario construir mquinas de estados para todas las clases en el sistema. Slo los objetos con una mayor vida til y un comportamiento dependiente del estado son dignos de tenerse en cuenta. Esto es casi siempre el caso de los objetos de control, con menos frecuencia para objetos entidad, y casi nunca para los objetos lmite.

La figura 5-17 muestra una mquina de estados para la clase Incident. El examen de esta mquina de estados puede ayudar al desarrollador para comprobar si hay casos de uso para la documentacin, el cierre y archivado de Incidentes. Por seguir perfeccionando cada estado, el desarrollador puede aadir detalles a las diferentes acciones del usuario que cambian el estado de un incidente. Por ejemplo, durante el estado Activo de un indicente, El FieldOfficer debera poder solicitar nuevos recursos, y los Dispatcher deben ser capaces de asignar recursos a los incidentes existentes.

Figura 5-17 mquina de estados de UML para Incident.

5.4.10 Modelando relaciones de herencia entre objetos

La Generalizacin se utiliza para eliminar la redundancia de el modelo de anlisis. Si dos o ms clases tienen atributos, acciones o comportamiento comn, las similitudes se consolidan en una superclase. Por ejemplo, los Dispatcher y FieldOfficers ambos tienen un atributo badgeNumber que sirve para identificarlos dentro de una ciudad. FieldOfficers y Dispatcher son ambos PoliceOfficers que estn asignados a diferentes funciones. Para modelar explcitamente esta similitud, presentamos una clase resumida PoliceOfficer de la cual los FieldOfficer y Dispatcher clases heredan (ver Figura 5-18).

Figura 5-18 Ejemplo de relacin de herencia (diagrama de clases UML).

5.4.11 Revisin del Anlisis de modeladoEl anlisis de modelado se construye gradualmente y de forma iterativa. El modelo de anlisis rara vez es correcto o incluso completo en la primera pasada. Varias iteraciones con el cliente y el usuario son necesarias antes de que el anlisis de modelado converja hacia una especificacin correcta utilizable por los desarrolladores para diseo e implementacin. Por ejemplo, una omisin descubierta durante el anlisis dar lugar a aadir o ampliar un caso de uso en la especificacin de requisitos, lo que puede conducir a la obtencin de ms informacin del usuario.

Una vez que el nmero de cambios en el modelo son mnimos y el alcance de los cambios localizado, el anlisis de modelado se vuelve estable. A continuacin, el anlisis de modelo se revisa, en primer lugar por el desarrolladores (es decir, revisiones internas), a continuacin, en forma conjunta por los desarrolladores y el cliente. El objetivo de la revisin es asegurarse de que la especificacin de requisitos es correcta, completa, consistente e inequvoca. Por otra parte, los desarrolladores y los clientes tambin revisan si los requisitos son realistas y verificables. Tenga en cuenta que los desarrolladores deben estar preparados para descubrir los errores de corriente abajo y hacer cambios en la especificacin. Es, sin embargo, una buena inversin para captar el mayor nmero de errores en los requisitos tan pronto como sea posible. La revisin puede ser facilitada por una lista o una lista de preguntas. A continuacin se presentan ejemplos de preguntas adaptadas de [Jacobson et al., 1999] y [Rumbaugh et al., 1991]. Se debe responder a las siguientes preguntas para asegurarse de que el modelo es correcto:

Es el glosario de objetos entidad comprensible por el usuario?

Los clases abstractas corresponden a conceptos de nivel usuario?

Estn todas las descripciones de acuerdo con las definiciones de los usuarios?

Todos los objetos de entidad y lmite tienen sustantivos nominales significativos como nombres?

Todos los casos de uso y los objetos de control tienen frases verbales significativas como nombres?

Estn todos los casos de error descritos y manipulados?Se debe responder a las siguientes preguntas para asegurarse de que el modelo es completo:

Para cada objeto: Es necesario por algn caso de uso? En qu casos de uso se crea? Es modificado?

Se destruye? Se puede acceder desde un objeto lmite?

Para cada atributo: Cundo se establece? Cul es su tipo? Puede justificarse?

Para cada asociacin: Cundo es requerido? Por qu se eligi la multiplicidad especfica?

Pueden las asociaciones con-uno-a-muchos y muchos-a-muchos multiplicidades ser justificados?

Para cada objeto de control: Tiene las asociaciones necesarias para acceder a los objetos participantes en su caso de uso correspondiente? Se debe responder a las siguientes preguntas para asegurarse de que el modelo es consistente:

Existen mltiples clases o casos de uso con el mismo nombre?

Los entidades (por ejemplo, casos de uso, clases, atributos) con nombres similares denotan conceptos similares?

Hay objetos con atributos y asociaciones similares que no estn en la misma jerarqua de generalizacin? Se debe responder a las siguientes preguntas para asegurarse de que el sistema descrito por el anlisis modelo es realista:

Existen nuevas caractersticas en el sistema? Estaban todos los estudios y prototipos construidos para garantizar su viabilidad?

Se pueden cumplir los requisitos de rendimiento y fiabilidad? Eran estos requisitos verificables por cualquier prototipo que se ejecuta en el hardware seleccionado?

5.4.12 Resumen Anlisis

La actividad de obtencin de requisitos es altamente iterativa e incremental. Se esbozan porciones de funcionalidad y se proponen a los usuarios y al cliente. El cliente agrega requisitos, critica la funcionalidad existente, y modifica los requisitos existentes. Los desarrolladores investigan los requisitos no funcionales a travs de estudio de la creacin de prototipos y la tecnologa y comprueban cada requisito propuesto. Inicialmente, la obtencin de requisitos se asemeja a una lluvia de ideas. Como la descripcin del sistema crece y los requisitos son ms concretos, los desarrolladores necesitar extender y modificar el anlisis del modelo de una manera ms ordenada para gestionar la complejidad de la informacin.

La figura 5-19 ilustra una secuencia tpica de las actividades de anlisis. Los usuarios, desarrolladores y clientes estn involucrados en el desarrollo de un modelo inicial de casos de uso. Identifican una serie de conceptos y construyen un glosario de objetos que participan. Estas dos primeras actividades fueron discutidas en el captulo anterior. El resto de actividades se describen en esta seccin. Los desarrolladores clasifican los objetos que participan en objetos entidad, lmite, y de control (Definicin de objetos entidad, Seccin 5.4.1, Definicin de objetos lmite, Seccin 5.4.2, y definicin de los objetos de control, Seccin 5.4.3). Estas actividades tienen lugar en un bucle apretado hasta que la mayora de las funcionalidades del sistema han sido identificadas como casos de uso con nombres y descripciones breves. Entonces los desarrolladores construyen diagramas de secuencia para identificar cualquier prdida de objetos (Definicin de interacciones, Seccin 5.4.4).

Cuando todos los objetos de entidad han sido nombrados y brevemente descritos, el anlisis del modelo debe permanecer bastante estable despus de su depuracin.

Figura 5-19 Las actividades de anlisis (actividades UML diagrama).

Definir asociaciones (Seccin 5.4.6), Definir atributos (Seccin 5.4.8) y Definir comportamiento basado en estados (Seccin 5.4.9) constituyen la depuracin del modelo de anlisis. Estas tres actividades ocurren en un bucle estrecho durante el cual el estado de los objetos y sus asociaciones es extrado y detallado de los diagramas de secuencia. Los casos de uso son entonces modificados a la cuenta para cualquier cambio en la funcionalidad. Esta fase puede conducir a la identificacin de una porcin adicional de la funcionalidad en forma de casos de uso adicionales. El proceso global se repite luego de manera incremental para estos nuevos casos de uso.

Durante la Consolidacin del modelo (seccin 5.4.10), los desarrolladores aaden al modelo la introduccin de los calificadores y las relaciones de generalizacin y la supresin de redundancias. Durante el Modelo de revisin (seccin 5.4.11), el cliente, los usuarios y los desarrolladores examinan el modelo para la correccin, la coherencia, la integridad, y el realismo. El cronograma del proyecto debe planificar mltiples zonas crticas para asegurar requisitos de alta calidad y para proporcionar oportunidades para aprender la actividad de los requisitos. Sin embargo, una vez que el modelo alcanza el punto donde estn la mayora de las modificaciones, el diseo cosmtico del sistema debe iniciar. Llegar un punto en donde no hay requisitos, ms problemas que se pueden anticipar, ms informacin de la creacin de prototipos, estudios de usabilidad, investigaciones tecnolgicas, o el diseo del sistema. Obtener todos los detalles correctos se convierte en un ejercicio desperdiciado: algunos de estos detalles se convertirn en irrelevantes por el prximo cambio. La administracin debe reconocer este punto e iniciar la siguiente fase del proyecto.

5.5 Gestin del anlisis

En esta seccin, se discuten temas relacionados con la gestin de las actividades de anlisis en un equipo de desarrollo multi-proyecto. El principal desafo en la gestin de los requisitos de un proyecto de este tipo es mantener la consistencia durante el uso de tantos recursos. Al final, el documento de anlisis de los requisitos debe describir un nico sistema coherente comprensible para una sola persona. En primer lugar, describimos una plantilla de documento que se puede utilizar para documentar los resultados del anlisis (Seccin 5.5.1). A continuacin, describimos la asignacin de funciones para el anlisis (Seccin 5.5.2). Despus, abordamos los problemas de comunicacin durante el anlisis. A continuacin, se abordan cuestiones relacionadas con la gestin el carcter iterativo e incremental de los requisitos (Seccin 5.5.4).

5.5.1 Documentacin del anlisis

Como vimos en el captulo anterior, las actividades de obtencin de requisitos y anlisis estn documentadas en el Documento de Anlisis de Requerimientos (RAD, Figura 5-20). La seccin 1 del RAD hasta el punto 3.5.2 se escribe durante la obtencin de requisitos. Durante el anlisis, se revisan estas secciones y se descubren ambigedades y nuevas funcionalidades. El esfuerzo principal, sin embargo, se centra en la escritura de las secciones de la documentacin del anlisis del modelo de objetos (RAD Secciones 3.5.3 y 3.5.4).

La seccin RAD 3.5.3, modelos de objetos, documenta en detalle todos los objetos que hemos identificado, su atributos, y cuando utilizamos las operaciones en los diagramas de secuencia. Como cada objeto se describe con definiciones textuales, las relaciones entre los objetos estn ilustradas en diagramas de clase. La seccin RAD 3.5.4, modelos dinmicos, documenta el comportamiento del modelo de objetos en trminos de los diagramas de mquina de estados y diagramas de secuencia. Aunque esta informacin es redundante con el modelo de casos de uso, los modelos dinmicos nos permiten representar con mayor precisin las conductas complejas, incluyendo casos de uso en los que muchos actores participan.

La RAD, una vez completado y publicado, ser lnea base y sometido bajo la gestin de configuracin. La seccin de historial de revisiones del RAD proporcionar un historial de cambios incluido el autor responsable de cada cambio, la fecha del cambio, y breve descripcin del cambio.

Documento de Anlisis de Requerimientos

1. Introduccin

2. Sistema actual

3. Sistema propuesto

3.1 Informacin general

3.2 Requisitos funcionales

3.3 Los requisitos no funcionales

3.4 Los modelos de sistema

3.4.1 Escenarios

3.4.2 Modelo de casos de uso

3.4.3 Modelo de objetos

3.4.3.1 Diccionario de datos

3.4.3.2 Los diagramas de clases

3.4.4 Los modelos dinmicos

3.4.5 Interfaz de usuario rutas de navegacin y diseo de pantallas

4. Glosario

Figura 5-20 Vista general de esquema del Documento de Anlisis de Requerimientos (RAD). Ver la Figura 4-16 para un esquema detallado.

5.5.2 Responsabilidades Asignacin

El anlisis requiere la participacin de una amplia gama de personas. El usuario destino proporciona conocimiento del dominio de aplicacin. El cliente financia el proyecto y coordina el lado usuario del esfuerzo. El analista busca el conocimiento del dominio de aplicacin y lo formaliza. Los Desarrolladores proporcionan comentarios sobre la viabilidad y el coste. El director de proyecto coordina el esfuerzo en del lado del desarrollo. Para sistemas grandes, muchos usuarios, analistas y desarrolladores pueden estar implicados, introduciendo desafos adicionales durante los requisitos de integracin y comunicacin del proyecto.

Estos retos pueden ser satisfechos mediante la asignacin de roles bien definidos y mbitos a los individuos. Hay tres tipos principales de funciones: generacin de la informacin, integracin y revisin. El usuario final es el experto en el dominio de aplicacin que genera informacin en el sistema actual, el entorno del futuro sistema, y las tareas que deben apoyar. Cada usuario corresponde a uno o ms actores y ayuda a identificar sus casos de uso asociados.

El cliente, tiene un papel de integracin, define el mbito de aplicacin del sistema basado en los requisitos del usuario. Diferentes usuarios pueden tener diferentes puntos de vista del sistema, ya sea porque que se beneficiarn de las diferentes partes del sistema (por ejemplo, un Dispatcher versus un FieldOfficer) o porque los usuarios tienen diferentes opiniones o expectativas sobre el sistema futuro. El cliente acta como un integrador de informacin del dominio de aplicacin y resuelve inconsistencias en las expectativas del usuario.

El analista es el experto en el dominio de aplicacin que modela el sistema actual y genera informacin sobre el sistema futuro. Cada analista es responsable al inicio de detallar uno o ms casos de uso. Para un conjunto de casos de uso, el anlisis identificar un nmero de objetos, sus asociaciones y sus atributos utilizando las tcnicas descritas en la Seccin 5.4. El analista es tpicamente un desarrollador con amplio conocimiento del dominio de la aplicacin.

El arquitecto, tiene un papel de integracin, unifica el caso de uso y modelos de objetos a partir de un punto de vista del sistema. Diferentes analistas pueden tener diferentes estilos de elaboracin de modelos y diferentes puntos de vista de las partes de los sistemas para los que no son responsables. Aunque los analistas trabajar juntos y lo ms probable es que resuelvan las diferencias a medida que avanzan a travs de anlisis, el papel del arquitecto es necesario para proveer la filosofa del sistema e identificar omisiones en los requisitos.

El editor de documentos es responsable de la integracin de bajo nivel del documento y del formato general del documento y su ndice.

El administrador de configuracin se encarga de mantener un historial de revisin del documento, as como la informacin de trazabilidad en relacin con otros documentos RAD (Como el Documento de Diseo del Sistema, vase el captulo 6, Diseo de Sistemas: Descomposicin del Sistema).

El revisor valida la exactitud del RAD, integridad, consistencia y claridad. Usuarios, clientes, desarrolladores, u otras personas pueden llegar a ser colaboradores en la validacin de los requisitos. Las personas que an no han sido implicados en el desarrollo suelen representar excelentes crticos, ya que son ms capaces de identificar las ambigedades y reas que necesitan aclaracin.

El tamao del sistema determina el nmero de diferentes usuarios y analistas que son necesarios para buscar y modelar los requisitos. En todos los casos, debe haber un papel integrador en el lado del cliente y uno en el lado de desarrollo. Al final, los requisitos, por grande que sea el sistema, debe ser comprensible por una sola persona con conocimientos en el dominio de la aplicacin.

5.5.3 La comunicacin sobre Anlisis

La tarea de comunicar la informacin es ms difcil durante la obtencin de requisitos y el anlisis. Los factores que contribuyen incluyen:

Diferentes experiencias de los participantes. Los usuarios, los clientes y los desarrolladores tienen diferentes mbitos de competencia y utilizan diferentes vocabularios para describir los mismos conceptos.

Diferentes expectativas de los interesados. Los usuarios, clientes y administraciones tienen diferentes objetivos al definir el sistema. Los usuarios quieren un sistema que apoya sus procesos de trabajo actuales, sin interferencia o amenaza a su posicin actual (por ejemplo, un sistema mejorado a menudo se traduce en la eliminacin de las posiciones actuales). El cliente quiere maximizar el retorno sobre la inversin. La administracin quiere entregar el sistema a tiempo. Diferentes expectativas y diferentes participaciones en el proyecto puede dar lugar a un rechazo para compartir informacin y reportar los problemas de manera oportuna.

Los nuevos equipos. La obtencin de requisitos y el anlisis a menudo marca el comienzo de un nuevo proyecto. Esto se traduce en nuevos participantes y nuevas asignaciones de equipo y, por lo tanto, en un perodo de aceleracin durante la cual los miembros del equipo deben aprender a trabajar juntos.

La evolucin del sistema. Cuando un nuevo sistema es desarrollado desde cero, trminos y conceptos relacionados con el nuevo sistema se encuentran en el flujo durante la mayor parte del anlisis y el diseo del sistema.

Un trmino puede tener un significado diferente maana. No hay mtodo de requisitos o mecanismo de comunicacin que pueda abordar los problemas relacionados con polticas internas y la ocultacin de informacin. Objetivos en conflicto y la competencia siempre sern parte de grandes proyectos de desarrollo. Algunas pautas simples, sin embargo, pueden ayudar en la gestin de la complejidad de los puntos de vista conflictivos del sistema:

Definir los territorios claramente. Definir las funciones como se describe en la Seccin 5.5.2 es parte de esta actividad. Esto tambin incluye la definicin de los foros de discusin pblicos y privados. Para ejemplo, cada equipo puede tener una base de datos de discusin, como se describe en el Captulo 3, Organizacin y Comunicacin del Proyecto, y la discusin con el cliente se hace en una base de datos separada del cliente. El cliente no debe tener acceso a la base de datos interna. Del mismo modo, los desarrolladores no deberan interferir en la poltica interna de cliente/usuario.

Definir objetivos claros y criterios de xito. La definicin compartida de objetivos verificables y criterios de xito claros y cuantificables por el cliente y los desarrolladores facilita la resolucin de conflictos. Tenga en cuenta que la definicin de un objetivo claro y verificable es una tarea trivial, dado que es ms fcil dejar los objetivos de participacin abierta. Los objetivos y los criterios de xito del proyecto se deben documentar en la Seccin 1.3 de la RAD.

Lluvia de ideas. Poner a todos los interesados en la misma habitacin y generar rpidamente soluciones y definiciones pueden eliminar muchas barreras en la comunicacin. Revisin de conductas crticas como una actividad recproca (es decir, la revisin de las prestaciones, tanto del cliente y el desarrolladores durante la misma sesin) tiene un efecto similar. La tormenta de ideas, y ms en general el desarrollo cooperativo de los requisitos, puede conducir a la definicin de anotaciones compartidas y precisas basadas en la comunicacin. Storyboards, bocetos de interfaz de usuario y diagramas de flujo de datos de alto nivel a menudo aparecen de forma espontnea. A medida que la informacin sobre el dominio de la aplicacin y el nuevo sistema se obtiene, es fundamental usar una notacin precisa y estructurada. En UML, los desarrolladores utilizan casos de uso y escenarios para la comunicacin con el cliente y los usuarios, y usan diagramas de objetos, diagramas de secuencia, y mquinas de estados para comunicarse con otros desarrolladores (ver secciones 4.4 y 5.4). Por otra parte, la ltima versin de los requisitos debe estar disponible para todos los participantes. El mantenimiento de un versin viva en lnea del documento de anlisis de requerimientos con una historia -actualizada- hasta la fecha del cambio facilita la propagacin oportuna de los cambios en todo el proyecto.

5.5.4 Iteracin sobre el Modelo de Anlisis

El anlisis ocurre manera incremental e iterativa, a menudo en paralelo con otras actividades de desarrollo tales como el diseo e implementacin del sistema. Ntese, sin embargo, que la modificacin sin restricciones y la extensin del anlisis del modelo slo puede resultar en caos, especialmente cuando un gran nmero de participantes estn involucrados. Las iteraciones y los incrementos se deben manejar con cuidado y las solicitudes de cambio rastreadas hasta los requerimientos originales. La actividad de requisitos puede ser visto como varios pasos (tormenta de ideas, solidificacin, madurez) que convergen hacia un modelo estable. Tormenta de ideas

Antes de iniciar cualquier otra actividad de desarrollo, las necesidades se identifican en una tormenta de ideas. Todo -conceptos y los trminos utilizados para referirse a ellos- cambia. El objetivo de un proceso de tormenta de ideas es generar tantas ideas como sea posible sin que necesariamente la organizarlas. Durante esta etapa, las iteraciones son rpidas y de largo alcance. Solidificacin

Una vez que el cliente y los desarrolladores convergen en una idea comn, se definen los lmites del sistema, y se acuerdan una serie de trminos estndar, el proceso de solidificacin comienza. La funcionalidad est organizada en grupos de casos de uso con sus correspondientes interfaces. Grupos de funcionalidad son asignados a los diferentes equipos que se encargan de detallar sus casos de uso correspondientes. Durante esta etapa, las iteraciones son rpidas pero localizadas. Madurez

Los cambios en el nivel superior son todava posibles pero es ms difcil, y por lo tanto, se hacen ms cuidadosamente. Cada equipo es responsable de los casos de uso y modelos de objetos relacionados con la funcionalidad que les han sido asignados. Un equipo multi-funcional, el equipo de arquitectura, hecha de representantes de cada equipo, es responsable de garantizar la integracin de los requisitos (por ejemplo, la nomenclatura). Una vez que el cliente se despide de los requisitos, la modificacin al modelo de anlisis debe dirigirse hacia las omisiones y los errores. Los Desarrolladores, en particular, el equipo de arquitectura, necesitan asegurarse de que la consistencia del modelo no se vea comprometida. El modelo de requisitos est bajo gestin de la configuracin y los cambios se deben propagar a los modelos de diseo existentes. Las iteraciones son lentas y a menudo localizadas. El nmero de caractersticas y funciones de un sistema siempre se incrementar con el tiempo. Cada cambio, sin embargo, puede poner en peligro la integridad del sistema. El riesgo de introducir ms problemas con cambios de ltima hora resulta en la prdida de informacin en el proyecto. Las dependencias entre funciones no estn capturadas; muchos supuestos son implcitos y olvidamos el momento en el que se hizo un cambio. A menudo el cambio responde a un problema, en cuyo caso no debe haber gran cantidad de presin para ponerlo en prctica, lo que resulta slo un examen superficial de las consecuencias del cambio.

Cuando se aaden nuevas caractersticas y funciones al sistema, deben ser desafiados con las siguientes preguntas: Fueron solicitados por el cliente? Son necesarias, o son adornos? Deben de ser tratadas por separado, enfocndonos en una utilera o son parte base del sistema? Son cambios de requisitos esenciales o funciones opcionales? Cul es el impacto de los cambios en las funciones existentes en trminos de consistencia, la interfaz, la fiabilidad? Cuando los cambios son necesarios, el cliente y el desarrollador definen el alcance del cambio y su resultado deseado y cambian el modelo de anlisis. Teniendo en cuenta que existe un modelo de anlisis completo para el sistema, la especificacin de la nueva funcionalidad es ms fcil (aunque su aplicacin es ms difcil).

5.5.5 Visto bueno del cliente

La despedida al cliente representa la aceptacin del modelo de anlisis (como lo demuestra el documento de anlisis de requisitos) por el cliente. El cliente y los desarrolladores convergen en una sola idea y estn de acuerdo sobre las funciones y caractersticas que el sistema va a tener. Adems, se deben poner de acuerdo sobre: una lista de prioridades

un proceso de revisin

una lista de criterios que se utilizarn para aceptar o rechazar el sistema

un calendario y un presupuesto. Dar prioridad a las funciones del sistema permite a los desarrolladores entender mejor las expectativas del cliente. En su forma ms simple, permite a los desarrolladores separar las campanas y silbatos de caractersticas esenciales. Tambin permite a los desarrolladores ofrecer el sistema en mdulos elementales: funciones esenciales se entregan primero, secciones adicionales se entregan en funcin de la Evaluacin de la porcin anterior. Incluso si el sistema se va a suministrar como un solo paquete completo, se da prioridad a las funciones permitiendo al cliente comunicar con claridad lo que es importante para l y donde debe estar el nfasis del desarrollo. Figura 5-21 proporciona un ejemplo de un esquema de prioridad. A cada funcin se le asignar una de las siguientes prioridades

Alta prioridad Las caractersticas de alta prioridad debe ser demostradas con xito durante la aceptacin del cliente.

Media prioridad Las caractersticas de media prioridad se deben tener en cuenta en el diseo del sistema y el diseo de objetos. Se llevarn a cabo y se demuestran en la segunda iteracin del desarrollo del sistema.

Baja prioridad Las caractersticas de baja prioridad ilustra cmo el sistema se puede ampliar a un plazo ms largo.

Figura 5-21 Un ejemplo de un esquema de prioridad para los requisitos.

Despus de que el cliente da el visto bueno, los requisitos son la lnea base y se utilizan para definir el costo estimado del proyecto. Los requisitos continan cambiando despus del cierre de sesin, pero estos cambios son sujetos a un proceso de revisin ms formal. Los requisitos cambian, ya sea debido a errores, omisiones, cambios en el entorno operativo, los cambios en el dominio de aplicacin, o cambios en la tecnologa. La definicin de un proceso de revisin por adelantado permite cambios que se comunicarn a travs del proyecto y reduce el nmero de sorpresas en las etapas posteriores. Tenga en cuenta que un cambio en el proceso no tiene por qu ser burocrtico o una sobrecarga excesiva. Puede ser tan simple como nombrar una persona responsable de recibir las solicitudes de cambio, aprobar los cambios, y el seguimiento de su aplicacin. La figura 5-22 ilustra un ejemplo ms complejo en el que los cambios estn diseados y revisados por el cliente antes de su ejecucin en el sistema. En todos los casos, reconociendo que los requisitos no se pueden congelar (pero son la lnea base) se beneficiar al proyecto.

Figura 5-22 Ejemplo de un proceso de revisin (diagrama de actividades UML).

La lista de los criterios de aceptacin se revisa antes del visto bueno. La obtencin de requisitos y la actividad de anlisis aclaran muchos aspectos del sistema, incluyendo los requisitos no funcionales con la que el sistema debe cumplir y la importancia relativa de cada funcin. Por la re expresin de los criterios de aceptacin en el cierre de sesin, el cliente se asegura de que los desarrolladores actualizan casi cualquier cambio en las expectativas de los clientes. El presupuesto y el calendario se revisan despus de que el anlisis del modelo se vuelve estable. Nosotros describimos en el Captulo 14, Gestin de Proyectos, las cuestiones relacionadas con el costo de estimacin. Ya sea que el cliente cierre de sesin es un acuerdo contractual o si el proyecto ya est regido por un contrato previo, es un hito importante en el proyecto. Representa la convergencia de cliente y el desarrollador en un solo conjunto de definiciones funcionales del sistema y un nico conjunto de expectativas. La aceptacin del documento de anlisis de requerimientos es ms crtica que cualquier otro documento, dado que muchas actividades dependen del anlisis del modelo.