Puds Libro

7/28/2019 Puds Libro

1/55

El Proceso Unificado de Desarrollo de Software1

CAPTURA DE REQUISITOS: DE LA VISIN A LOS REQUISITOS

La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difciles, loque se debe construir. Proceso que no es nada sencillo y que por lo tanto es muy comn suuso por los equipos de proyectos.

6.1 Por qu la captura de requisitos es complicada

La principal razn es que los usuarios del software, que realizan los desarrolladores, son unafuente imperfecta de informacin. Con frecuencia no saben cuales son los requisitos y muchomenos, cmo especificarlos de una forma precisa.

Entonces surgi el analista, encargado de obtener una lista de requisitos de cada usuario paracomponer una, completa, correcta y consistente.

A pesar de ello, los usuarios sugeran una gran cantidad de cambios cuando el proyecto habaavanzado ya bastante, lo cual produce un impacto importante en los plazos y el coste.

No basta entrevistarnos con los usuarios para saber que quieren, lo ms importe es quenuestro sistema de soporte a la misin para la cual se construye. Aunque claro, este valorcambiar con el tiempo, con el negocio, etc.

6.2 El objeto del flujo de trabajo de los requisitos

Su propsito es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante unadescripcin de los requisitos del sistema (es decir, las condiciones o capacidades que elsistema debe cumplir) suficientemente buena como para que pueda llegarse a un acuerdoentre el cliente y los desarrolladores sobre qu debe y qu no debe hacer el sistema. Paraalcanzar este objetivo debemos usar el lenguaje del cl ientepara describir los resultados,

evitando incluir detalles sobre el funcionamiento interno del sistema

6.3 Visin general de la captura de requisitos

As como cada proyecto de software es diferente, ya que ste debe acomodarse a losrequerimientos de las diferentes empresas que lo puedan necesitar, as tambin la captura derequisitos tiene diferentes puntos de partida. Podemos tener clientes que han podidodesarrollar una especificacin de requisitos completa y detallada, y en el otro extremo, clientesque tiene una vaga nocin de lo que debera ser su sistema. Esto hace que los analistas debenser capaces de adaptar sus tcnicas a la captura de requisitos en cada situacin. Ademsdeben seguir un flujo de trabajo arquetpico que comprende lo siguiente:

Enumerar los requisitos candidatos

Un conjunto de requisitos candidatos es una lista de ideas que se puede decidirimplementar en una versin futura del sistema. Esta lista de caractersticas crece a medidaque se aaden nuevos elementos y mengua cuando algunas caractersticas se conviertesen requisitos y se transforman en casos de uso. Esta lista es usada slo para laplanificacin del trabajo.Cada caracterstica tiene un nombre corto y una breve explicacin o definicin, informacinsuficiente para poder hablar de ella durante la planificacin del producto.

Comprender el contexto del sistema


2/55


3/55


Fase de Elaboracin.Se capturan la mayoria de los requisitos restantes para estimar el tamao del esfuerzode desarrollo requerido. El objetivo es capturar el 80% de los requisitos y describir lamayora de los casos de uso.

Fase de ConstruccinLos requisitos restantes se capturan e implementan.

Fase de Transicin.Hay captura de datos si los requisitos cambian.

6.5 La comprensin del contexto del sistema mediante un modelo del dominio

6.5.1 Modelo de Dominio

Captura los tipos ms importantes de objetos en el contexto del sistema. Los objetos deldominio o clases representan las cosas que existen o los sucesos que ocurren en el entorno

del sistema, pueden obtenerse de una especificacin de requisitos o por una entrevista con losexpertos del dominio, las clases aparecen de 3 formas:

Objetos del Negocio Representan cosas que se manipulan en el negocio (pedidos,cuentas, matriculas, reservas, etc).

Objetos del Mundo Real y Conceptos El sistema les debe hacer un seguimiento(clientes, paquetes tursticos, comprobantes de compra, venta, fichas de matricula, etc.)

Sucesos que ocurrirn o han ocurrido (horas de llegada, fechas de envi, etc)

El modelo del dominio se describe con diagramas de clases, los que muestran los actores,clases y su interaccin.

6.5.2 Desarrollo de un modelo de dominio

El modelado del dominio se realiza en reuniones organizadas por los analistas las cualesdeben incluir a expertos del dominio y a gente con experiencia en modelado.

El objetivo del modelado es comprender y describir las clases ms importantes dentro delcontexto del sistema. Los dominios de tamao moderado requieren de 10 a 50 clases, el restode clases que los analistas extraen del dominio se guardan como definiciones en un glosario detrminos, los cuales pueden ser suficientes para los dominios de negocio muy pequeos.

El glosario y el modelado ayudan a utilizar un vocabulario comn para compartir elconocimiento con los otros y el proceso de ingeniera sea ms fcil.

El modelado de dominio debera contribuir a la comprensin del problema que el sistemaresuelve en relacin a su contexto.

6.5.3 Uso del modelado de dominio

Las clases de dominio y el glosario de trminos se usan en el desarrollo de casos de uso y deanlisis. Se usan:

Al escribir los casos de usos y al disear la interfaz de usuario. Para sugerir clases internas al sistema en desarrollo durante el anlisis.


4/55


Sin embargo desarrollar un modelo del negoc io es una alternativa ms potente quedesarrollar un modelo de dominio

6.6. La comprensin del contexto del sistema mediante un modelo del negocio

El mod elado d el negoc ioes una tcnica para comprender los procesos de negocio de laorganizacin. Participa en casos de uso de ms alto nivel que deberamos esquematizarbrevemente.El objetivo es identificar los casos de uso del software y las entidades de negocio relevantesque el software debe soportar, de forma que podramos modelar slo lo necesario paracomprender el contexto. El resultado de esta actividad es un modelo del dominio derivadode la comprensin del funcionamiento del sistemade negocio que lo rodea.

6.6.1. Qu es un modelo del negocio?

Un modelo de casos de uso del negocio describe los procesos de negocio de una empresaen trminos de casos de uso del negocio y actores del negocio que se corresponden con

los procesos del negocio y los clientes respectivamente. Al igual que el modelo de casos deuso para un sistema software, el modelo de casos de uso del negocio presenta un sistema(en este caso, el negocio) desde la perspectiva de su uso y esquematiza cmo proporcionavalor a sus usuarios (en este caso, sus clientes y socios).

El modelo de casos de uso del negocio se describe mediante diagramas de casos de uso.

Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cmo cadacaso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores queutilizan un conjunto de entidades del negocio y de unidades de trabajo. Cada realizacin deun caso de uso del negocio puede mostrarse en diagramas de interaccin y diagramas de

actividad.

Una entidad del negocio representa algo, como una factura, que los trabajadores toman,inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio. Una unidad detrabajo es un conjunto de esas entidades que conforma un todo reconocible para un usuariofinal.

Las entidades del negocio y las unidades de trabajo se utilizan para representar los mismostipos de conceptos que las clases del dominio. Por tanto podemos confeccionar undiagrama de las entidades del negocio. Tambin tendremos otros diagramas para mostrarlos trabajadores, sus interacciones y cmo utilizan las entidades de negocio y las unidades

de trabajo.

Cada trabajador, entidad del negocio y unidad de trabajo pueden participar en la realizacinde ms de un caso de uso del negocio.

6.6.2. Como desarrollar un modelo del negocio

1. Los modeladores del negocio deben confeccionar un modelo de casos de uso delnegocio que identifique los actores del negocio y los casos de uso del negocio queutilicen los actores. Este modelo de casos de uso del negocio permite a los modeladorescomprender mejor que valor proporciona el negocio a sus actores.

2. Los modeladores deben desarrollar un modelo de objetos del negocio compuesto portrabajadores, entidades del negocio y unidades de trabajo que juntos realizan los casos


5/55


de uso del negocio. Se asocian a estos diferentes objetos las reglas del negocio y otrasnormas impuestas por el negocio. El objetivo es crear trabajadores, entidades delnegocio y unidades de trabajo que realicen los casos de uso del negocio de la manerams eficaz posible es decir rpidamente, con precisin y con un coste bajo.

6.6.3. Bsqueda de casos de uso a partir de un modelo del negocio

En primer lugar, el analista identifica un actor por cada trabajador y por cada actor delnegocio (es decir cada cliente) que se convertir en usuario del sistema de informacin.Cada trabajador (y cada actor del negocio) que vaya a ser usuario del sistema deinformacin requerir un soporte por parte del mismo.Para cada trabajador identificamos todas las realizaciones de casos de uso del negociodiferentes en las que participa. El trabajador cumple un papel en cada una de forma muyparecida al papel que desempea una clase en cada realizacin de caso de uso.

Una vez que hemos encontrado todos los roles de un trabajador o de un actor del negocio,uno por cada caso de uso del negocio en el que participa, podemos encontrar los casos deuso de los actores del sistema en el sistema de informacin. Cada trabajador y cada actor

del negocio se corresponden con un actor del sistema de informacin.La manera ms directa de identificar un conjunto tentativo de casos de uso es crear un casode uso para el actor correspondiente a cada rol de cada trabajador y de cada actor delnegocio. Como resultado obtendremos para cada caso de uso del negocio un caso de usopor cada trabajador y por cada actor del sistema.

6.7. Requisitos adicionales

Son fundamentalmente requisitos no funcionales que no pueden asociarse a ningn casode uso en concreto en cambio cada uno de estos requisitos tienen impacto en varios casos

de uso o en ninguno. Algunos ejemplos son el rendimiento, las interfaces y los requisitos dediseo fsico as como las restricciones arquitectnicas de diseo e implementacin. Losrequisitos adicionales se capturan de forma muy parecida a como se haca en laespecificacin de requisitos tradicional. Despus se utilizan durante el anlisis y el diseojunto al modelo de casos de uso.

Un requisito de interfaz especifica la interfaz con un elemento externo con el cual debeinteractuar el sistema o que establece restricciones condicionantes en formatos, tiempos uotros factores de relevancia en esa interaccin.

Un requisito fsico especifica una caracterstica fsica que debe poseer un sistema como su

material, forma, tamao o peso. Por ejemplo puede utilizarse para representar requisitoshardware como las configuraciones fsicas de red requeridas.

Una restriccin de implementacin especifica o limita la codificacin o construccin de unsistema. Son ejemplos los estndares requeridos, las normas de codificacin, los lenguajesde programacin, polticas para la integridad de la base de datos, limitaciones de recurso yentornos operativos.

PREGUNTAS

1. Cules s on los paso s d el f lujo de tr abajo arqu etpic o p ara la c aptur a derequis i tos?

2. Ques un modelo de dom inio ?3. Ques un modelo del nego cio ?4. Cules son los pas os par a la bsqued a de cas os de Uso del Neg oc io?


6/55


CAPTURA DE REQUISITOS COMO CASOS DE USO

7.1 Introduccin

En la fase de requisitos se necesito un modelo, y para construir ese modelo, se usan los casos

de uso debido a que los casos de uso nos permiten representar los requisitos funcionales de unSistema.Mediante la utilizacin de Casos de uso los analistas estn obligados a pensar en trminos dequienes son los usuarios y que necesidades u objetivos de la empresa pueden cumplir.Adems los Casos de Uso permiten dirigir el resto de los trabajos de software haciendo de estacaracterstica la principal razn para ser aceptado por la mayora de los mtodos de laingeniera moderna del software.Se describir el flujo de trabajos en tres pasos:

1.-Los artefactos creados en el flujo de los requisitos.2.-Los trabajadores participantes en el flujo de los requisitos.

3.-El flujo de trabajo de captura de requisitos, incluyendo cada actividad en mas detalle.

Se comenzara a analizar los Artefactos y Trabajadores.

7.2 Artefacto:Es un trmino general para cualquier tipo de descripcin o informacin creada, producida,cambiada o utilizada por los trabajadores durante su trabajo con el sistema.Un artefacto puede ser un modelo, un elemento de un modelo o un documento. En el flujo detrabajo de los requisitos, los artefactos son fundamentalmente el modelo de casos de uso y suscasos de uso ya que estos permiten la captura de requisitos funcionales.

7.2.1 Artefacto: Modelo de Casos de UsoEl modelo de casos de uso permite determinar a los usuarios y analistas que condicionesy posibilidades deben cumplir nuestro sistema, constituye la entrada fundamental para elanlisis el diseo y las pruebas. Este modelo esta formado por un conjunto de actores ycasos de uso.Si el modelo es grande se puede dividir en paquetes o en otros casos de uso.

7.2.2 Artefacto: ActorEl modelo de Casos de Uso tambin representan los roles de los usuarios a travs de losactores, es decir modela lo que un usuario hace en el sistema esto determinando elentorno externo al Sistema.

7.2.3 Caso de UsoCada forma en que los actores usan el sistema se representa con un caso de uso. Loscasos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar unresultado de valor para sus actores.

Es un conjunto de acciones que realiza el sistema produciendo un resultado valioso paraalguien en el sistema. Los casos de uso son verbosUna instancia de un caso de uso es lo que el sistema lleva a cabo cuando obedece a uncaso de uso, normalmente un instancia de un actor invoca una instancia de caso de uso,pero la instancia de caso de uso no interacta con otras instancias de caso de uso. Cadainstancia es atmica ( se ejecuta en su totalidad o no se ejecuta)


7/55


7.2.3.1 Flujo de sucesosViene a ser la secuencia de acciones para cada caso de uso, especifica lo que el sistemahace y como el sistema interacta con los actores cuando se lleva a cabo un caso de uso.

7.2.3.2 Requisitos especialesEs la descripcin textual que agrupa los requisitos del tipo de los requisitos nofuncionales sobre el caso de uso

7.2.4 Artefacto: Descripcin de la arquitectura (Vista del modelo de casos de uso)Contiene una vista de la arquitectura del modelo de casos de uso, que representa loscasos de uso significativos para la arquitectura.

7.2.5 Artefacto: glosarioSirven para definir trminos comunes e importantes, conceptos y nociones que losanalistas usan al describir el sistema para evitar confusiones.Se puede obtener de un modelo de negocios o de un modelo del dominio, ya estncentrados en el sistema y no el contexto.

7.2.6 Artefacto: Prototipo de interfaz de usuarioNos ayudan a comprender y especificar las interacciones entre los actores humanos y elsistema durante la captura de los requisitos, nos ayuda a comprender mejor los casos deuso y a desarrollar un interfaz grafica mejor.

7.3 TrabajadoresEs la representacin de un ser humano con ciertas capacidades que se requiere en un caso deuso para el desarrollo de software.Un trabajador no corresponde a un cargo especfico dentro de la empresa y una mismapersona puede estar asignada a diferentes trabajadores durante un proyecto.

Los trabajadores pueden ser:

7.3.1 Trabajador Analista de Sistema.Es el encargado de la captura de los requerimiento funcionales del sistema es decir es elresponsable de encontrar los actores y casos de uso, tambin es responsable del glosarioy de los los requisitos no funcionales.Para cada Sistema hay un analista pero el analista no es responsable de cada caso enparticular.

7.3.2 Trabajador: Especificador de caso de usoEl analista esta acompaado de otros trabajadores para detallar los casos de uso a

estos trabajadores se les denomina Especificadores de casos de uso.Cada especificar necesita trabajar estrechamente con los usuarios reales de sus casos deuso

7.3.3 Diseador de interfaz de usuarioEs el encargado de la forma visual de la interfaces de usuario, lo cual puede implicar eldesarrollo de prototipos para cada actor. El diseador esta encargado del diseo de lainterfaz de usuario pero no de la implementacin.

7.3.4 Trabajador: arquitecto.- Participa en el flujo de trabajo de los requisitos paradescribir la vista de arquitectura del modelo de casos de uso (es duna entrada importante

para planificar las iteraciones).


8/55


7.4. Flujo de trabajo.-Es una secuencia de actividades que estn ordenadas, as que una actividad produce unasalida que sirve de entrada a la siguiente actividad, donde el orden no es estricto.

Analista de

SistemasEncontrar Actores

y casos de uso

Arquitecto

Especificador

de casos de

Diseador de

interfaces de usuario

Encontrar el modelo

de casos de uso

Priorizar loscasos de uso

Detallar un

caso de uso

Prototipar la

interface de usuario

Esta figura muestra la captura de requisitos en forma de casos de uso, incluyendo trabajadoresparticipantes y sus actividades. El analista de sistemas se asegurara que todas listar todas lascaractersticas y el modelo de dominio o de negocio, entonces el arquitecto identificara loscasos de uso relevantes, hecho esto los especificadores de casos de uso describen todos loscasos de uso que se han priorizado, los diseadores de interfaces sugieren las interfaces deusuario segn los casos de uso, entonces el analista de sistemas reestructurara el modelo decasos de uso definiendo generalizaciones para su entendimiento. Esta primera iteracinproduce una primera versin del modelo de casos de uso, la cual se completa y se mejora atravs de las iteraciones.

7.4.1. Actividad: encontrar actores y casos de uso.- El analista ejecuta esta actividad para:o Delimitar el sistema de su entorno.o Esbozar quin y qu interactan con el sistema, y que funcionalidad se espera con

el sistema.o Captura y definir un glosario de trminos comunes esenciales para la creacin

descripciones detalladas de las funcionalidades del sistema.Esta actividad consta de 4 pasos: Encontrar los actores. Encontrar los casos de uso. Describir brevemente cada caso de uso. Describir el modelo de caso uso completo (este pasos tambin incluye la

preparacin de un glosario de trminos).Estos pasos no tienen ningn orden en particular, por ejemplo el diagrama de casos de usopuede actualizarse tan pronto como se identifique un actor o un caso de uso.

7.4.1.1.- Encontrar los actores.- El analista puede asignar un actor a cada actor delnegocio y un actor a cada cliente de negocio que utilizar la informacin del sistema, sedebe identificar los actores que representan sistemas externos y los actores para elmantenimiento y operacin del sistema.Hay 2 criterios a la hora de elegir candidatos a actores: primero, identificar un usuario quepueda representar al actor candidato, esto nos ayudara a encontrar a los actoresrelevantes y eliminar los actores fantasmas, segundo, Debera existir una coincidencia

mnima entre los roles que desempean las instancias de los diferentes actores enrelacin con el sistema, en caso de que existan actores con los mismos roles, entonces sedeber inatentar combinar los papeles en un conjunto de roles que asignaremos a un


9/55


actor, o encontrar un actor generalizado que tenga los roles a los actores que se solapan,Por ejemplo el comprador y el vendedor pueden ser especializaciones del actor cliente delbanco.El analista de sistemas da nombre a los actores y describe a brevemente sus papeles,esta debe esbozar sus necesidades y responsabilidades.

7.4.1.2.- Encontrar los casos de uso.- Se propone un caso de uso para cada rol deltrabajador que participa en realizacin de casos de uso del negocio y que utilizara lainformacin del sistema, o los identificara a travs de los talleres con los clientes yusuarios, tambin puede utilizar las entrevistas, el actor necesita normalmente casos deuso para soportar su trabajo de creacin, cambio, rastreo, eliminacin o estudio de losobjetos de negocio, o en otras formas de representacin el actor puede necesitarinformarle al sistema de algunos sucesos que a realizado. Hay recordar que intentamoscrear casos de uso fciles de modificar, revisar probar y manejar unitariamente, Elegimosel nombre para cada caso de uso de forma que nos haga pensar en la secuencia deacciones que aade valores a un actor, y debe reflejar cual es el objetivo de la interaccinentre el actor y el sistema, las cuales pueden especificarse en un caso de uso o varios.

Existen criterios tiles para identificacin de casos de uso:-Resultado de valor: Cada ejecucin satisfactoria de un caso de uso debe proporcionaralgn valor al actor para alcanzar su objetivo.

-Un actor en concreto: Identificando casos de uso que proporcionen valores a usuariosindividuales reales, nos aseguramos que los casos de uso no se harn grandes al igualque con los actores.

7.4.1.3.-Describir brevemente cada caso de uso.- Esto se puede realizar con algunasfrases que resumen las acciones con algunos anotes en los casos de uso y mas tarde conuna descripcin paso a paso de lo que el sistema requiere.

7.4.1.4.-Descripcin del modelo de casos de uso en su totalidad.- En este pasonecesitamos explicar como estn relacionados entre si los casos de uso y los actores ycomo juntos constituyen el modelo de casos de uso, se elige los diagramas que describenmas claramente el sistema.Para asegurar la consistencia cuando se describen varios casos de usoconcurrentemente, resulta prctico desarrollar un glosario de trminos.Luego terminado la descripcin general se convoca a una revisin informal con los que noforman parte del equipo de desarrollo (cliente, usuario) para determinar:

-Se han capturado como casos de uso todos los requisitos funcionales necesarios.-La secuencia de acciones es correcta, completa y comprensible para cada caso de

uso.-Se identifica algn caso de uso que no proporcione valor. Si es as ese caso de uso

deber reconsiderarse.

7.4.2. Actividad: priorizar casos de uso.- El propsito de esta actividad es proporcionarentradas a la priorizacion de los casos de uso para determinar cuales son necesarios para eldesarrollo en las primeras iteraciones, y cuales pueden dejarse para ms tarde. La vista de laarquitectura del modelo de casos de uso significativos desde el punto de vista de laarquitectura.

7.4.3. Detallar un caso de uso.- El objetivo principal de detallar cada caso de uso es describir

su flujo de sucesos en detalle, incluyendo como comienza, termina e interacta con los actores,con el modelo de casos de uso y los diagramas de casos de uso asociados como punto decomienzo el especificador de casos de uso individual puede describir cada caso de uso a


10/55


detalle en una especificacin precisa de la secuencia de acciones. El especificador de casos deuso deber precisar la siguiente secuencia de acciones.

-Como estructurar la descripcin de para especificar todas las vas alternativas del caso deuso.

-Que incluir en la descripcin de caso de uso.-Como formalizar la descripcin de caso de uso cuando sea necesario.

Cada especificador de casos de uso debe trabajar estrechamente con los usuarios reales delos casos de uso, para lo cual les entrevistara y solicitarles que revisen la descripcin de loscasos de uso.El resultado de esta actividad es la descripcin detallada de un caso de uso en particular enforma de texto y diagrama.

7.4.3.1.- Estructuracin de la descripcin de casos de uso.- Ya hemos mencionado que uncaso de uso los estados que las instancias de los casos de uso pueden tener y la posibletransicin entre estos estados, As mismo un caso de uso puede imaginarse como un diagramade estados con su estado de comienzo, estados intermedios, estados finales y sus transicionesde un estado a otro.

7.4.3.2 Formalizacin de la Descripciones de Casos de UsoPara mejorar el entendimiento de los CU se debe puede utilizar un Diagrama de

Estados, un Diagrama de Actividad o unDiagrama de Interaccin

EjmEl Diagrama de Estados para el CU pagarFactura muestra como la instancia del CUtransita por los diferentes estados unsecuencia de transiciones.

7.4.4 Actividad: Prototipar la Interfaz deUsuario

El objetivo de esta actividad esconstruir un prototipo la interfaz de usuarioel cual le permita al usuario llevar a cabolos casos de uso de manera eficiente, paraesto se debe seguir los sgtes pasos: Diseo lgico de la interfaz de

usuario. Diseo fsico de la interfaz de

usuario.Despus de realizar estas dos etapas nosda como resultado un conjunto deesquemas de interfaces de usuario quecuentan con una apariencia amistosa hacialos actores.

7.4.4.1 Creacin del Diseo Lgico de la Interfaz de Usuario

Cuando lo actores interactan con el sistema, utilizaran y manipularan elementos deinterfaces de usuario que representan atributos. En si el Diseador de los Interfaces de Usuariodebe identificar y especificar estos elementos actor por actor, recorriendo todos los casos deuso que los actores pueden acceder, y tambin determinando los atributos para cado Caso deUso.


11/55


EjmElementos de la interfaz de usuario paraCuenta y Factura, con algunos de susatributos

7.4.4.1 Creacin del Diseo Fsico de la Interfaz de Usuario

Los diseadores de interfaz de usuario primero preparan unos esquemas aproximadosde la configuracin de los elementos de interfaces de usuario que constituyen interfaces deusuario tiles para los actores. Despus, bosquejan elementos adicionales (herramientas,controles, etc.) necesarios para combinar varios elementos de interfaces de usuario eninterfaces de usuario completos.

EjmPara un mejor manejo de todas los CU su puededisear herramientas, controlas, mens etc.

7.4.5 Actividad: Estructurar el Modelo de Casos de Uso

El modelo de Casos de Uso se estructura para: Extraer descripciones de funcionalidad generales y compartidas que pueden ser

utilizados por descripciones mas especificas (relacin de Generalizacin entre CU). Extraer descripciones de funcionalidad adicionales u opcionales que pueden ser

extender descripciones mas especificas (relacin de Extensin entre CU).

7.4.5.1 Identificacin de Descripciones de funcionalidad Compartidas

A medida que identificamos y esbozamos las acciones de cada caso de uso, debemostambin ir buscando acciones o parte de acciones comunes o compartidas por varios Casos deUso con el fin de reducir la redundancia.

Relacin de Generalizacin.- Esta relacin entre Casos de Uso es una clase de Herencia, enla que las instancias de los Casos de Uso generalizadospueden ejecutar todo el comportamiento descrito en el casode uso generalizador.

EjmLa Relacin de Generalizacin entre los CU, toda lasacciones descritas por Ejecutar Transaccin es heredada en

la secuencia descrita por Pagar Factura.

7.4.5.1 Identificacin de Descripciones de funcionalidad Adicionales

Una de las relaciones entre Casos de Uso es la Relacin de Extensin.Relacin de Extensin (extend relationship).- Esta relacin modela la adicin de unasecuencia de acciones a un Caso de Uso. Esta relacinse comporta como si fuera algo que se aade a ladescripcin original de un Caso de Uso, esta relacinincluye una condicin para la extensin como unareferencia a un punto de extensin en el Caso de Uso.Vase el sgte grafico


12/55


EjmLa fecha entrecortada representa la relacin de Extensin entre los CU. Como esta relacin esde condicin se debe verificar si el Comprador es un deudor del Vendedor para as poderejecutar la nueva operacin.

7.4.5.3 Identificacin de otras Relaciones entre Casos de Uso

Existen otras relacin entre los CU, como las Relaciones de Inclusin (includerelationship), esta es una relacin inversa a la relacin de Extensin., que le proporciona unextensin explicita e incondicional a un CU. En este libro no se encontrara muchos detallessobre este tipo de Relacin.

7.5 Resumen del Flujo de Trabajo de los Requisitos

En este capitulo y en el anterior, se ha descrito como capturar los requisitos de unsistema en forma de: Un modelo de l negocio o un modelo del dominio para establecer el contexto del Sistema. Un modelo de CU que capture los requisitos funcionales.

Un conjunto de esbozos de interfaces de usuario y de prototipos para cada actor. Una especificacin de requisitos generales y adicionales.

Estos resultados son un buen inicio para los sgtes flujos de trabajo: anlisis, diseo,implementacin y prueba.

Preguntas:

Quse debe determ inar una vez term inada la descr ipc in gen eral del model o de casos

de uso?Quse debe tomar en cuenta para pro to tipar una In tefaz de usuar io?Cules son los car gos que puede adoptar un trab ajador?Quson los flu jos de trabajo , menc ione las ac t iv idad es ?


13/55


ANLISIS

8.1 IntroduccinEn la etapa del anlisis se analizan los requisitos obtenidos en la captura de requisitos delsistema, refinndolos y estructurndolos, cuyo objetivo es facilitar su comprensin para quenos ayude a estructurar el sistema entero- incluyendo su arquitectura.

La regla numero uno de la captura de requisitos es usar el lenguaje del cliente, y los casos deuso nos ayudan a eso. Pero esto implica algunos riesgos como por ejemplo que algunosaspectos queden sin describir o que su descripcin no sea muy legible a los ojos de losdiseadores.

Para comunicar de manera eficiente las funciones del sistema al cliente:1. Los casos de uso deben mantenerse tan independientes unos de otros como sea

posible.- Se logra no quedndose atrapado en detalles como interferencias,concurrencia y conflictos.

2. Los casos de uso deben describirse utilizando el lenguaje del cliente, y ser cuidadosos al

utilizar notaciones mas formales.3. Debe estructurarse cada caso de uso para que forme una especificacin defuncionalidad completa e intuitiva. Esto se logra estructurando los casos de uso demanera que reflejen intuitivamente los casos de uso reales que el sistema proporciona

El objetivo del anlisis es encontrar solucin a los detalles que aun no han sido resueltos,analizando con mayor profundidad los requisitos, con la diferencia que puede usarse ellenguaje de los desarrolladores. Es decir se puede usar el lenguaje natural para algunos casosde uso y el lenguaje formal para otros casos de uso que lo requieran (a esto le denominaremosrefinar los requisitos).

COMPARACIN DEL MODELO DE CASOS DE USO CON EL MODELO DE ANLISIS

Modelo de Casos de Uso Modelo de AnlisisDescrito con el lenguaje del Cliente

Vista Externa del Sistema

Estructurado por los C.U. proporciona laestructura a la vista externa

Utilizado fundamentalmente como contrato

entre el usuario y los desarrolladores sobreque deberia y que no deberia hacer el sistema

Puede contener redundancias eincosistencias, etc. entre requisitos

Define C.U. que se analizaran con masprofundidad en el modelo del Anlisis.

Descrito con el lenguaje del desarrollador.

Vista Interna del Sistema

Estructurado por Clases y paquetesestereotipados, proporciona la estructura a lavista internaUtilizado por los desarrolladores para

comprender como deberia darse forma alsistema

No deberia contener redundancias eincosistencias, etc. entre requisitos

Define realizaciones de C.U. y cada una deellas representa el anlisis de un C.U. delmodelo de C.U.

8.2 El anlisis en pocas palabras


14/55


El lenguaje que se usa en el anlisis esa basado en un modelo de objetos conceptualdenominado modelo de anlisis. Dicho modelo nos ayuda a refinar los requisitos. Ademsofrece un mayor poder expresivo y mayor formalizacin, y proporciona una estructura centradaen el mantenimiento, como la flexibilidad ante los cambios y la reutilizacin. Adems estemodelo puede servir como entrada en las actividades de diseo e implementacin. Enresumen el modelo de anlisis se puede considerar como una aproximacin al modelo dediseo. Debemos aclarar que en algunos casos quedan algunos detalles sin resolver, loscuales se dejan a la etapa de diseo e implementacin para su resolucin.

8.2.1 Por que el anlisis no es diseo ni implementacin

El diseo tiene como fin el modelamiento del sistema y hallar su forma, incluyendo suarquitectura y su forma real.

Al respecto podemos decir:El diseo e implementacin son mucho mas que un simple anlisisy refinamiento y estructuracin de requisitos, pues hace realidad la forma del sistema. Por esoes recomendable que antes de pasar a un diseo e implementacin, se debe de contar con la

comprensin detallada y precisa de los requisitos, y todo esto se consigue mediante el anlisis.El anlisis ayuda mucho en la divisin de los intereses, facilitando de esta manera el procesode diseo e implementacin.

8.2.2 El objeto del anlisis: resumen

La importancia de analizar los requisitos en la forma de un modelo de anlisis es importantepor varios motivos: Un modelo de anlisis ofrece una especificacin mas precisa de los requisitos que la

tenemos como resultado de la captura de requisitos, incluyendo el modelo de casos deuso.

El modelo de anlisis es descrito con el lenguaje del desarrollador, e introduce mayorformalismo. Un modelo de anlisis estructura los requisitos de modo que facilita su comprensin,

separacin, modificacin y mantenimiento. Un modelo de anlisis puede considerarse como primera aproximacin al modelo de

diseo.

8.2.3 El papel del anlisis en el ciclo de vida del software

Las primeras iteraciones de la elaboracin se centran en el anlisis. Eso contribuye a obteneruna arquitectura estable y facilita una comprensin en profundidad de los requisitos.

El propsito y objetivo del anlisis debe alcanzarse de algn modo en todo proyecto. Perocomo los proyectos difieren unos de otros, segn el autor se distinguen tres tipos:

1. El proyecto usa el modelo de anlisis para describir los resultados del anlisis, ymantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del software.

2. El proyecto utiliza el modelo de anlisis para describir los resultados del anlisis pero lousa como herramienta transitoria e intermedia, es decir se puede actualizar el anlisis enla fase de diseo e implementacin.

3. El proyecto no utiliza en absoluto el modelo de anlisis para describir los resultados delanlisis. En cambio, el proyecto analiza los requisitos en el proceso de captura derequisitos o en el diseo.

8.4 Artefactos


15/55


8.4.1 Artefacto: modelo de anlisis

La estructura impuesta por el modelo de anlisis se define mediante una jerarqua como semuestra en la siguiente figura.

El modelo de anlisis se representa mediante un sistema de anlisis que denota el paquete dems alto nivel del modelo. La utilizacin de otros paquetes de anlisis es por tanto una formade organizar el modelo de anlisis en partes ms manejables que representan abstraccionesde subsistemas y posiblemente capas completas del diseo del sistema.

8.4.2 Artefactos: Clase del anlisis

Una clase de anlisis representa una abstraccin de una o varias clases y/o subsistemas deldiseo del sistema. Posee las siguientes caractersticas: Se centra en el tratamiento de los requisitos funcionales y pospone los no funcionales,

denominndolos requisitos funcionales, hasta llegar a las actividades de diseo eimplementacin subsiguientes.

Raramente define u ofrece una interfaz en trminos de operaciones y de sus signaturas.Su comportamiento se rige mediante responsabilidades en una nivel ms alto y menosformal. Una responsabilidad es una descripcin textual de un conjunto cohesivo del

comportamiento de una clase. Una clase de anlisis define atributos, aunque esos atributos tambin son de un nivelobastante alto. Estos atributos son conceptuales y reconocibles en el dominio delproblema.

Participa en relaciones, aunque esas relaciones son ms conceptuales que suscontrapartidas de diseo e implementacin.

Siempre encajan dentro de los 3 estereotipos bsicos: Interfaz, Control o Entidad, y cadaestereotipo implica una semntica especifica

Estos tres estereotipos estn estandarizados en UML y se utilizan para ayudar a losdesarrolladores a distinguir el mbito de las diferentes clases, cada uno de estos estereotipos

tiene una representacin diferente, como se ve en el siguiente grafico.

Modelo de anlisis Paquete de anlisisSistema de anlisis

Clase de anlisisRealizacin de caso

de uso-anlisis


16/55


8.4.2.1 Clase de Interfaz.- Las clases de interfaz seutilizaran para modelar la interaccin entre el sistemay sus actores. La interaccin puede ser de recibir(ypresentar) informacin y recibir peticiones de (y a)los usuarios. Modelan las partes del sistemas quedependen de sus actores. Por lo general representaninterfaces graficas de usuario (formularios, paneles,

interfaces de impresin etc.).

8.4.2.2 Clases de Entidad.- las clases de entidad se usan para modelar informacin queposee una vida larga y que es a menudo persistente. Las clases de entidad modelan lainformacin y el comportamiento asociado de algn fenmeno o concepto, como una persona,un objeto del mundo real, o un suceso del mundo real.

8.4.2.3. Clases de Control.- Las clases de control representan coordinacin, secuencia,transacciones y control de otros objetos y se usan con frecuencia para encapsular el control deun caso de uso. Las clases de control tambin se utilizan para representar derivaciones yclculos complejos, como la lgica del negocio, que no puede asociarse con ninguna

informacin concreta, de larga duracin y almacenada por el sistema.8.4.3. Artefactos: realizacin de caso de uso-anlisis

Es una colaboracin dentro del modelo de anlisis que describe cmo se lleva a cabo y seejecuta un caso de uso determinado en trminos de las clases de anlisis y de sus objetos delanlisis en interaccin.

8.4.3.1. Diagrama de clases.- Una clase de anlisis y sus objetos participan en variasrealizaciones de casos de uso, y algunas de las responsabilidades, atributos, y asociaciones deuna clase suelen ser relevantes para una nica realizacin de caso de uso. Por tanto es

importante durante el anlisis coordinar todos los requisitos sobre una clase y sus objetos quepuedan tener diferentes casos de uso.

8.4.3.2. Diagramas de interaccin.- La secuencia de acciones en un caso de usocomienza cuando un actor invoca el caso de uso mediante el envi de algn tipo de mensaje alsistema. En un sistema, un objeto de interfaz recibir el mensaje del actor, el cual a su vez serenviado a algn otro objeto, de esta manera los objetos implicados interactan para larealizacin del caso de uso. En esta se identifica secuencia de interaccin detallada yordenadas cronolgicamente.

En los diagramas de colaboracin se muestra las interacciones entre objetos creandoenlaces entre estos y aadiendo mensajes a estos enlaces. En el anlisis se prefiere modelar

Flujo de suceso-anlisisdiagramas de clases

diagramas de interaccin

requisitos especiales

Modelo de casos de uso Modelo de anlisis

Realizacin de caso de

uso-anlisisCaso de uso

Realizacin de caso deuso-anlisis

Participantes

Clase de anlisis

Clase de

interfaz

Clase de

Entidad

Clase de

Control


17/55


con diagramas de colaboracin ya el objetivo principal es identificar requisitos yresponsabilidades.

8.4.3.3. Flujo de sucesos-anlisis.- En una realizacin de caso de uso pueden serdifciles de leer por si mismos, especialmente el los diagramas de colaboracin; de modo quepuede ser til un texto adicional que lo explique. Este objeto debera escribirse en trminos deobjetos de control.

8.4.3.4. Requisitos especiales.- Son descripciones textuales que recogen todos losrequisitos no funcionales sobre una realizacin de caso de uso.

8.4.4. Artefacto: paquete del anlisis

Los paquetes de anlisis proporcionan un medio para organizar los artefactos del modelo deanlisis en piezas manejables. Un paquete de anlisis puede constar de clases de anlisis, derealizaciones de casos de uso, y de otros paquetes del anlisis (recursivamente)

8.4.4.1. Paquetes de servicio.-Aparte de proporcionar casos de uso a sus actores, todosistema tambin proporciona un conjunto de servicios a sus clientes. Un cliente adquiere unacombinacin de adecuada de servicios para ofrecer a sus usuarios los casos de uso necesariospara llevar a cabo un negocio. Estos servicios son un conjunto coherente de accionesrelacionadas funcionalmente con unpaquete de funcionalidad, que se utiliza en varios casos deuso.

Los paquetes de servicio presentan algunas caractersticas:

Contiene un conjunto de clasesrelacionadas funcionalmente.

Es indivisible. Depende de otro paquete de

servicio. Normalmente slo es relevante

para uno o unos pocos actores. Puede ser mutuamente

excluyente con otro paquete. Son reutilizables.

8.4.5. Artefacto: descripcin de laarquitectura (vista del modelode anlisis)

La descripcin de la arquitecturacontiene una vista de la arquitectura del modelo de anlisis , que muestra sus artefactossignificativos para la arquitectura.

8.5. Trabajadores8.5.1. Trabajador: arquitecto

Clase de anlisis Realizacin de caso

de uso-anlisis

Paquete

del anlisis

Contenido de un

paquete de anlisis


18/55


Responsable de la integridad del modelo de anlisis, garantizando que ste sea correcto,consistente y legible como un todo. En sistemas grandes y complejos el arquitecto puededelegar el mantenimiento a otro trabajador, posiblemente a un ingeniero de componentes.

8.5.2. Trabajador: ingeniero de casos de uso

Responsable de la integridad de una o ms realizaciones de caso de uso, garantizando quecumplan los requisitos que recaen sobre ellos. Tambin es responsable del anlisis.

8.5.3. Trabajador: ingeniero de componentesDefine y mantiene las responsabilidades, atributos relaciones, y requisitos especiales de una ovarias clases de anlisis, asegurndose de que cada clase del anlisis cumpla los requisitos deacuerdo a las realizaciones de caso de uso en las que participa. Tambin mantiene laintegridad de uno o varios paquetes del anlisis.

8.6. Flujo de trabajo

Es el comportamiento dinmico y ordenado y evolutivo del modelo de anlisis.

8.6.1. Actividad: anlisis de la arquitectura

El propsito del anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitecturamediante la identificacin de paquetes del anlisis, clases de anlisis evidentes y requisitosespeciales comunes.

8.6.1.1 Identificacin de paquetes de anlisis (dividir el trabajo de anlisis).- los paquetesdel anlisis proporcionan un medio para organizar el modelo de anlisis en piezas maspequeas y mas manejables. Y posee las siguientes caractersticas: Gestin de los aspectos comunes entre paquetes del anlisis. Identificacin de paquetes de servicio.

Definicin de dependencias entre paquetes del anlisis.

Modelo de

anlisis

Descripcin

de la

ar uitectura

Vista de la arquitectura

Responsable de

Arquitecto Ingeniero decasos de uso

Responsable de

Realizacin de caso

de uso-AnlisisResponsabilidades

del Ing. De casos

de uso anlisis

Responsabilidade

s del arquitecto

en el anlisis


19/55


8.6.1.2 Identificacin de clases de entidad obvias.- Se identifican las clases principales queno necesitan de un anlisis muy profundo, es decir que estas clases se pueden identificarfcilmente.8.6.1.3 Identificacin de requisitos especiales comunes.- Son requisitos que aparecendurante la fase del anlisis, que es necesario dar importancia para las fases de diseo eimplementacin. Y presentan las siguientes restricciones. Persistencia Distribucin y concurrencia Caractersticas de seguridad Tolerancia a fallos Gestin de transacciones.

8.6.2 Actividad: analizar un caso de uso

Se analiza un caso de uso para: Identificar las clases del anlisis cuyos objetos son necesarios para llevar a cabo el flujo

de sucesos. Distribuir el comportamiento de caso de uso entre los objetos del anlisis que

interactan. Capturar requisitos especiales sobre el caso de uso.

Tambin a este proceso se le denomina: refinamiento de casos de uso.

8.6.2.1 Identificacin de clases del anlisis.- En este paso se identifican las clases decontrol, entidad e interfaz necesarias para realizar los casos de uso y esbozamos sus nombres,responsabilidades, atributos, y relaciones.

8.6.2.2 Descripcin de interacciones entre el objeto del anlisis.- Teniendo un esbozo delas clases necesarias, se debe hacer una descripcin de la interaccin de los objetos del

anlisis, y se hacen mediante los diagramas de colaboracin, que contienen las instancias delos actores participantes, los objetos del anlisis y sus enlaces.

8.6.2.3 Captura de requisitos especiales.- En este paso recogeremos todos los requisitossobre una realizacin de caso de uso que se identifican en el anlisis pero deberan tratarse enel diseo y en la implementacin, tales como los requisitos no funcionales.

8.6.3 Actividad: Analizar una claseLos objetivos de analizar de una clase son: Identificar y mantener las responsabilidades de una clase de anlisis, basadas en su

papel en las realizaciones de caso de uso.

Identificar y mantener los atributos y relaciones de la clase de anlisis. Capturar requisitos especiales sobre la realizacin de la clase de anlisis.

8.6.3.1 Identificar responsabilidades.- Las responsabilidades de una clase puedenrecopilarse combinando todos los roles que cumple en diferentes realizaciones de caso de uso.Podemos identificar toas las realizaciones de caso de uso en las cuales participan las clasesmediante el estudio de diagrama de clases y de interaccin.

8.6.3.2 Identificacin de atributos.- Los atributos son esenciales para definir lasresponsabilidades de la clase.

8.6.3.3 Identificaciones de asociaciones y agregaciones.- Los diagramas de colaboracinestn compuestos de los objetos del anlisis y los enlaces, estos ltimos son instancias de


20/55


asociaciones entre las clases. Los enlaces pueden implicar la necesidad de referencias yagregaciones entre objetos.

8.6.3.4 Identificacin de generalizaciones.- Las generalizaciones se usan para extraer elcomportamiento compartido y comn entre varias de las clases del anlisis diferentes.

8.6.3.5 Captura de requisitos especiales.- En este paso se recogen los requisitos de unaclase del anlisis que se han identificado en el anlisis y sern tratados en la fase de diseo eimplementacin (es decir requisitos no funcionales).

8.6.4 Actividad: Analizar un paqueteSus objetivos son: Garantizar que el paquete es lo ms independientemente posible de otros paquetes. Garantizar que el paquete cumple su objetivo de realizar algunas clases del dominio o

casos de uso. Describir las dependencias de forma que pueda estimarse el efecto de los cambios

futuros.

Las siguientes son normas para realizar esta actividad: Definir y mantener las dependencias del paquete con otros paquetes cuyas clasescontenidas estn asociadas con l.

Asegurarse de que el paquete contiene las clases correctas, es decir que contengaclases que se relacionan funcionalmente.

Limitar la dependencia con otros paquetes.


21/55


Preguntas:1. Cuales son los estereotipos de una clase de anlisis:

a) Comunicate, extends e include.b) Clase de Interfaz, clase de control, clase de entidad *c) Generalizacin, agregacin y dependencia.d) Asociacin, Generalizacin, include.

2. En un paquete de servicio, dos de sus caractersticas son:a) Es indivisible y reutilizable.*b) Depende de otros paquetes y no es divisible.c) No es excluyente con otro paquete.d) Son reutilizables y no dependen de otro paquete.

3. Los objetivos de analizar de una clase son:a) Identificacin de paquetes, identificacin de clases de entidad obvias e

identificacin de requisitos especiales.b) Identificacin de de clases de anlisis, descripcin de interacciones,

captura de requisitos especiales.c) Garantizar la independencia de paquetes, definir y mantener las

dependencias del paquete, y describir la dependencia de paquetes.

d) Identificacin de responsabilidades, identificacin de atributos,identificacin de generalizaciones.*


22/55


23/55


24/55


Los arquitectos crean los modelos de diseo y despliegue, es decir, los nodos,subsistemas y clases que estos implican. Despus, los ingenieros de casos de usorealizan cada caso de uso en trminos de clases y/o subsistemas y sus interfaces. Losingenieros de componentes especifican luego los requisitos y los integran dentro decada clase. La identificacin de nuevos subsistemas, interfaces, clases y mecanismosde diseo genrico se da a medida que evolucione el diseo, a lo largo del flujo detrabajo, por los desarrolladores, y los ingenieros de componentes responsables, debernrefinarlos y mantenerlos.

9.5.1 Actividad: diseo de la arquitectura

Su objetivo es esbozar los modelos de diseo y despliegue, y su arquitectura mediantela identificacin de los siguientes elementos:

Nodos y sus configuraciones de red Subsistemas y sus interfaces Clases del diseo significativas (clases activas) Mecanismos de diseo genricos que tratan requisitos comunes

Los arquitectos pueden considerar distintas posibilidades de reutilizacin de partes desistemas parecidos, o de productos de software generales, tambin mantienen, refinan yactualizan la descripcin y vistas arquitectnicas de los modelos de diseo y despliegue.

9.5.1.1 Identificacin de nodos y configuraciones de red

Las configuraciones de red habituales utilizan un patrn de tres capas en el cual losclientes se dejan en una capa, la funcionalidad de base de datos en otra, y la lgica delnegocio o de la aplicacin en la tercera, entre sus aspectos podemos resaltar:

Qu nodos se necesitan, y cul debe ser su potencia en trminos de potencia deproceso y tamao de memoria?

Qu tipo de conexiones debe haber entre nodos, y que protocolos se han deutilizar?

Qu caractersticas deben tener las conexiones y los protocolos decomunicaciones (ancho de banda, disponibilidad y calidad)?


25/55


Es necesario alguna capacidad de proceso redundante, modos de fallo,migracin de procesos o mantenimiento de copias de seguridad?

Gracia a estas consideraciones, el arquitecto puede incorporar nuevas tecnologas quepuedan hacer ms fcil la realizacin de la distribucin del sistema.

9.5.1.2 Identificacin de subsistemas y de sus interfaces

Los subsistemas constituyen un medio para organizar el modelo de diseo en piezasmanejables. Pueden identificarse inicialmente como forma de dividir el trabajo de diseo,o se pueden encontrar a medida que el modelo evoluciona; algunos subsistemasrepresentan productos reutilizados y otros son recursos existentes en la empresa.

9.5.1.2.1 Iden tif icacin de sub sist emas d e aplicacin.-En este paso identificamos lossubsistemas de las capas especfica y general de la aplicacin. Si se hizo durante elanlisis una descomposicin adecuada en paquetes, podemos utilizar estos tanto comosea posible e identificar los correspondientes subsistemas dentro del modelo de diseo;puede ser necesario un refinamiento de esta descomposicin en los siguientes casos:

Una parte de un paquete puede ser compartida y utilizada por otros subsistemas.

Algunas partes de un paquete se realizan mediante software reutilizados. Los paquetes del anlisis no representan una divisin del trabajo adecuada. Los paquetes del anlisis no representan la incorporacin de un sistema

heredado. Los paquetes del anlisis no estn preparados para una distribucin directa sobre

los nodos.

9.5.1.2.2 Ident i f icacin de s ubs istemas in termedios y d e sof tw are del sistema.-Elsoftware del sistema y la capa intermedia constituyen los cimientos de un sistema. Laseleccin e integracin de productos software son dos de los objetivos fundamentalesdurante las fases de inicio y elaboracin. El arquitecto verifica que los productos

software encajan en la arquitectura y permiten una implementacin econmica delsistema. Es importante mantener una adecuada libertad de accin y evitar hacernosdependientes de un determinado producto de software, en caso que cambien en elfuturo, o bien ser capaces de cambiar de fabricante si es necesario.

9.5.1.2.3 Definic in de depend encias entr e subs istemas.-Las dependencias entresubsistemas se dan cuando sus contenidos tienen relaciones unos con otros, si noconocemos estos contenidos, consideraremos las dependencias entre los paquetes delanlisis que se corresponden con los subsistemas del diseo. La direccin de estadependencia debe ser la misma que la direccin de la relacin (navegabilidad).

9.5.1.2.4 Identif icacin de interfaces entre subsistemas.- Las interfacesproporcionadas por un subsistema definen operaciones que son accesibles desdefuera del subsistema, estas interfaces los proporcionan las clases u otros subsistemasdentro del subsistema (recursividad), adems de identificarlas, debemos conocer lasoperaciones que deben definirse sobre cada una de ellas, esto se hace mediante eldiseo de casos de uso en trminos de subsistemas y de sus interfaces.

9.5.1.3 Identificacin de clases del diseo relevantes para la arquitectura

Es prctico identificar las clases del diseo relevantes para la arquitectura dentro del

ciclo de vida del software, sin embargo la mayora de las clases se identificarn duranteel diseo de clases, y se refinarn de acuerdo a los resultados obtenidos en el diseo decasos de uso. Por esta razn, los desarrolladores deben evitar mucho detalle al


26/55


identificar las clases, una clase del diseo que no participe en ninguna realizacin decaso de uso es innecesaria.

9.5.1.3.1 Iden tif ic acin de clas es d el di seo a partir de clas es d e anlis is.-Podemos esbozar inicialmente algunas clases del diseo partir de las clases del anlisissignificativas para la arquitectura, tambin podemos usar las relaciones entre esasclases para identificar un conjunto de relaciones entre las correspondientes clases dediseo.

9.5.1.3.2 Identif ic acin d e clas es activ as.-El arquitecto identifica las clases activasconsiderando requisitos de ocurrencia del sistema como:

Rendimiento, tiempo de respuesta y disponibilidad en la interaccin de los actorescon el sistema.

Distribucin del sistema sobre los nodos Otros como el arranque y la terminacin del sistema, progresin, evitacin del

interbloqueo y la inanicin, reconfiguracin y capacidad de los nodos.Cada clase activa se esboza mediante la consideracin del ciclo de vida y de, cmodeberan comunicarse, sincronizarse y compartir informacin sus objetos activos. Luego,

se asignan los objetos activos a los nodos del modelo de despliegue.Para esbozar las clases activas, se puede usar resultados del anlisis y el modelo dedespliegue como entradas y despus hacer corresponder los diseos de las respectivasclases del anlisis con los nodos. Cualquier clase activa que represente un procesopesado es candidata para la identificacin de un componente ejecutable dentro de laimplementacin.

9.5.1.4 Identificacin de mecanismos genricos de diseo

En este paso estudiamos requisitos comunes y decidimos cmo tratarlos, teniendo encuenta las tecnologas de diseo e implementacin disponibles. Los requisitos que

deben tratarse suelen estar relacionados en aspectos como: Persistencia Distribucin transparente de objetos Caractersticas de seguridad Deteccin y recuperacin de errores Gestin de transacciones

La mayora de los mecanismos genricos deberan ser identificados y diseados en lafase de elaboracin.

9.5.2. Actividad: Diseo de un caso de uso

Los objetivos del diseo de un caso de uso son: Identificar las clases de diseo y/o los subsistemas que son necesaria para llevar

acabo el flujo del caso de uso. Distribuir el comportamiento del caso de uso entre los objetos de diseo que

interactan entre los subsistemas participantes. Definir los requisitos sobre las operaciones de las clases del diseo.

9.5.2.1. Identificacin de clases del diseo participantes.-

Para identificar las clases del diseo que se necesitan para realizar el caso de usodebemos hacer lo siguiente:


27/55


Estudiar las clases del anlisis que participan en la correspondiente realizacindel caso de uso-anlisis.

Identificar las clases del diseo que realizan requisitos especiales. Identificar las clases necesarias y asignar una tarea al ingeniero de componentes. Si faltase alguna clase del diseo para un caso de uso en particular, el ingeniero

de caso de uso debera comunicrselo a los arquitectos o ingeniero decomponentes.

9.5.2.2. Descripcin de las interacciones entre objetos del diseo

Cuando tenemos un esquema de las clases del diseo necesarias para realizar elcaso de uso, debemos describir como interactan sus correspondientes objetos deldiseo, esto se hace mediante diagramas de secuencia que contienen las instancias delos actores, los objetos del diseo y las transmisiones de mensajes entre estos, queparticipan en el caso de uso. Si los casos de uso suelen tener varios flujos o subflujosdistintos, es til crear un diagrama de secuencia para cada uno de ellos.

Para crear un diagrama de secuencia, debemos comenzar por el principio del flujodel caso de uso, y despus seguir ese flujo paso a paso decidiendo que objetos del

diseo e interacciones son necesarias para realizar cada paso. Debemos observar losiguiente sobre estos diagramas de secuencia.

El causante de la invocacin del caso de uso es un mensaje de una instanciade un actor hacia un objeto del diseo.

Cada clase del diseo identificada en el paso anterior debera tener al menos unobjeto del diseo participante en el diagrama de secuencia.

Los mensajes que realizan el caso de uso se envan entre lneas de vida de losobjetos.

La secuencia en el diagrama debera ser la principal preocupacin, ya que larealizacin del caso de uso-diseo es la entada principal para la

implementacin del caso de uso. El diagrama de secuencias debera tratar todas las relaciones del caso de uso

que realiza.

9.5.2.3. Identificacin de subsistemas e interfaces participantes

Alguna veces es mas apropiado disear un caso de uso en trminos de lossubsistemas o interfaces que participan en el. Por ejemplo, en el desarrollodescendente, puede que sea necesario captura los requisitos sobre lossubsistemas y sus interfaces antes de haber diseado sus contenidos, o en algunos

casos debera ser fcil sustituir un subsistema y su diseo interno particular por otosistema que tenga otro diseo distinto.Para comenzar, es necesario identificar los subsistemas necesarios para

realizar el caso de uso mediante los siguientes pasos:

Identificar los paquetes del anlisis que contienen a esas clases del anlisis yluego identificar los subsistemas del diseo que poseen una traza hacia esospaquetes del anlisis.

Identificar las clases que realizan requisitos especiales y los subsistemas quelos contienes a esas clases.

9.5.2.4. Descripcin de interacciones ente subsistemas


28/55


Cuando tenemos un esbozo de los subsistemas necesarios para realizar el caso deuso, debemos describir como interactan los objetos de las clases que contiene en elnivel de subsistema, lo haremos mediante diagramas de secuencia que contengan lasinstancias de actores, subsistemas y transmisiones de mensajes entre estos queparticipan. Al hacerlo, utilizaremos una tcnica similar a la descrita en la seccin 5.2.2con las siguientes diferencias:

Las lneas de vida, en los diagramas de secuencia denotan subsistemas en lugarde objetos de diseo.

Cada subsistema identificado en la seccin 5.2.3 debera tener al menos unalnea de vida que lo denote en un diagrama de secuencia.

Si asignamos un mensaje a una operacin de una interfaz, puede resultar serapropiado cualificar el mensaje con el interfaz que proporciona la operacin.

9.5.2.5. Captura de requisitos de implementacin

En este paso incluimos en la realizacin del caso de uso todos los requisitosidentificados guante el diseo que deberan tratarse en la implementacin, como los

requisitos no funcionales.

9.5.3. Actividad: diseo de una clase

El propsito de disear una clase es crear una clase del diseo que cumpla su papel enla realizacin de los casos de uso y los requisitos no funcionales que se aplican a estos.Esto incluye el mantenimiento del diseo de clase en si mismo y los siguientes aspectosde este:

Sus operaciones Sus atributos Las relaciones en las que participa Sus mtodos Los estados impuestos Sus dependencias con cualquier mecanismo del diseo genrico Los requisitos relevantes a su implantacin La correcta realizacin de cualquier interfaz requerida

9.5.3.1 Esbozar la clase del diseo

Como un primer paso necesitamos esbozar una o varias clases del diseo, dada la

entrada en trminos de clases de anlisis cuando tomamos una interfaz como entrada,suele se simple y directo el asignar a una clase de diseo para que proporcione esainterfaz.

Cuando se dan como entrada una o varias clases del anlisis los mtodos utilizadosdependen del estereotipo de la clase de anlisis:

Disear clases de interfaz es dependiente de la tecnologa de interfaz que seutilice.

Disear las clases de entidad que representan informacin persistente a menudoimplica el uso de tecnologas de bases de datos especficas.

Disear clases de control es una tarea delicada, debido a que encapsulan

secuencias, coordinacin de otos objetos, es necesario considerar los siguientesaspectos:


29/55


1. Aspectos de distribucin, si la secuencia necesita ser distribuida ymanejada por diferentes nodos de una red.

2. Aspectos de rendimiento, puede que no sea justificable tener clases deldiseo separadas para realizar la clase de control.

3. Aspectos de transaccin, las clases de control a menudo encapsulantransacciones, sus correspondientes diseos deben incorporar cualquiertecnologa de manejo de transaccin existente que se este utilizando.

9.5.3.2 Identificar Operaciones

En esta etapa identificaremos las operaciones que las clases de diseo va a necesitary describimos esas operaciones utilizando la sintaxis de los lenguajes de programaciny algunas entradas importantes en esta etapa son:

Las responsabilidades de cualquier clase del anlisis que tenga una traza conla clase del diseo, una responsabilidad implica una o varias operaciones.

Los requisitos especiales de cualquier clase de anlisis que tenga una trazacon la clase del diseo.

Las interfaces que las clases de diseo necesita proporcionar. La realizacin del caso de uso-diseo en las que la clase participa.

9.5.3.3 Identificar Atributos

En este paso identificamos los atributos requeridos por la clase de diseo y losdescribimos usando la sintaxis del lenguaje de programacin usada. Un atributoespecifica una propiedad de una clase de diseo, para identificar los atributos tomamosen cuenta las siguientes normas:

Considerar los atributos sobre cualquier clase de anlisis que tenga una traza

con la clase de diseo. los tipos de atributos disponibles estn restringidos por le lenguaje de

programacin. Cuando se elige un tipo de atributo, intentar reutilizar uno que ya exista. Una simple instancia de atributo no puede ser compartida por varios objetos de

diseo. Si una clase de diseo llega a ser muy complicada de comprender por culpa de

sus atributos, algunos de estos atributos pueden ser separados en claseindependientes.

Si hay muchos atributos o son complejos los atributos de una clase, se puede

ilustrar esta en un diagrama de clases separado que muestre solamente elapartado de atributos.

9.5.3.4 Identificar Asociaciones y Agregaciones

Los objetos de diseo interactan unos con otros en los diagramas de secuencia estasinteracciones a menudo requieren asociaciones entre las clases correspondientes. Lasinstancias de las asociaciones deben ser utilizadas para abarcar las referencias conotros objetos y para agregar operaciones en agregaciones con el propsito deenviarles mensajes.

El nmero de relaciones entre clases debe estar minimizado. Deben tenerse en

cuenta las siguientes: a la hora de definir y redefinir las asociaciones y agregaciones:


30/55


Considerar la agregaciones y asociaciones involucrando la correspondiente clasede anlisis

Refinar la multiplicidad de las asociaciones, Nombres de rol, clases deasociacin, roles d ordenacin, roles de cualificacin y asociaciones n-arias deacuerdo con el soporte de lenguaje de programacin utilizada.

Considerar los diagramas de interaccin en los que se emplea asociaciones

9.5.3.5 Identificar las generalizacionesLas generalizaciones deben ser utilizadas con la misma semntica definida en lenguajede programacin, si el lenguaje de programacin no admite generalizacin o herencia,las asociaciones y agregaciones deben utilizarse en lugar de este.

9.5.3.6.-Describir los mtodosLos Mtodos pueden ser utilizados durante el diseo para especificar como se debenrealizar las operaciones.9.5.3.7.-Describir los EstadosAlgunos objetos de diseo son estados controlados, lo que significa que sus estados

determinan su comportamiento cuando reciben un mensaje.9.5.3.8.-Tratar requisitos especialesEn esta fase debe ser tratado cualquier requisito que no haya sido considerado en pasosanteriores, cuando se hace esto debemos estudiar los requisitos formulados en larealizacin de los casos de uso en lo que la clase participa.9.5.4.-Actividad: Diseo de un SubsistemaLos Objetos de diseo de un subsistema son:

Garantizar que el subsistema sea independiente como sea posible de otrossubsistemas.

Garantizar que el subsistema proporcione las interfaces correctos. Garantizar que el subsistema cumpla con su propsito de ofrecer una realizacin

correcta.9.5.4.1.-Mantenimiento de las dependencias entre subsistemas

Se definen y mantienen dependencias de en un subsistema respecto otros cuando loselemento s contenidos en estos estn asociados con el elemento dentro de aquel otro.Las dependencias de usos deberan declararse hacia a los interfaces que en vez dehacia los propios subsistemas.

9.5.4.2.-Mantenimiento de Interfaces proporcionados por el Subsistema

Las Operaciones definidas por la s interfaces que proporciona un subsistema debensoportar todos los roles que cumple el subsistema en las diferentes realizaciones de uncaso de uso.

9.5.4.3.-Mantenimiento de los contenidos de los subsistemas

Un subsistema cumple sus objetivos cuando ofrece una realizacin correcta de lasoperaciones tal y como estn descritas por las interfaces que proporciona. An cuandohaya sido realizado por el arquitecto los contenidos de los subsistema.

Preguntas:1.-Que es un diagrama de clases?


31/55


Son las relaciones que existen entre las clases ,las clases constan de atributos yoperaciones estas participan en varias realizaciones de caso de uso donde semuestra las relaciones que exciten entre estas.

2.-De que se encarga el ingeniero de casos de uso.?Es el encargado y responsable de la realizacin de uno o mas casos de uso diseo.

3.-Cul es el objetivo del diseo de la arquitectura?Esbozar los modelos de diseo, de despliegue y su arquitectura.

4.- Qu son los casos de usos reales?5.- Qu normas tomamos para identificar los atributos?


32/55


Captulo X

Implementacin

10.1.- Introduccin

En la implementacin empezamos con el resultado del diseo e implementamos el sistemaen trminos de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigobinario, ejecutables y similares.

Afortunadamente, la mayor parte de la arquitectura del sistema es capturada durante eldiseo, siendo el propsito principal de la implementacin el desarrollar la arquitectura y elsistema como un todo. Deforma ms especfica, los propsitos de la implementacin son:

Planificar las integraciones de sistema necesarias en cada iteraccin. Seguimospara ello un enfoque incremental, lo que da lugar a un sistema que se implementaen una sucesin de pasos y manejables.

Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de

despliegue. Esto se basa fundamentalmente en las clases activas encontradasdurante el diseo. Implementar las clases y subsistemas encontrados durante el diseo. En particular,

las clases se implementan como componentes de fichero que contienen cdigofuente.

Probar los componentes individualmente, y a continuacin integrarlos compilndolosy enlazndolos en uno o ms ejecutables, antes de ser enviados para serintegrados y llevar a cabo las comprobaciones de sistema.

10.2.- El Papel de la Implementacin en el Ciclo de Vida del Software

La implementacin es el centro durante las iteraciones de construccin, aunque tambin selleva acabo de implementacin durante la fase de elaboracin, para crear la lnea baseejecutable de la arquitectura, y durante la fase de transicin, para tratar defectos tardos comolos encontrados con distribuciones beta del sistema.

Ya que el modelo de implementacin denota la implementacin actual del sistema entrminos de componentes y subsistemas de implementacin, es natural mantener el modelo deimplementacin a lo largo de todo el ciclo de vida del software.

10.3.- Artefactos

10.3.1.- Artefacto: Modelo de Implementacin

El modelo de implementacin describe cmo los elementos del modelo de diseo, como lasclases, se implementan en trminos de componentes, como ficheros de cdigo fuente,ejecutables, etctera. El modelo de implementacin describe tambin cmo se organizan loscomponentes de acuerdo con los mecanismos de estructuracin y modularizacin disponiblesen el entorno de implementacin y en el lenguaje o lenguajes de programacin utilizados, ycmo dependen los componentes unos de otros.

El modelo de implementacin de fine una jerarqua.


33/55


El modelo de implementacin se representa con un sistema de implementacin que denotael subsistema de nivel superior del modelo. El utilizar otros subsistemas es pro tanto una formade organizar el modelo de implementacin en trozos ms manejables.

10.3.2.- Artefacto: Componente

Un componente es le empaquetamiento Fsico de los elementos de un modelo, como son lasclases en el modelo de diseo. Algunos estereotipos estndar de componentes son lossiguientes:

executable es un programa que puede ser ejecutado en un nodo. file es un fichero que contiene cdigo fuente o datos. library es una librera esttica o dinmica. table es una tabla de base de datos. document es un documento.

10.3.3.- Artefacto: Subsistema de Implementacin

Los subsistemas de implementacin proporcionan una forma de organizar los artefactos delmodelote implementacin en trozos ms manejables. Un subsistema puede estar formado porcomponentes, interfaces y otros subsistemas (recursivamente). Adems, un subsistema puedeimplementar y as proporcionar las interfaces que representan la funcionalidad queexportan en forma de operaciones.

Es importante entender que un subsistema de implementacin se manifiesta a travs de unmecanismo de empaquetamiento concreto en un entorno de implementacin determinado,tales como:

Un paquete en Java. Un proyecto en Visual Basic. Un directorio de ficheros en un proyecto de C++. Un subsistema en un entorno de desarrollo integrado como Rational Apex. Un paquete en una herramienta de modelado visual como Rational Rose.

10.3.4.- Artefacto: Interfaz

Las interfaces pueden ser utilizadas en el modelo de implementacin para especificar las

operaciones implementadas por componentes y subsistemas de implementacin. Adems,como se mencion anteriormente, los componentes y los subsistemas de implementacinpueden tener dependencias de uso sobre interfaces.

Un componente que implementa (y por tanto proporciona) una interfaz ha de implementarcorrectamente todas las operaciones definidas por la interfaz. Un subsistema deimplementacin que proporciona una interfaz tiene tambin que contener componentes queproporcionen la interfaz u otros subsistemas (recursivamente) que proporcionen la interfaz.

10.3.5.- Artefacto: Descripcin de Arquitectura (Vista del Modelo de Implementacin)

La descripcin de arquitectura contiene una visin de la arquitectura del modelo deimplementacin, el cual representa sus artefactos significativos arquitectnicamente.


34/55


Los siguientes artefactos son usualmente considerados en el modelo de implementacinsignificativos arquitectnicamente:

La descomposicin del modelo de implementacin en subsistemas, su interfaces y lasdependencias entre ellos. En general, esta descomposicin es muy significativa para laarquitectura. Sin embargo, ya que los subsistemas de implementacin siguen la traza delos subsistemas de diseo uno a uno y los subsistemas de diseo sern muyprobablemente representados en la vista de la arquitectura del modelo de diseo,usualmente es innecesario representar los subsistemas de implementacin en la vistade la arquitectura del modelo de implementacin.

Componentes clave, como los componentes que siguen la traza de las clases de diseosignificativas arquitectnicamente, los componentes ejecutables y los componentes queson generales , centrales, que implementan mecanismos de diseo genricos de los quedependen muchos otros componentes.

10.3.6.- Artefacto: Plan de Integracin de Construcciones

Es importante construir el software incrementalmente en pasos manejables, de forma que

cada paso de lugar a pequeos problemas de integracin o prueba. El resultado de cada pasoes llamado construccin, que es una versin ejecutable del sistema, usualmente una parteespecfica del sistema. Cada construccin es entonces sometida a pruebas de integracinantes de que se cree ninguna otra construccin (por ejemplo, si no pasa las pruebas deintegracin) se lleva un control de versiones de forma que pueda volver atrs a unaconstruccin anterior. Los beneficios de este enfoque incremental son los siguientes:

Se puede crear una versin ejecutable del sistema muy pronto, en lugar de tener queesperar a una versin ms completa. Las pruebas de integracin comienzan pronto, ylas versiones ejecutables pueden ser utilizadas para hacer demostraciones de lascaractersticas del sistema tanto a los participantes directos en el proyecto como a otras

personas involucradas en l. Es ms fcil localizar defectos durante las pruebas de integracin, porque slo se aade

o refina en una construccin existente una parte pequea y manejable del sistema.Incluso mejor, los defectos sern muy probablemente (aunque no siempre) relacionadoscon la parte nueva o refinada.

Las pruebas de integracin tienden a ser ms minuciosas que las pruebas del sistemacompleto porque se centran en partes ms pequeas y ms manejables.

10.4.- Trabajadores

10.4.1.- Trabajador: Arquitecto

Durante la fase de implementacin, el arquitecto es responsable de la integridad del modelode implementacin y asegura que el modelo como un todo es correcto, completo y legible.Como el anlisis y el diseo, para sistemas grandes y complejos puede introducirse untrabajador adicional para asumir la responsabilidad del subsistema de nivel ms alto (es decir,el sistema de implementacin) del modelo de implementacin.

El modelo es correcto cuando implementa la funcionalidad descrita en le modelo de diseo yen los requisitos adicionales (relevantes), y slo esta funcionalidad.

El arquitecto es responsable tambin de la arquitectura del modelo de implementacin, esdecir, de la existencia de sus partes significativas arquitectnicamente como se represent en


35/55


la vista de la arquitectura del modelo de despliegue. Recordemos que esta vista es parte de ladescripcin de la arquitectura del sistema.

Por ltimo, un resultado importante de la implementacin es la asignacin de componentesejecutables a nodos. El arquitecto es responsable de esta asignacin, la cual se representa enla vista de la arquitectura del modelo de despliegue.

Obsrvese que el arquitecto no es responsable del desarrollo en marcha ni delmantenimiento de los diversos artefactos en el modelo de implementacin; por el contrario,esto es responsabilidad del ingeniero de componentes correspondiente.

10.4.2.- Trabajador: Ingeniero de componentes

El ingeniero de componentes define y mantiene el cdigo fuente de uno o varioscomponentes garantizando que cada componente implementa la funcionalidad correcta (porejemplo, como especifican las clases de diseo) .

A menudo, el ingeniero de componentes tambin mantiene la integridad de uno o varios

subsistemas de implementacin. Ya que los subsistemas de implementacin siguen la trazauno a uno a los subsistemas de diseo, la mayora de los cambios en estos subsistemas tienenlugar durante el diseo. Sin embargo, el ingenierote componentes necesita garantizar que loscontenidos (por ejemplo, los componentes) de los subsistemas de implementacin soncorrectos, que sus dependencias con otros subsistemas o interfaces son correctas y queimplementan correctamente las interfaces que proporcionan.

10.4.3.- Trabajador: Integrador de Sistemas

La integracin del sistema est ms all del mbito de cada ingeniero de componentesindividual. Por el contrario, esta responsabilidad recae sobre el integrador de sistemas. Entre

sus responsabilidades se incluye el planificar la secuencia de construcciones necesarias encada interaccin y la integracin de cada construccin cuando sus partes han sidoimplementadas. La planificacin da lugar a un plan de integracin de construcciones.

10.5.- Flujo de Trabajo

En las secciones anteriores hemos descrito el trabajo de implementacin de forma esttica.A continuacin utilizaremos un diagrama de actividades para razonar su comportamientodinmico.

El objetivo principal de la implementacin es implementar el sistema. Este proceso es

iniciado por el arquitecto esbozando los componentes clave en el modelo de implementacin. Acontinuacin, el integrador de sistemas planea las integraciones de sistema necesarias en lapresente iteracin como una secuencia de construcciones. Para cada construccin, elintegrador de sistemas describe la funcionalidad que debera ser implementada y que partesdel modelo de implementacin (es decir, subsistemas y componentes) se vern afectadas.

10.5.1.- Actividad: implementacin de la arquitectura

El propsito de la implementacin de la arquitectura es esbozar el modelo deimplementacin y su arquitectura mediante:

La identificacin de componentes significativos arquitectnicamente, tales comocomponentes ejecutables.

La asignacin de componentes a los nodos en las configuraciones de redes relevantes.


36/55


10.5.1.1.- Identificacin de los componentes significativos arquitectnicamente

A menudo resulta prctico identificar pronto en el ciclo de vida del software los componentessignificativos arquitectnicamente, para iniciar as el trabajo de implementacin. Losdesarrolladores deberan tener cuidado de no identificar demasiados componentes en estaetapa ni ahondar en demasiados detalles. De lo contrario, gran parte del trabajo habr devolverse a hacer cuando se implementen las clases. Tambin es importante la identificacin decomponentes ejecutables y asignacin a nodos.

10.5.1.- Actividad: integrar el sistema

Los objetivos de la integracin del sistema son:

Crear un plan de integracin de construcciones que describa las construccionesnecesarias en una iteracin y los requisitos de cada construccin.

Integrar cada construccin antes de que sea sometida a pruebas de integracin.

10.5.2.- Planificacin de una construccin

En esta seccin discutimos como planificar los contenidos de una construccin,independientemente de que partamos de una construccin previa o de que no partamos deninguna. Suponemos que tenemos un numero de casos de uso o escenarios (es decir, caminoa travs de casos de uso) y otros requisitos que han de ser implementados en la iteracinactual.

Entre los criterios para crear una construccin tenemos: Una construccin debera aadir funcionalidad a la construccin previa implementando

casos de uso completos o escenarios de stos. Una construccin no debera incluir demasiados componentes nuevos refinados. Si no

es as, puede ser muy difcil integrar la construccin y llevar a cabo las pruebas deintegracin.

Una construccin debera estar basada en la construccin anterior, y debera expandirsehacia arriba y hacia los lados en la jerarqua de subsistemas.

Manteniendo estos criterios en mente, uno puede empezar a evaluar los requisitos, talescomo los casos de uso, que han de ser implementados. Obsrvese probablemente sernecesario un compromiso para cumplir de forma apropiada estos criterios.Para cada caso de uso que pueda ser implementado hgase lo siguiente:

1. Considera el diseo del caso de uso, identificando su realizacin de caso de uso-diseocorrespondiente en el modelo de diseo.

2. Identificar los subsistemas y clases de diseo que participan en la realizacin de caso deuso-diseo.

3. Identificar los subsistemas y componentes de implementacin en el modelo deimplementacin que siguen la traza de los subsistemas y clases de diseo encontradosen el paso 2.

4. Considerar el impacto de implementar los requisitos de estos subsistemas deimplementacin y de los componentes sobre la construccin en cuestin. Obsrvese que

estos requisitos se especifican como subsistemas y clases de diseo, como se hizonotar en el paso 3.


37/55


Los resultados deberan estar recogidos en el plan de integracin de la construccin y sercomunicados a los ingenieros de componentes responsables de los subsistemas ycomponentes de implementacin afectados.

10.5.2.2.- Integracin de una construccin

Si la construccin ha sido planificada cuidadosamente como se describe en la seccinanterior debera ser fcil integrar la construccin.

10.5.3.- Integracin de una construccin

El propsito de implementar un subsistema es el de asegurar que un subsistema cumple supapel en cada construccin, tal y como se especifica en el plan de integracin de laconstruccin.

10.5.3.1.- Mantenimiento de los contenidos de los subsistemas

Un subsistema cumple su propsito cuando los requisitos a ser implementados en la

construccin actual y aquellos que afectan al subsistema estn implementados correctamentepor componentes dentro del subsistema.

10.5.4.- Actividad: Implementar una clase

El propsito de la implementacin de una clase es implementar una clase de diseo en uncomponente fichero. Esto incluye lo siguiente:

Esbozo de un componente fichero que contendr el cdigo fuente. Generacin de cdigo fuente a partir de la clase de diseo y de las relaciones en que

participa. implementacin de las operaciones de la clase de diseo en forma de mtodos. Comprobacin de que el componente proporciona las mismas interfaces que la clase de

diseo.

10.5.5.- Actividad: Realizar prueba de unidad

El propsito de realizar la prueba de unidad es probar los componentes implementadoscomo unidades individuales. Se levan a cabo los siguientes tipos de pruebas de unidad:

La prueba de especificacin, o prueba de caja negra, que verifica el comport amientode la unidad observable externamente

La prueba de estructura, o prueba de caja blanca, que verifica la implementacininterna de la unidad.

Obsrvese que puede haber tambin otras pruebas que realizar sobre las unidades, comopruebas de rendimiento, utilizacin de memoria, carga y capacidad. Adems, han de serrealizadas las pruebas de integracin y sistema para asegurar que los diversos componentesse comportan correctamente cuando se integran.

Preguntas propuestas:

1. Cules son los artefactos de la implementacin?2. Cules son los estereotipos estndar de los componentes?


38/55


3. Quines son los trabajadores durante la fase de implementacin?


39/55


Capitulo XI:

Prueba

INTRODUCCION:

En este capitulo se verifica el resultado de la Implementacin probando cada construccinincluyendo tanto construcciones internas como intermedias. Mas concretamente los objetivosde la prueba son:-Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y desistema. Las pruebas de integracin son necesarias para cada construccin dentro de cadaiteracin, mientras que las pruebas de sistema son necesarias solo al final de la iteracin.-Disear e implementar las pruebas creando los casos de prueba, procedimientos de prueba ysi es posible los componentes de prueba.-Realizar las diferentes pruebas y manejar los resultados de cada prueba sistemticamente y sise encuentra algn error ser probada de nuevo o sino sern devueltas a o

Puds Libro

Documents

Transcript of Puds Libro