1

USO DE UML EN APLICACIONES WEB. Arquitectura para web. La mayora de las aplicaciones desarrolladas hoy en da son las aplicaciones llamadas Web, es decir, aquellas que tienen como elemento significativo de su arquitectura un navegador y un protocolo de comunicacin HTTP. El estndar en WEB. En 1998, Jim Conallen defini una extensin a la que denomin WAE (Web Application Extension) para UML. Esta extensin es la convencin ms difundida y aceptada hasta nuestros das. Extensiones WAE para el diagrama de Clases. Algunos de los ejemplos ms comunes de estereotipos que se pueden asociar a las clases y a las relaciones entre estas, para representar una aplicacin en web son las siguientes:

Estereotipos para las Clases Estereotipo Descripcin Son las pginas que contienen scripts o cdigo ejecutable por el servidor (.php , .asp , .jsp). Estos scripts interactan con los recursos que se encuentran al alcance del servidor. Server Page Son las pginas que estn en el lado del cliente, normalmente pginas HTML y scripts (jsvascript), representan pginas que son dibujadas por el navegador web. Client Page Representa una coleccin de campos de entrada que forman parte con una pgina del lado cliente (Client Page). Tiene una correspondencia directa con la etiqueta <FORM> de XHTML. Form Es una coleccin de scripts del lado del cliente que existe como un archivo separado y que son incluidos mediante una peticin independiente por parte del navegador. ClientScript Object Un frame es un contenedor de mltiples pginas web.

Estereotipos para las Relaciones entre las Clases Link Submit Build Representa un apuntador desde una client page hacia una client page o server page. Corresponde directamente con una etiqueta <a> (ancla) de HTML Es una relacin entre un formulario y un servidor de pgina. Una relacin entre una pgina servidor y una pgina cliente. La pgina servidor "construye" a la pgina cliente. Esta relacin siempre es unidireccional Esta es tambin una relacin unidireccional que indica que una pgina Web redirige hacia otra. En caso de que la pgina origen sea una client page esta asociacin corresponder con la META etiqueta y valor HTTP-EQUIV de Refresh*.

Redirect

2
Ejemplos:

<<link>>

MOMovDiarioMo.php

<<link>> menumo.php menumo.html MOBusqAct.php

EOMovDiarioEq.php <<link>>

EOSalidaEqObra.php <<link>> <<link>> menuequipo.php menuequipo.html <<link>> <<link>> EOBusqEqHoras.php

EOBusqEqRendimiento.php

EOBusqEqProduccion.php

UNIDAD III. PROCESO DE DESARROLLO DE SOFTWARE BASADO EN UML. 1.- EL PROCESO DE DESARROLLO DE SOFTWARE UNIFICADO. Proceso Unificado de Desarrollo de Software o PUDS (-Tambin conocido como RUP: Rational Unified Process- ): Proceso de desarrollo de software basado en el Lenguaje Unificado de Modelado y que es iterativo, centrado en la arquitectura y dirigido por los casos de uso y los riesgos. Proceso que se organiza en cuatro fases: inicio, elaboracin, construccin y transicin, y que se estructura en torno a cinco flujos de trabajo fundamentales: recopilacin de requisitos, anlisis, diseo, implementacin y pruebas. El proceso de desarrollo de software se basa en: Dirigido por casos de uso. Centrado en la arquitectura. . Con un ciclo de vida iterativo e incremental. Utiliza UML para definir los modelos del sistema software. El sistema software en construccin est formado por o Componentes de software. o Interconectados a travs de interfaces

4
* Dirigido por casos de uso. Los casos de uso guan el diseo, implementacin y prueba del sistema software. Para construir un sistema con xito, debemos conocer lo que sus futuros usuarios necesitan y desean. Los casos de uso representan requisitos funcionales. Todos los casos de uso juntos constituyen un modelo de casos de uso. Dirigido por casos de uso significa que el proceso de desarrollo avanza a travs de una serie de flujos de trabajo que parten de los casos de uso.

* Centrado en la arquitectura Agrupa aspectos estructurales y dinmicos. Influencias: plataforma, aspectos legales, componentes reusables disponibles. Es una vista del diseo completo que hace visibles las caractersticas principales. El proceso ayuda a centrarse en los objetivos correctos: Legibilidad, adaptabilidad, reutilizacin. Cmo se relacionan casos de uso y arquitectura? Funcin y forma.

Cmo se relacionan los casos de uso y la arquitectura? La arquitectura del sistema da una idea de qu forma tiene el sistema completo. Conviene pensar en la forma del sistema que se est construyendo: computadoras necesarias, SOs, SGBDs, comunicaciones, etc.

Cada producto tiene una funcin y una forma, ambas deben equilibrarse para obtener un producto con xito. La funcin corresponde a los casos de uso y la forma a la arquitectura. Tanto la arquitectura como los casos de usos deben evolucionar en paralelo, ya que los casos de uso deben encajar en la arquitectura y la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, tanto en el momento en el que se desarrolla el proceso como en el futuro. Por lo tanto, los arquitectos modelan el sistema para darle una forma. Es sta la que debe permitir que el sistema evolucione tanto en el desarrollo como en futuras generaciones. Para encontrar esta forma, los arquitectos deben trabajar sobre los casos de uso clave del sistema (o funciones clave del sistema) los cuales pueden suponer el 5 o el 10 por ciento de los casos de uso. * Iterativo Incremental El trabajo se divide en iteraciones o mini proyectos, cada una de las cuales resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos al crecimiento del producto. Las iteraciones deben estar controladas: deben seleccionarse y ejecutarse de manera planificada, por eso se les llama miniproyectos. Cada iteracin trata un grupo de casos de uso que amplan la utilidad del producto, y una serie de riesgos. Las iteraciones sucesivas se construyen sobre los artefactos tal como quedaron de la ltima iteracin. Los equipos de proyecto tratan de seleccionar solo las iteraciones requeridas para lograr el objetivo. En la medida que se aadan ms, el proceso consumir ms tiempo y esfuerzo. Si una iteracin cumple con sus objetivos el desarrollo contina con la siguiente iteracin, si no, los desarrolladores debern revisar sus decisiones previas y probar un nuevo enfoque Uno de los objetivos de la reduccin del riesgo es minimizar los problemas inesperados.

La Iteracin controlada: Reduce el coste del riesgo a los costes de un solo incremento. Reduce el riesgo de no sacar el producto al mercado segn el calendario previsto. Acelera el ritmo del esfuerzo de desarrollo. Reconoce que las necesidades del usuario no pueden definirse completamente al principio.