Flujo de Trabajo Requerimiento: un requerimiento define qu es lo que el sistema debe hacer, para lo cual se identifican las funcionalidades requeridas

y las restricciones que se imponen.Adems son condiciones o capacidades que necesita un usuario para resolver un problema o lograr un objetivo.Este flujo de trabajo se desarrolla en la fase de inicio del proceso unificado de desarrollo. Contenido
[ocultar]

1 Objetivos del Flujo de Trabajo Requerimiento 2 Artefactos del FT Requerimientos 3 Trabajadores del FT Requerimiento 4 Actores del Sistema 5 Actividades 6 Caractersticas que deben tener los Requerimientos

7 Clasificacin de los Requerimientos

o o

7.1 Requerimientos Funcionales 7.2 Requerimientos No Funcionales

8 Diagrama de Casos de Uso del Sistema 9 Fuente

Objetivos del Flujo de Trabajo Requerimiento

Definir el mbito del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario. Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo que el sistema debera hacer. Proveer a los desarrolladores un mejor entendimiento de los requerimientos del sistema. Proveer una base para estimar recursos y tiempo de desarrollo del sistema. Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones.

Artefactos del FT Requerimientos

Los principales artefactos que se obtienen son:

Modelo de casos de uso del sistema: Es un modelo del sistema que contiene actores, casos de uso y sus relaciones. Actor: Terceros fuera del sistema que interactan con l.

Caso de uso: Fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Descripcin de la arquitectura (vista del modelo de casos de uso): Representa los casos de uso significativos para la arquitectura ya que describen alguna funcionalidad importante y crtica o algn requisito que deba priorizarse.

Glosario de trminos: Trminos comunes que se utilizan para describir el sistema. Prototipo de interfaz usuario: Presentacin de la interfaz del producto que representa la funcionalidad contenida en los casos de uso; de manera que permita que el usuario verifique que el sistema va a satisfacer sus necesidades.

Trabajadores del FT Requerimiento

Los trabajadores que participan en este flujo de trabajo son:

Analista del sistema: Define los alcances del sistema e identifica a los actores y casos de uso que permiten modelar completa y consistentemente el sistema. Especificador de casos de uso: Describe detalladamente cada caso de uso de acuerdo a las funcionalidades que engloba. Diseador de interfaz de usuario: Responsable de desarrollar el prototipo de la interfaz de usuario para algunos casos de uso, habitualmente un prototipo para cada actor. Arquitecto: Describe la vista de la arquitectura del modelo de casos de uso, definiendo la prioridad de cada caso de uso para decidir en qu iteracin ser desarrollado cada uno.

Actores del Sistema

Cada trabajador del negocio (inclusive si fuera un sistema ya existente) que tiene actividades a automatizar es un candidato a actor del sistema. Si algn actor del negocio va a interactuar con el sistema, entonces tambin ser un actor del sistema. Los actores del sistema:

No son parte de l. Pueden intercambiar informacin con l. Pueden ser un recipiente pasivo de informacin. Pueden representar el rol que juega una o varias personas, un equipo o un sistema automatizado.

Actividades
Como parte de este flujo de trabajo las principales actividades que se realizan son:

Identificar y clasificar requerimientos. Encontrar actores y casos de uso. Priorizar casos de uso. Detallar casos de uso. Prototipar la interfaz de usuario.

Estructurar el modelo de casos de uso.

Caractersticas que deben tener los Requerimientos

Deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos partes. Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces Cmo sabemos si cumplimos con l o no? Descritos como una caractersticas del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo).

Clasificacin de los Requerimientos

Los requisitos se pueden clasificar en Funcionales y No Funcionales

Requerimientos Funcionales

Son capacidades o condiciones que el sistema debe cumplir. En la realizacin de los casos de uso del negocio, se obtienen las actividades que sern objeto de automatizacin. Estas actividades no son exactamente los requerimientos funcionales, pero s son el punto de partida para identificar qu debe hacer el sistema. Los requerimientos funcionales se mantienen invariables sin importar con que propiedades o cualidades se relacionen.

Requerimientos No Funcionales

Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las caractersticas que hacen al producto atractivo, usable, rpido o confiable. Los requerimientos no funcionales forman una parte significativa de la especificacin. Son importantes para que clientes y usuarios puedan valorar las caractersticas no funcionales del producto, pues si se conoce que el mismo cumple con la toda la funcionalidad requerida, las propiedades no funcionales, como cun usable, seguro, conveniente y agradable, pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptacin.

Diagrama de Casos de Uso del Sistema

Un diagrama de casos de uso del sistema representa grficamente a los procesos y su interaccin con los actores. Cada caso de uso debe comunicarse con al menos un actor, si no aparece ningn actor que se

comunique con un caso de uso esto indica error en el modelo de caso de uso o en los requerimientos planteados. Como excepciones a esta ltima regla podran considerarse:

Si el caso de uso es abstracto (no instanciable) no tiene porque incluir relacin con actores (aunque puede tenerlas) Un caso de uso Padre en una relacin de generalizacin-especializacin no tiene porque tener relacin con un actor si el caso de uso Hijo describe completamente toda la relacin con el actor Algunos casos de uso se inician acorde a un horario (ejemplo: una vez a la semana o al da) lo que significa que el reloj del sistema es su iniciador. El reloj es interno al sistema, de esta forma el caso de uso no tendra relacin de iniciacin con ningn actor, pero para esclarecer el modelo debe colocarse un actor ficticio denominado "Reloj".

Las relaciones de comunicacin entre actores y casos de uso no tienen nombre, slo se necesita especificar el punto de inicio y el fin de la relacin. Esto se hace a travs de una lnea con saeta que indica inicio y fin de la relacin Cada fin de la relacin identifica un rol e incluso una multiplicidad (cuntas instancias del actor o caso de uso pueden asociarse con una instancia de actores o casos de uso). Cada rol de una relacin de comunicacin tiene una propiedad de navegabilidad, indicando quien inicia la comunicacin en la interaccin. La navegabilidad se muestra mediante una flecha. Si la fecha apunta al caso de uso, esto indica que el actor es quien inicia la relacin con el sistema. Si la fecha apunta al actor, el sistema es quien inicia la interaccin con el actor. La relacin en ambos sentidos se muestra a travs de una lnea sin saetas (la doble saeta dificulta la comprensin del diagrama). Por cada flecha de comunicacin se asume un mensaje de retorno. No se debe confundir navegabilidad con flujo de datos, la navegabilidad slo debe expresar relacin de iniciacin. Ejemplo: un cliente requiere que se muestre un dato del sistema, esto se muestra mediante una flecha del actor al caso de uso a case (representando al sistema), an cuando la mayor parte de los flujos de datos van del sistema al cliente. Un actor se comunica con un caso de uso por mltiples razones: 1. Para invocar un caso de uso. Una instancia de un actor siempre invoca una instancia de un caso de uso. 2. Para solicitar algn dato almacenado en el sistema, el cual el caso de uso obtiene y presenta al actor. 3. Para cambiar el dato almacenado en el sistema mediante el uso de un dilogo con el sistema. 4. Para reportar que algo especial ha ocurrido alrededor del sistema y que dicho sistema debe cuidar.

Un actor inicia un caso de uso. Sin embargo, una vez que este ha comenzado, el caso de uso puede comunicarse con varios actores. Se pueden usar relaciones de comunicacin entre casos de uso y actores para mostrar cules actores se comunican con ellos. La multiplicidad de las relaciones muestra cuntas instancias del actor se relacionan con una instancia del caso de uso al mismo tiempo. Flujo de trabajo anlisis y diseo. Esta disciplina explica cmo transformar los productos de trabajo de los requisitos en los productos de trabajo que especifiquen el diseo del software que el proyecto va a desarrollar. Aunque RUP contempla Anlisis y Diseo en mismo Flujo de Trabajo por estar muy relacionadas, son actividades diferentes con artefactos diferentes. Contenido
[ocultar]

1 Objetivos del anlisis y diseo

2 Relacin del flujo de trabajo de anlisis y diseo con otras disciplinas

3 Disciplina del anlisis

o o

3.1 Principales artefactos del anlisis 3.2 Trabajadores del anlisis

4 Disciplina de diseo

o o

4.1 Principales artefactos del diseo 4.2 Trabajadores del Diseo

5 Fuente

Concepto:

Esta disciplina centra su atencin al inicio de la fase de Elaboracin. Contribuye a obtener una arquitecturaestable y slida y facilita una comprensin en profundidad de losrequisitos

Objetivos del anlisis y diseo

El Anlisis y Diseo de un producto software tiene como finalidad: -Transformar los requisitos en un diseo del sistema en creacin. -Evolucionar una arquitectura slida para el sistema. -Adaptar el diseo para que se ajuste al entorno de implementacin, con un diseo pensado para el rendimiento.

Relacin del flujo de trabajo de anlisis y diseo con otras disciplinas

La disciplina de anlisis y diseo est relacionada con otras disciplinas de la siguiente forma: -La disciplina de requisitos proporciona una entrada fundamental para el anlisis y diseo. -La disciplina de Implementacin implementa el diseo. -La disciplina de Prueba prueba el sistema diseado durante al anlisis y diseo. -La disciplina de entorno desarrolla y mantiene los artefactos de soporte que se utilizan durante el anlisis y diseo. -La disciplina de Gestin de proyectos planifica el proyecto y las iteraciones (descritas en el plan de iteracin).

Disciplina del anlisis

Luego de identificados todos los requisitos que debe satisfacer el software que se va a desarrollar es importante realizar un Anlisis de ellos, con el objetivo de tener una mejor comprensin antes de entrar al diseo de dicho software, garantizando as una arquitectura robusta, eficaz, eficiente y capaz de sobrevivir a cambios. Por esta razn existe esta Disciplina. En los flujos de trabajo anteriores el cliente jugaba un rol decisivo, por lo que el lenguaje utilizado estaba al alcance de todos, ya en esta Disciplina se comienza a hablar en un lenguaje propio de los desarrolladores y se separan a los clientes del trabajo. Tambin se comienza a ver el software de forma interna, en funcin de clases y paquetes que permiten el cumplimiento de todos los requisitos que deben ser cumplidos. El modelo de aAnlisis puede considerarse como una primera aproximacin al modelo de diseo. Es una entrada fundamental cuando se da forma al sistema en el diseo y en la implementacin . Si se sigue un paradigma orientado a objetos (OO) entonces en el anlisis obtendremos las primeras propuestas de clases que se encarguen de garantizar los distintos servicios que el cliente necesita. Se dice que es una aproximacin inicial, ya que en el anlisis se modelan solo 3 tipos de clases (interfaz , control, entidad ) y estas no se encuentran especificadas en ningn lenguaje de programacin en concreto, as que aun no podran ser codificadas, ellas deben enriquecerse y profundizarse en flujos posteriores en aras de cumplir ese objetivo. La disciplina del anlisis tiene como propsito: -Conseguir una comprensin ms precisa de los requisitos, refinarlos y estructurarlos. -Utilizar el lenguaje de los desarrolladores para analizar con profundidad los requisitos funcionales . -Proporcionar una visin general del sistema.

Principales artefactos del anlisis

Paquete del anlisis

Cuando se trabaja en sistemas medianamente complejos se necesita agrupar las clases en mdulos lgicos que permitan favorecer la reutilizacin, que se vuelva ms fcil manipular la complejidad y distribuir el trabajo entre los miembros del equipo, por esta razn aparecen los paquetes de anlisis. Un paquete del anlisis puede incluir clases del anlisis, realizaciones de CU y otros paquetes del anlisis (recursivamente). Todos los elementos que se encuentran dentro de un paquete del anlisis no son necesariamente visibles desde el exterior, es decir, un paquete encapsula a la vez que agrupa. Debe procurarse que los paquetes cumplan con el patrn de Alta Cohesin y Bajo Acoplamiento .

Clase del anlisis

Modelo conceptual temprano que describe las caractersticas y comportamiento comunes de un conjunto de cosas que existen en el sistema. Se indica que es conceptual pues pospone todos los elementos de diseo ya que no considera posibles tecnologas a emplear en el desarrollo del software. Constituyen un prototipo de las futuras clases que darn vida al mismo. Las clases del Anlisis estn siempre identificadas con uno de los tres estereotipos siguientes:
Error al crear miniatura: El fichero parece no existir: /srv/www/docs/images/b/b9/Clases_unidas.jpg

Representacin de las clases del anlisis en la herramientas de modelado Rational Rose

-Interfaz (Boundary): se encargan de la modelacin de toda la interaccin que puede existir entre los actores y el sistema. Constituyen las fronteras del sistema. -Control: representan la coordinacin, secuenciacin, transacciones y a veces la lgica del negocio. Se emplean a menudo para encapsular el control referido a un Caso de uso (CU). -Entidad: representa la informacin de larga duracin y a menudo persistente que se maneja en el sistema.

Diagrama de colaboracin

Se utilizan para ilustrar la realizacin de un Caso de Uso (CU). Muestra como los objetos interactan para lograr el comportamiento de un CU o parte de este y de esta forma definen los roles de los mismos. A diferencia de los diagramas de secuencia su principal objetivo es mostrar la relacin entre dichos objetos. Estos diagramas tienen una mayor utilidad cuando se utilizan en interacciones entre un nmero no muy grande de objetos, pues en caso contrario el nmero de mensajes entre estos crece y el diagrama se hace difcil de entender; en estos casos los diagramas de secuencia son una mejor eleccin.

Diagrama de secuencia

Al igual que los Diagramas de Colaboracin los diagramas de secuencia se utilizan para ilustrar la realizacin de un CU. Son particularmente importantes para los diseadores pues aclaran los roles jugados por los objetos en un flujo, lo cual le proporciona un gran valor para la determinacin de las responsabilidades de las clases. A diferencia del Diagrama de Colaboracin este incluye secuencia cronolgica de los mensajes y no la relacin entre los objetos, por lo que es mejor su utilizacin cuando el orden en el tiempo de los mensajes es de importancia.

Diagrama de clases del anlisis

Constituye una vista esttica de las clases que conforman el modelo del anlisis y las asociaciones entre las mismas. Es una vista de la futura composicin de clases de software.

Realizacin de caso de uso

Descripcin de cmo se realiza un CU. Esta se expresa en trminos de un diagrama de clases que muestra las clases del anlisis participantes en la realizacin del CU y diagramas de interaccin que muestran como se lleva a cabo la colaboracin entre las clases para dar cumplimiento al mismo (tantos diagramas como sean necesarios para abarcar todas los posibles desenlaces (escenarios ) del CU ).

Trabajadores del anlisis

En la Disciplina de Anlisis aparecen involucrados principalmente los siguientes Roles:

Arquitecto de software Ingeniero de casos de uso Ingeniero de componentes

Disciplina de diseo
El diseo tiene el propsito de formular los modelos que se centran en los requisitos no funcionales y en el dominio de la solucin y que prepara para la implementacin y prueba del sistema. Pretende crear un plano del modelo de implementacin, por lo que el grueso del esfuerzo est en las ltimas iteraciones de elaboracin y las primeras de construccin.

El papel del diseo en el ciclo de vida del software

RUP define el anlisis y el diseo como un nico flujo de trabajo en el que hay actividades que se realizan desde la fase de inicio . Durante esta fase se analiza si es posible dar una solucin que satisfaga a los requerimientos significadtivos de la arquitectura. En la fase de elaboracin se comienza con un anlisis de los elementos significativos de la arquitectura como parte de la 1ra iteracin de elaboracin y en las siguientes iteraciones se refina la arquitectura hasta disear todos sus elementos. En las restantes fases se hace algo de anlisis y diseo vinculado con nuevos requerimientos que sean definidos y se decida implementar y con los defectos que haya que corregir como consecuencia de las pruebas realizadas. El modelo de diseo est muy cercano al de implementacin, lo que es natural para guardar y mantener el modelo de diseo a travs del ciclo de vida completo del software. En el diseo se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los no funcionales y las restricciones que se le suponen. Una entrada esencial en el diseo es el resultado del anlisis, o sea el modelo de anlisis, que proporciona una comprensin detallada de los requisitos. Adems impone una estructura del sistema que hay que esforzarse por conservar lo ms fielmente posible cuando se de forma al sistema. La Disciplina de Diseo tiene como propsito: -Adquirir una comprensin de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con los lenguajes de programacin, componentes reutilizables, sistemas operativos, tecnologas de distribucin y concurrencia y tecnologas de interfaz de usuario. -Crear una entrada apropiada y un punto de partida para actividades de implementacin, capturando los requisitos o subsistemas individuales, interfaces y clases. -Descomponer los trabajos de implementacin en partes ms manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo. -Capturar las interfaces entre los subsistemas antes en el ciclo de vida del software, lo cual es muy til cuando utilizamos interfaces como elementos de sincronizacin entre diferentes equipos de desarrollo.

Principales artefactos del diseo

Modelo de diseo

El artefacto Modelo de Diseo est compuesto por: -Diagramas de clases del diseo y diagramas de interaccin (colaboracin y/o secuencia) del diseo. Estos ltimos tambin llamados realizacin de casos de uso. -Paquetes y subsistemas de diseo representados en una jerarqua y una breve descripcin de ellos. -Clases, interfaces, relaciones, etc. contenidas en los Paquetes y una breve descripcin de ellos. Un Diagrama de Clases del Diseo est formado por dos elementos bsicos: las Clases y las Relaciones entre ellas. Una clase de UML se representa con un rectngulo dividido en 3 secciones. La primera seccin o seccin superior es empleada para indicar el nombre de la clase, la segunda o intermedia empleada para mostrar los atributos de la clase y la tercera para definir las responsabilidades de la clase. Existen varios tipos de relaciones entre clases entre los que se encuentran: -Dependencia Dependency -Asociacin Asociation - Agregacin Agregation - Composicin Composition - Herencia Hierarchy
Error al crear miniatura: El fichero parece no existir: /srv/www/docs/images/9/97/Subsistema_de_diseo.JPG

Representacin de un Subsistema Diseo

Subsistemas de diseo Los subsistemas de diseo son una forma de organizar los artefactos del modelo de diseo en piezas ms manejables. Puede contener clases del diseo, realizaciones de casos de uso, interfaces y otros subsistemas. Pueden proporcionar interfaces que representan la funcionalidad que exportan en trminos de operaciones. Un subsistema de diseo cumple la misma funcin que un paquete, pero tiene la diferencia que aqu el todo (subsistema) es mayor que la simple suma de las partes que lo componen, ya que estas se encuentran interrelacionadas de forma tal que puedan satisfacer ciertos servicios, el subsistema tiene una semntica, que lo hace algo ms que una simple agrupacin de elementos, el subsistema tiene personalidad, responsabilidades bien definidas, provee servicios que son empleados por otros subsistemas o sistemas en s. Los Servicios brindados por un subsistema, es decir, sus responsabilidades, las expone por un conjunto de interfaces, que es otro artefacto que resulta identificado en este punto, al igual que un sistema brinda funcionalidades a un actor a travs de una interfaz, en este caso de usuario, el subsistema brinda su funcionalidad a travs de una interfaz, pero de aplicacin, es decir que cuando se refiere al artefacto Interface en la disciplina de diseo, no se esta hablando de una interfaz grfica de usuario, sino de una interfaz a una aplicacin o parte de ella. Cuando la clase del anlisis es demasiado compleja, tal que parece contener comportamientos que no deben ser responsabilidad de una sola clase actuando sola, dicha clase debe ser transformada en un subsistema de diseo. El subsistema de diseo se usa para encapsular las colaboraciones y el comportamiento en una forma tal que los clientes, (elementos que utilizan los servicios del subsistema) puedan permanecer completamente despreocupados de cmo se ha diseado internamente el subsistema, no importando incluso si este cambia internamente, para ellos es de vital importancia el artefacto Interface. Interfaz Las interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas del diseo. Una clase de diseo que proporcione una interfaz debe proporcionar tambin mtodos que

realicen las operaciones de la interfaz. Un subsistema que proporcione una interfaz debe contener tambin clases del diseo u otros subsistemas (recursivamente) que proporcionen la interfaz. Paquetes de Diseo

Representacin de un Paquete de Diseo.Si un elemento del paquete Capa Negocios utiliza elementos del paquete Capa de Datos, el paquete Capa Negocios tiene relacin de dependencia con el Capa de Datos

Es una coleccin de clases, relaciones, realizaciones de casos de uso, diagramas y otros paquetes que estn de alguna forma relacionados. Es usado para estructurar el modelo de diseo dividindolo en partes ms pequeas. A diferencia de los subsistemas de diseo, los paquetes no ofrecen una interfaz formal. Los paquetes de diseo deben usarse fundamentalmente como herramienta organizacional del modelo para agrupar elementos relacionados, si se requiere un comportamiento o semntica se deben usar subsistemas de diseo. Realizacin de casos de uso del diseo Es una colaboracin en el modelo de diseo que describe como se realiza un caso de uso especfico, y como se ejecuta en trminos de casos de uso del diseo. Una realizacin de caso de uso del diseo proporciona una traza directa a una realizacin de caso de uso del anlisis en el modelo de anlisis Cuando el modelo de anlisis no va a mantenerse a lo largo del ciclo de vida del software pero en cambio se utiliza solo para crear un buen diseo, no tendra realizacin de caso de uso del anlisis. La dependencia de traza de una realizacin de caso de uso del diseo ir en este caso directamente hasta el caso de uso en el modelo de casos de uso. Una realizacin de caso de uso del diseo tiene una descripcin de flujos de eventos textual, diagramas de clases que muestran sus clases de diseo participantes y diagramas de interaccin que muestran la realizacin de un flujo o escenarios concretos de un caso de uso en trminos de interaccin entre objetos del diseo. Proporciona una realizacin fsica de la realizacin de caso de uso de anlisis y tambin gestiona muchos requisitos no funcionales capturados en la realizacin de casos de uso del anlisis. Por consiguiente una realizacin de casos de uso de diseo puede posponer el manejo de algunos requisitos hasta las subsiguientes actividades de implementacin anotndolas como requisitos de implementacin en la realizacin. Diagramas de interaccin Los diagramas de secuencia y los diagramas de colaboracin (ambos llamados diagramas de interaccin) son dos de los cinco tipos de diagramas UML que se utilizan para modelar los aspectos dinmicos de los sistemas. Un diagrama de interaccin muestra una interaccin, que consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos.

Un diagrama de secuencia es un diagrama de interaccin que destaca la ordenacin temporal de los mensajes; un diagrama de colaboracin es un diagrama de interaccin que destaca la organizacin estructural de los objetos que envan y reciben mensajes. Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de un sistema. La mayora de las veces, esto implica modelar instancias concretas o prototpicas de clases, interfaces, componentes y nodos, junto con los mensajes enviados entre ellos, todo en el contexto de un escenario que ilustra un comportamiento. Los diagramas de interaccin no son slo importantes para modelar los aspectos dinmicos de un sistema, sino tambin para construir sistemas ejecutables por medio de ingeniera directa e inversa. Un diagrama de interaccin es bsicamente una proyeccin de los elementos de una interaccin. La semntica del contexto de una interaccin, los objetos y roles, enlaces, mensajes y secuenciacin se aplican a los diagramas de interaccin. Al igual que los dems diagramas, los diagramas de interaccin pueden contener notas y restricciones.

Modelo de despliegue.
Error al crear miniatura: El fichero parece no existir: /srv/www/docs/images/1/1b/Diagrama_de_despliegue.JPG

Diagrama de Despliegue de un cajero automtico.Se conecta mediante el protocolo TCP/IP al Sevidor del banco que es el encargado de hacer todas las transacciones, este se conecta utilizando tecnologa ADO al servidor de base de datos (BD)

El modelo de despliegue es utilizado para capturar los elementos de configuracin del procesamiento y las conexiones entre esos elementos. Tambin se utiliza para visualizar la distribucin de los componentes de software en los nodos fsicos. El mismo est compuesto por: -Nodos: Elementos de procesamiento con al menos un procesador, memoria, y posiblemente otros dispositivos. -Dispositivos: Nodos estereotipados sin capacidad de procesamiento en el nivel de abstraccin que se modela. -Conectores: Expresan el tipo de conector o protocolo utilizado entre el resto de los elementos del modelo.

Descripcin de la arquitectura.

La Arquitectura es el esqueleto o base de una aplicacin, en esta se analiza la aplicacin desde varios puntos de vista. En la arquitectura aparecen los artefactos ms importantes y diferentes, para establecer un esquema de cmo deben ser los prximos artefactos a construir, o sea es puramente un semi-molde al que se deben ajustar sin muchos cambios los restantes artefactos a construir en la aplicacin o solucin. De obtenerse un artefacto demasiado diferente a los dems, este formara parte de la arquitectura. En RUP, esta se compone de 4+1 vistas: vista lgica, vista de procesos, vista de implementacin, vista de despliegue y estas cuatro regidas por la vista de casos de uso. Durante el FT anlisis y diseo se incorpora la vista lgica, la cual toma varios elementos del modelo de diseo. Suelen considerarse significativos para la arquitectura los siguientes artefactos del modelo de diseo: 1. La descomposicin del modelo de diseo en subsistemas, sus interfaces, y las dependencias entre ellos. Esta descomposicin es muy significativa para la arquitectura en general, debido a que los subsistemas y sus interfaces constituyen la estructura fundamental del sistema. 2. Clases de diseo fundamentales como clases que poseen una traza con clases del anlisis significativas, clases activas, y clases del diseo que sean generales y centrales. 3. Realizaciones de casos de uso del diseo que describen alguna funcionalidad importante y crtica que debe desarrollarse pronto dentro del ciclo de vida. La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de despliegue, que muestra sus artefactos relevantes para la arquitectura. Debido a su importancia, deberan mostrarse todos

los aspectos del modelo de despliegue en la vista arquitectnica, incluyendo la correspondencia de los componentes sobre los nodos tal como se identificar durante la implementacin.

Modelo de datos

Este modelo se obtiene como resultado de la actividad: Diseo de la base de datos

Trabajadores del Diseo

En la Disciplina de Diseo aparecen involucrados principalmente los siguientes Roles:

El Arquitecto El Diseador El Diseador de Bases de Datos

Flujo de trabajo de Implementacin. El flujo de trabajo de implementacin describe cmo los elementos del modelo del diseo se implementan en trminos de componentes y cmo estos se organizan de acuerdo a los nodos especficos en el modelo de despliegue. En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. Adems se deben hacer los tests de unidad: cada implementador es responsable de testear las unidades que produzca. El resultado final de este flujo de trabajo es un sistema ejecutable. Contenido
[ocultar]

1 Objetivos 2 Actividades 3 Artefactos 4 Trabajadores 5 Relacin con otras disciplinas

6 Ver tambin 7 Fuente

Objetivos
Los objetivos de la disciplina de implementacin son:

Definir la organizacin del cdigo, en trminos de los subsistemas de implementacin organizados en capas. Implementar los elementos de diseo en trminos de los elementos de implementacin (archivos de origen, binarios, programas ejecutables y otros). Probar y desarrollar componentes como unidades.

Integrar los resultados producidos por los implementadores individuales (o equipos) en un sistema ejecutable. Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue.

Actividades
A continuacin se listan las principales actividades de la disciplina: 1. Estructurar el modelo de implementacin: En esta actividad se establece la estructura de los elementos de implementacin basndose en las responsabilidades asignadas de los subsistemas de implementacin y su contenido. 2. Planificar la integracin: Consta de planificar la integracin de cada subsistema y del sistema en su conjunto. Consiste en definir el orden en el que se integrarn los elementos contenidos en un subsistema de implementacin. 3. Realizacin de servicios: Se centra en la realizacin de un modelo de servicio (modelo de los elementos centrales de una arquitectura orientada a servicios) desde el punto de vista de los componentes de software que se ejecutan en los entornos de middleware existentes. 4. Implementar componentes: Mediante esta actividad se completa una parte de la implementacin de forma que se puede entregar para la integracin. 5. Integrar los subsistemas: Consiste en integrar los elementos en un subsistema de implementacin y, a continuacin, entregar el subsistema de implementacin para su integracin en el sistema. 6. Integrar el sistema: Consiste en integrar las partes de los subsistemas de implementacin en una construccin.

Artefactos

Componente Diagrama de Componentes Subsistema de Implementacin Modelo de Implementacin Plan de Integracin Elemento de Implementacin

Trabajadores

Arquitecto: reponsable de la integridad, correccin, completitudy legibilidad del modelo de implementacin de acuerdo alo descrito en el modelo de diseo. Programador: implementacin de componentes. Revisor tcnico: revisa y evala el cdigo contrauna lista de chequeo. Integrador de Sistemas: planificala secuencia de construcciones necesarias en cada iteracin y la integracin de cada construccin cuando sus partes han sido implementadas.

Relacin

con

otras

disciplinas

La implementacin est relacionada con otras disciplinas:

La disciplina de requisitos describe cmo capturar los requisitos que debe cumplir la implementacin en un modelo de guin de uso. La disciplina de anlisis y diseo describe cmo desarrollar un modelo de diseo. El modelo de diseo representa la intencin de la implementacin y es la entrada principal de la disciplina de implementacin. La disciplina de prueba describe cmo realizar el test de integracin para cada compilacin durante la integracin del sistema. Tambin describe cmo realizar las pruebas del sistema para verificar que todos los requisitos se han cumplido, as como la forma en que se detectan y remiten los defectos.

La disciplina de entorno describe cmo desarrollar y mantener artefactos de soporte que se utilicen durante la implementacin, como la descripcin del proceso, las directrices de diseo y las de programacin. La disciplina de despliegue describe cmo utilizar el modelo de implementacin para producir y entregar el cdigo al cliente final. La disciplina de gestin de proyectos describe la mejor forma de planificar el proyecto. Algunos aspectos importantes del proceso de planificacin son el plan de iteracin, la gestin de cambios y los sistemas de seguimiento de defectos.