Arquitectura del software La arquitectura es un aspecto del diseo que se concentra en algunas caractersticas especficas.

RUP: proceso unificado relacionado UML: Lenguaje de Modelamiento unificado Dentro del RUP, la arquitectura de un sistema de software es la organizacin o estructura de los componentes ms significativos del sistema que interactan a travs de INTERFACES, con componentes pequeos o componentes de otros componentes Descripcin de la arquitectura Para hablar y razonar acerca de la arquitectura de software, se debe primero definir una representacin ARQUITECTURAL UN CAMINO QUE DESCRIBE los aspectos importantes de una arquitectura. En RUP, sta descripcin es capturada en el documento de software Arquitecture Document. Vistas de la Arquitectura Podemos Elegir muchas vistas de arquitectura para representar una Arquitectura de software. Cada vista de arquitectura est dirigida por un conjunto especfico de intereses para los stakeholders dentro del desarrollo de los procesos: usuarios finales, diseadores, gerentes, ingenieros de sistema, entre otros. Las vistas capturan las principales decisiones de diseo estructural mostrando como la arquitectura de software se descompones a travs de componentes y como los componentes son conectados por conectores para producir formas tiles. Esta decisin de diseo debe estar ligada con los requerimientos funcionales y suplementarios. Pero sta decisin a su vez pone ms restricciones sobre los requerimientos y sobre las decisiones del diseo de ms bajo nivel. UN CONJUNTO TPICO DE VISTAS DE ARQUITECTURA

La arquitectura se representa por un nmero de vistas de arquitectura diferentes las cuales en esencia son extractos de los elementos significativos del MODELO DE LA ARQUITECTURA. Dentro del RUP se empieza desde un conjunto tpico de vistas llamadas las vistas del Modelo 4+1, compuesta de: La Vista de Caso de Uso USE CASE VIEW la cual contienen los Casos de Uso, y escenarios que representan el comportamiento deseado del sistema: en ella se encontrar los modelos relacionados con la CAPTURA DE REQUISITOS.Segn RUP en esta vista se ubicaran 1. EL MODELO DEL NEGOCIO 2. MODELO CONCEPTUAL 3. MODELO DE CASO DE USO 4. DIAGRAMAS DE SECUENCIA del sistema La vista lgica Logical view, en la que encontraramos los modelos que muestran el vocabulario y la funcionalidad (Estructura y comportamiento) del sistema, a travs de un conjunto de colaboraciones que realizan los Casos de uso de la Vista de Casos de uso(colaboraciones que se modelan mediante diagramas de clase y diagramas de interaccin: diagrama de secuencia y el diagrama de colaboracin), las clases se organizan dentro de paquetesy subsistemas y estos a su vez en capas. La vista de implementacin Impentationview Contiene un resumen del modelo de implementacin y su organizacin en trminos de mdulos dentro de paquetes y capas. La asignacin de paquetes y clases (vista lgica) hacia los paquetes y mdulos de vista de implementacin tambin es descrita La vista de procesos Process view, comprenden los hilos y procesos que forman los mecanismos de sincronizacin y concurrencia del sistema. Dentro del RUP viene a ser un subconjunto del modelo de diseo La vista de despliegue. Deployment view En la que se modela la distribucin y despliegue de los componentes a los nodos de procesamiento del sistema. Muestra la topologa, distribucin e instalacin del sistema. Es un subconjunto del Modelo de Implementacin 2.4 El foco de la arquitectura

AUNQUE LAS VISTAS pueden representar el Diseo de todo el sistema, la arquitectura tiene que ver con algunos aspectos especficos La Estructura del Modelo Los elementos esenciales- Casos de Uso Crtico, clases principales, mecanismos comunes y as sucesivamente, opuestos a todos los elementos presentes en el modelo Los principales escenarios que muestran el flujo de control principal a lo largo de todo el sistema. Los servicios para capturar la modularidad, caractersticas opcionales, aspectos de la lnea de producto. En la fase de iniciacin, el anlisis y diseo se preocupa por establecer si el sistema visionado es factible. Y con la evaluacin de las potenciales tecnologas para su solucin. La fase de elaboracin temprana se focaliza en la creacin de una arquitectura inicial. Detalle del flujo de trabajo-Fase de iniciacin-Realizar sntesis de Arquitectura El propsito es lograr la construccin y evaluacin de los conceptos de arquitectura para demostrar si el sistema es viable y factible. Descripcin Este flujo de trabajo representa una solucin que existe o que debe existir, la cual satisface los requerimientos significativos de arquitectura, aquellos que muestran que el sistema es factible y viable Cmo est organizado? Se lleva a cabo con un grupo pequeo de profesionales funcionales. El equipo debe incluir miembros con experiencia en modelos organizacionales. Detalle del flujo

Es crear un bosquejo inicial de la arquitectura del software Detalle del flujo de trabajo Fase de elaboracin Descripcin Objetivos Crear bosquejo inicial de la arquitectura del sistema Definir un conjunto inicial de elementos significativos de la arquitectura que sern utilizados como la base para el anlisis Definir un conjunto inicial de mecanismos de anlisis. Fase de elaboracin Cmo est organizado Grupo pequeo de profesionales Se trata del desempeo, escalabilidad, procesos y sincronizacin de hilos de distribucin. Detalle de Flujo de trabajo Analizar comportamiento El propsito es la transformacin de las descripciones del comportamiento proporcionadas por los requerimientos en un conjunto de elementos sobre los cuales se basa el diseo.

CONCEPTOS FUNDAMENTALES PARA MODELAR NEGOCIOS Proceso 1. Es un conjunto de actividades que emplean un insumo 2. Agregan valor 3. Suministran un producto al consumidor Proceso de Negocio 1. Conjunto de o grupo de tareas o actividades

2. 3. 4. 5.

Secuencia u orden lgico Emplean recursos de organizacin Ofrece resultados de inters a alguien Apoya algn objetivo de la organizacin rea funcional Grupo de trabajo Objetivos Comprender la estructura y la dinmica de la organizacin de objetivos. Comprender los problemas actuales de la organizacin objetivo e identificar el campo de accin incluido en donde hay un potencial de crecimiento y mejora. Evaluar el impacto del cambio en la organizacin objetivo Asegurar que los clientes, usuarios finales, desarrolladores, y otros roles tengan un entendimiento comn de la organizacin objetivo

ESTEREOTIPOS

<Actor Name>
(f rom Actors)

NewUseCase2
(from <Use Case Name>)

<Actor Name>
(f rom Actors)

Actividades del Modelo de Negocio

El actor de Negocio representa un rol ejecutado por alguien o algo externo al negocio, pero que interacta o se relaciona con l.
<Actor Name>
(f rom Actors)

El BA(actor de negocio) se beneficia o afecta por los resultados del proceso. Generalmente se identifican como: clientes, proveedores, autoridades, entidades legales y/o reguladoras, sistemas de Informacin localizados fuera del sistema o fuera del negocio. No debe representar reas, departamentos o partes de una organizacin, sino roles de ejecucin.

BUSINESS USE CASE

NewUseCase2
(from <Use Case Name>)

EL Caso de uso del Negocio, identifica un proceso especfico del negocio que produce un resultado de valor medible, y esperado por un actor en particular. Representa la secuencia de actividades desarrolladas para lograr ese valor. Reconoce los procesos del tipo de giro del negocio, por comparacin con las otras empresas o a partir del estudio de la Cadena De Valor. Son procesos complejos del negocio, no son actividades simples Business Worker

<Actor Name>
(f rom Actors)

El trabajador del negocio representa aquel personaje que tiene algn tipo de responsabilidad dentro del rea de estudio, vale decir, que realiza algn tipo de tarea dentro de la misma, o tiene alguna responsabilidad. Creacin del Modelo en Rational Rose Para poder implementar el modelo antes mencionado, haremos uso de la Herramienta CASE Rational Rose 1.- Una vez instalado el producto, botn inicio, seleccionar RationalUnifiedprocess y click en OK

2.- Una vez que nos encontramos en la pantalla principal, pondremos especial atencin al rea del Browser, que se encuentra a lado izquierdo, donde desplegaremos el Use Case View

Desplegar el Use Case Viiew

3.- Realizar doble click sobre el objeto main

4.- Seguidamente crearemos un paquete de nombre Modelo de Negocio

5.- Hacer doble click sobre el paquete Modelo de Negocio, debindose abrir una nueva ventana, donde empezaremos a desarrollar nuestro modelo

Funcionalidad del sistema La vista de Caso de Uso captura el comportamiento de un subsistema o de una clase, tal cmo se muestra a un usuario exterior. Reparte la funcionalidad del sistema en transacciones significativas para los Actores-Usuarios ideales de un sistema. Las piezas de funcionalidad interactivas se llaman casos de uso. Un Caso de Uso describe una interaccin con los Actores como consecuencia de mensajes entre el sistema y uno o ms Actores. El trmino Actor incluye a los seres humanos, as como a otros sistemas informticos y procesos.

NewClass2

NewUseCase

NewClass

Actor Un actor es una idealizacin de una persona externa, de un proceso, o de una cosa que interacta con el sistema. El tiempo de ejecucin, un usuario fsico puede estar limitado a los actores mltiples dentro del sistema. Diferentes usuarios pueden estar ligados al mismo actor y por lo tanto pueden representar casos mltiples de la misma definicin de actor. Cada actor participa en uno o ms casos de uso, interacta con el Caso de uso (y por lo tanto con el sistema o la clase que posee el caso de uso.

Los actores pueden ser definidos en jerarquas de generalizacin, en los cuales una descripcin abstracta del actor es compartida y aumentada por una o ms descripciones especificas del actor. Un actor puede ser un humano, otro sistema informtico, o un cierto proceso ejecutable. Se dibuja a un actor como una persona pequea con trazos lineales y el nombre debajo de l. Caso de Uso Un caso de uso es una unidad coherente de funcionalidad, externamente visible proporcionada una unidad del sistema y expresada por secuencias de mensajes intercambiados por la unidad del sistema y uno o ms actores. El propsito de un caso de uso es definir una pieza de comportamiento coherente, sin revelar la estructura interna del sistema. La definicin de un Caso de Uso incluye todo el comportamiento que implica las lneas principales, las diferentes variaciones sobre el comportamiento normal y todas las condiciones excepcionales, que pueden ocurrir con tal comportamiento, junto con la respuesta deseada. Desde el punto de vista de los usuarios estos pueden ser situaciones anormales. Desde el punto de vista de los sistemas son las variaciones adicionales que deben ser descritas y manejadas. En el Modelo, la ejecucin de cada caso de uso es independiente de las dems, aunque una implementacin de casos de uso puede crear dependencias implcitas entre ellas, debido a los objetos compartidos, cada caso de uso representa una pieza ortogonal de la funcionalidad cuya ejecucin se puede mezclar con la ejecucin de otros casos de uso. La dinmica de un caso de uso se puede especificar por las interacciones de UML, mostradas como diagramas de estado, diagramas de secuencia, diagramas de colaboracin o descripcin informales de texto. Cuando se implementan, los casos de uso son realizados mediante colaboraciones entre clases del sistema. Una clase puede participar en mltiples colaboraciones, y por lo tanto mltiples casos de uso. En el nivel de sistemas los casos de uso representan el comportamiento externo de todo sistema tal y como se muestra en los usuarios exteriores. Un caso de uso es como una operacin del sistema, una operacin invocada por un usuario exterior. Sin embargo a diferencia de una operacin, un caso de uso puede continuar recibiendo la entrada de sus actores durante su ejecucin. Los casos de uso tambin se pueden aplicar internamente a unidades ms pequeas de un sistema, tales como subsistemas y clases individuales. Un caso interno de uso representa el comportamiento que una parte del sistema presenta al resto

del sistema . Por ejemplo un caso de uso para una clase representa una pieza coherente de funcionalidad que una clase proporciona a otras clases que desempeen ciertos roles dentro del sistema. Una clase puede tener ms de un caso de uso. Un caso de uso es una descripcin lgica de una parte de la funcionalidad del sistema . No es una construccin manifiesta en la implementacin de un sistema. En su lugar cada caso de uso se debe corresponder con las clases que implementen el sistema. El comportamiento del caso de uso se corresponde con las transiciones y operaciones de las clases. Ya que una clase puede desempear roles mltiples en la implementacin de un sistema, puede por lo tanto realizar porciones de mltiples casos de uso. Una parte de la tarea del diseo es encontrar las clases de implementacin que combinen claramente los roles apropiados para implementar todos los casos de uso, sin introducir complicaciones innecesarias. La implementacin de un caso de uso se puede mostrar como un conjunto de una o ms colaboraciones. Una colaboracin es una realizacin de casos de uso. Un caso de uso puede participar en varias relacione, adems de poderse asociar con actores. Un caso de uso se dibuja como una elipse con su nombre dentro o debajo de ella. Se conecta por lneas con trazo continuo con los actores que se comunican con ella.

Tipos de Asociacin entre Casos de Uso

Un caso de Uso es una descripcin lgica de una parte de la funcionalidad del Sistema. Un Caso de Uso puede participar en varias relaciones con otros casos de uso, adems de poder asociarse con actores. Aunque cada instancia de un caso de uso es independiente, la descripcin de un caso de uso se puede descomponer en factores de otros casos de uso ms simples. Esto es similar a la manera en que la descripcin de una clase se puede definir incrementalmente a partir de la definicin de la superclase. Un Caso de

uso puede incorporar simplemente el comportamiento de otros casos de uso como fragmentos de su propio comportamiento. A esto se llama relacin de inclusin. En este caso, el nuevo caso de uso es un caso especial de caso de uso original, y no se puede sustituir por l. Un caso de uso se puede tambin definir como una extensin incremental de un caso de uso base. Puede haber varias extensiones del mismo caso de uso base, que pueden ser aplicadas conjuntamente. Las extensiones a un caso de uso se agregan a su semntica, que es el caso de uso base instanciado, no los casos de uso de la extensin. Las relaciones de inclusin y extensin, se dibujan como flechas de lneas discontinuas con la palabra clave <<include>> o <<extend>>. La relacin de inclusin apunta al caso de uso a ser incluido, la relacin de extensin seala el caso de uso que se extender Relacin comunicacin Funcin Notacin Solo se produce entre un actor y un caso de uso La insercin de comportamiento <<extend>> adicional en un CU base que no tiene conocimiento sobre l Relacin entre un CU general y un CU ms especfico, que hereda y aade propiedades Insercin de <include> comportamiento adicional en un CU base que describe la insercin

Extensin

Generalizacin

Inclusin

Comunicacin

Las instancias de actores se comunican con el sistema mediante el envi y recepcin de instancias de mensaje(seales y llamadas)desde y hacia instancias de casos de uso y en el nivel de realizacin, desde y hacia los objetos que implementan el caso de uso. Todo lo anterior se expresa mediante asociaciones entre el actor y el caso de uso

NewClass

NewUseCase

Un actor puede listar el conjunto de seales que enva y que recibe, y mantener una lista de las interfaces que ofrece y que requiere. Las interfaces de un actor deben ser compatibles con las de los casos de uso con los que se comunica. En otras palabras un actor debe recibir todas las seales que un caso de uso sea capaz de enviarle y no debe mandarle al caso de uso seales que ste no sea capaz de recibir. Las interfaces de un actor restringe las clases con las que pueda corresponderse (que puedan implementar un comportamiento). Un actor puede tambin tener una lista de atributos que caracterice su estado.

GENERALIZACIN
Pueden existir semejanzas entre dos o ms actores: esto es pueden comunicarse con el mismo conjunto de casos de uso de la misma manera. Esta semejanza se expresa mediante la GENERALIZACION en otro actor, posiblemente abstracto, que modele los aspectos comunes. Los actores descendientes heredan los roles y relaciones con casos de uso del actor antecesor. Una instancia de un actor descendiente siempre se `puede utilizar en aquellos casos en los que se espera una instancia del actor antecesor (principio de capacidad de sustitucin). Un descendiente incluye los atributos y operaciones de sus antecesores.

trabajador

cajero

vendedor

almacenero

Inclusin La relacin de inclusin conecta un caso de uso base con un caso de uso incluido. El caso de uso incluido que figura en sta relacin no es un clasificador instanciable independientemente. Lo que hace es describir explcitamente una secuencia adicional de comportamiento que se inserta en una instancia de caso de uso que est ejecutando el caso de uso base. A este mismo caso de uso base se le puede aplicar mltiples relaciones de inclusin. El mismo caso de uso incluido se puede incluir en mltiples casos de uso base. Esto no indica ninguna relacin entre los casos de uso base, siempre y cuando cada insercin se ha en una posicin diferente.
<<include>>

Registrar pago

Emitir comporbante de pago

El caso de uso incluido puede acceder a atributos o a operaciones del caso de uso base. La inclusin representa un comportamiento encapsulado que, potencialmente puede reutilizarse en mltiples casos de uso base. Pero el caso de uso base no debe acceder a los atributos del caso de uso incluido, por que el caso de uso incluido habr concluido cuando el caso de uso base recupere el control.

Observese que se puede anidar las adiciones(sea cual fuere su clases). Por tanto, una inclusin puede servir cmo base para otra inclusin, extensin o generalizacin posterior. Extensin Una relacin desde un caso de uso extensor a un caso de uso base, que especifica como se puede insertar el comportamiento definido para el caso de uso extensor en el comportamiento definido para el caso de uso base. El caso de uso extensor modifica incrementalmente el caso de uso base de forma modular
<<extend>>

Registrar cotizacin

registrar cliente

El caso de uso extensor en esta relacin, no es necesariamente un clasificador instanciable separado. Consiste en uno o ms segmentos que describen las secuencias adicionales de comportamiento que modifican incrementalmente el comprtamiento del caso de uso base, cada segmento en en un caso de uso extensor se puede insertar en una localizacin separada en el caso de uso base. La relacin de extensin tiene una lista de los nombres de los puntos de extensin, igual en nmero al nmero de segmentos en el caso de uso extensor. Cada punto de extensin se debe definir en el caso de uso base. Un caso de uso extensor en una relacin de extensin puede tener acceso y modificar los atributos definidos por el caso de uso base. El caso de uso base, sin embargo, no puede ver las extensiones y puede no tener acceso a sus atributos u operaciones. El caso de uso base define un marco modular en el cual pueden ser agregadas extensiones, pero la base no tiene visibilidad sobre las extensiones. Las extensiones modifican implcitamente el comportamiento del caso de uso base. Como Identificar a un actor 1.- Quin est interesado en un requerimiento concreto?

Quien hace el requerimiento? El cliente Quien solicita el servicio? el cliente Quien define el servicio? El analista 2.- En que dominios de la organizacin se usar el sistema?

3.- Quin ser el beneficiario de la nueva funcionalidad? 4.- Quin proveer, usar y/o retirar informacin? 5.- Quin dar soporte y administrar el sistema? 6.- Usar el sistema un recurso externo? 7.- Un usuario actuar con diferentes roles? 8.- Diferentes usuarios actuarn con un mismo rol? 9.-Interaccionar el nuevo sistema con un sistema antiguo? 24/05/2012 Como identificar un caso de uso 1Cules son las tareas y responsabilidades de cada actor? 2Algun actor creara, almacenara, cambiara, borrar, o leera informacin del sistema? 3Qu casos de uso, creara, almacenaran, cambiaran, borraran o leern esta informacion? 4Es necesario que un actor informe al sistema sobre cambios externos? 5es necesario que un actor sea informado sobre ciertas incidencias del sistema? 6que casos de uso darn soporte y mantendrn al sistema? 7puede ser realizado por los CU todos los requerimientos funcionales documentados?

Ventajas de los casos de uso 1.- lenguaje de comunicacin entre usuarios y desarrolladores 2.- Comprensin detallada de la funcionalidad del sistema 3.- Acotacin precisa de las habilidades de los usuarios 4.- Gestin de riesgo ms eficiente para gobernar la complejidad 5.- Estimacin mas exacta para determinar tiempo, recursos y prioridades en la dosificacin de esfuerzo de desarrollo. 6.- Fiel trazabilidad para verificar la traduccin de requerimientos en cdigo ejecutable 7.- mayor control para mantener las sucesivas revisiones de los programas 8.- certificacin contractual cliente-desarrollador 9.- Documentacin orientada al usuario help, manual de procedimientos, reglas del negocio 10.- documentacin orientada al administrador del sistema: soporte de mantenimiento

DOCUMENTACION DE LOS CASOS DE USO