SlideShare una empresa de Scribd logo

UWE

Metodología UWE

1 de 280
UWE
Introducción.
En los años 1980 se propuso que la mejor forma de
desarrollar un sistema software era por medio de una
planificación rígida y meticulosa del proyecto, soportada por
herramientas CASE (Ingeniería de Software Asistida por
Computador) y algunos procesos de desarrollo rigurosos y
altamente controlados, que eran sinónimo de garantía y
calidad en el software.
Estas metodologías tenían una carga de trabajo pesada en
planificación, diseño y documentación, absorbiendo gran
parte del tiempo destinado al desarrollo del sistema.
Introducción.
En los años 1990 se comenzaron a proponer métodos ágiles
para el desarrollo de software, que permitieran a los
desarrolladores concentrarse en el software y no totalmente
en el diseño y documentación del mismo.
Éstas metodologías tienen un enfoque iterativo para la
especificación, el desarrollo y la entrega del producto,
teniendo como principio que los requerimientos podían
cambiar permanentemente y durante el proceso de
desarrollo, entregando sistemas funcionales más
rápidamente con la posibilidad de agregar nuevos cambios
en las especificaciones.
Introducción.
En la actualidad, el proceso de desarrollo de software ha
sido abordado desde diferentes metodologías, las cuales
tienen diferentes enfoques para la captura de requerimientos
y el proceso de desarrollo del sistema software, algunas de
ellas se basan en analizar y documentar rigurosamente las
especificaciones del sistema, para luego realizar un
desarrollo y posteriormente efectuar las pruebas.
Otros métodos proponen centrarse en la organización del
equipo de trabajo, incluir al cliente activamente y en arrojar
resultados satisfactorios más rápidamente. Sea cual fuere la
metodología es conveniente saber que éstas se eligen e
implementan de acuerdo a la naturaleza del proyecto,
llegando incluso a combinarse entre sí para lograr mejores
resultados.
Introducción.
El avance de Internet y las comunicaciones ha provocado en
los últimos años el nacimiento de nuevas propuestas
metodológicas para la web.
La web se ha convertido por méritos propios en el medio de
comunicación por excelencia del siglo XXI. Resulta difícil
decir algo original para justificar el tremendo impacto que
tiene y seguirá teniendo en el devenir de nuestra civilización.
Entre sus muchos aportes, destaca la rapidez con la cual se
intercambia la información que unida a la eliminación de las
barreras geográficas, han convertido Internet en un terreno
fértil en el cual las empresas pueden extender sus negocios.
Introducción.
Como consecuencia ha proliferado el número de
aplicaciones web para la resolución de las necesidades de
las organizaciones.
A diferencia de las aplicaciones tradicionales desarrolladas
para una plataforma tecnológica concreta, las aplicaciones
web potencialmente pueden llegar a cualquier tipo de
dispositivo.
Por tanto este nuevo paradigma de desarrollo se está
utilizando cada vez más para implementar aplicaciones
gubernamentales, de enseñanza a distancia o de gestión
empresarial entre otras.

Recomendados

Más contenido relacionado

La actualidad más candente

Diferencias entre scrum y xp
Diferencias entre scrum y xp Diferencias entre scrum y xp
Diferencias entre scrum y xp deborahgal
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Usoutrilla
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosSergio Sanchez
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de usoSaul Mamani
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xpCrisCobol
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional CristobalFicaV
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientosTensor
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosCesar Prado
 
Entrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemasEntrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemasmodayestilo
 
Diagramas De Secuencia
Diagramas De SecuenciaDiagramas De Secuencia
Diagramas De SecuenciaFabian Garcia
 

La actualidad más candente (20)

Casos De Uso
Casos De UsoCasos De Uso
Casos De Uso
 
Metodologia orientada a objeto
Metodologia orientada a objetoMetodologia orientada a objeto
Metodologia orientada a objeto
 
Diferencias entre scrum y xp
Diferencias entre scrum y xp Diferencias entre scrum y xp
Diferencias entre scrum y xp
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Diagrama de Componentes
Diagrama de ComponentesDiagrama de Componentes
Diagrama de Componentes
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Uso
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
 
Metodologia xp
Metodologia xpMetodologia xp
Metodologia xp
 
Desarrollo web
Desarrollo webDesarrollo web
Desarrollo web
 
Documento vision
Documento visionDocumento vision
Documento vision
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Entrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemasEntrevista y encuesta para analisis y diseño de sistemas
Entrevista y encuesta para analisis y diseño de sistemas
 
Arquitectura fisica y logica
Arquitectura fisica y logicaArquitectura fisica y logica
Arquitectura fisica y logica
 
HTML5
HTML5HTML5
HTML5
 
Diagramas De Secuencia
Diagramas De SecuenciaDiagramas De Secuencia
Diagramas De Secuencia
 

Similar a UWE

15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC
15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC
15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVCLuis Fernando Aguas Bucheli
 
Programación web
Programación webProgramación web
Programación weberic291285
 
15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB Contenidos: 4.1 Dao 4.2 Mv...
15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB  Contenidos:  4.1 Dao  4.2 Mv...15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB  Contenidos:  4.1 Dao  4.2 Mv...
15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB Contenidos: 4.1 Dao 4.2 Mv...Luis Fernando Aguas Bucheli
 
Resultado de aprendizaje
Resultado de aprendizajeResultado de aprendizaje
Resultado de aprendizajeCharly Zetina
 
aplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.pptaplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.pptssuser948499
 
aplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.pptaplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.pptssuser948499
 
Diseño de aplicaciónes Web.pptx
Diseño de aplicaciónes Web.pptxDiseño de aplicaciónes Web.pptx
Diseño de aplicaciónes Web.pptxromaldohuerta1
 
Prog. web. equipo 5
Prog. web. equipo 5Prog. web. equipo 5
Prog. web. equipo 5Luis Mendez
 
Guia de aprendizaje 4 cms
Guia de aprendizaje 4 cmsGuia de aprendizaje 4 cms
Guia de aprendizaje 4 cmslechonahp
 
Página Web Gilberto García
Página Web Gilberto GarcíaPágina Web Gilberto García
Página Web Gilberto Garcíagilbertogt_18
 

Similar a UWE (20)

lenguaje web
lenguaje weblenguaje web
lenguaje web
 
Prog webuni3
Prog webuni3Prog webuni3
Prog webuni3
 
15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC
15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC
15-Unidad 4: Introducción a las Arquitecturas Web 4.1 DAO 4.2 MVC
 
Unidad 1
Unidad 1Unidad 1
Unidad 1
 
Prog webuni3
Prog webuni3Prog webuni3
Prog webuni3
 
Web2
Web2Web2
Web2
 
Programación web
Programación webProgramación web
Programación web
 
15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB Contenidos: 4.1 Dao 4.2 Mv...
15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB  Contenidos:  4.1 Dao  4.2 Mv...15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB  Contenidos:  4.1 Dao  4.2 Mv...
15-TEMA: 4. INTRODUCCION A LAS ARQUITECTURASWEB Contenidos: 4.1 Dao 4.2 Mv...
 
Resultado de aprendizaje
Resultado de aprendizajeResultado de aprendizaje
Resultado de aprendizaje
 
aplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.pptaplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.ppt
 
aplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.pptaplicaciones_web_advantage_multimedia.ppt
aplicaciones_web_advantage_multimedia.ppt
 
Diseño de aplicaciónes Web.pptx
Diseño de aplicaciónes Web.pptxDiseño de aplicaciónes Web.pptx
Diseño de aplicaciónes Web.pptx
 
Ria
RiaRia
Ria
 
Capitulo1
Capitulo1Capitulo1
Capitulo1
 
Capitulo1
Capitulo1Capitulo1
Capitulo1
 
Marco conceptual
Marco conceptualMarco conceptual
Marco conceptual
 
Prog. web. equipo 5
Prog. web. equipo 5Prog. web. equipo 5
Prog. web. equipo 5
 
Guia de aprendizaje 4 cms
Guia de aprendizaje 4 cmsGuia de aprendizaje 4 cms
Guia de aprendizaje 4 cms
 
Página Web Gilberto García
Página Web Gilberto GarcíaPágina Web Gilberto García
Página Web Gilberto García
 
Arquitectura Web
Arquitectura WebArquitectura Web
Arquitectura Web
 

Más de Facultad de Ciencias y Sistemas

Introducción a la progrogramación orientada a objetos con Java
Introducción a la progrogramación orientada a objetos con JavaIntroducción a la progrogramación orientada a objetos con Java
Introducción a la progrogramación orientada a objetos con JavaFacultad de Ciencias y Sistemas
 

Más de Facultad de Ciencias y Sistemas (20)

Ejercicios HTML 5
Ejercicios HTML 5Ejercicios HTML 5
Ejercicios HTML 5
 
CSS3
CSS3CSS3
CSS3
 
09 ordenamiento-en-vectores-en-c
09 ordenamiento-en-vectores-en-c09 ordenamiento-en-vectores-en-c
09 ordenamiento-en-vectores-en-c
 
08 mas-de-vectores-en-c
08 mas-de-vectores-en-c08 mas-de-vectores-en-c
08 mas-de-vectores-en-c
 
07 vectores-en-c final
07 vectores-en-c final07 vectores-en-c final
07 vectores-en-c final
 
06 clases-en-c
06 clases-en-c06 clases-en-c
06 clases-en-c
 
05 cadenas-de-caracteres-en-c
05 cadenas-de-caracteres-en-c05 cadenas-de-caracteres-en-c
05 cadenas-de-caracteres-en-c
 
04 mas-estructuras-iterativas-en-c
04 mas-estructuras-iterativas-en-c04 mas-estructuras-iterativas-en-c
04 mas-estructuras-iterativas-en-c
 
03 estructuras-iterativas-en-c
03 estructuras-iterativas-en-c03 estructuras-iterativas-en-c
03 estructuras-iterativas-en-c
 
02 mas-de-las-estructuras-de-programacion-en-c
02 mas-de-las-estructuras-de-programacion-en-c02 mas-de-las-estructuras-de-programacion-en-c
02 mas-de-las-estructuras-de-programacion-en-c
 
01 estructuras-de-programacion-en-c
01 estructuras-de-programacion-en-c01 estructuras-de-programacion-en-c
01 estructuras-de-programacion-en-c
 
Procesamiento del lenguaje natural con python
Procesamiento del lenguaje natural con pythonProcesamiento del lenguaje natural con python
Procesamiento del lenguaje natural con python
 
Actividades de aprendizaje en Moodle
Actividades de aprendizaje en MoodleActividades de aprendizaje en Moodle
Actividades de aprendizaje en Moodle
 
Creación de grupos en Moodle
Creación de grupos en MoodleCreación de grupos en Moodle
Creación de grupos en Moodle
 
Introducción a la progrogramación orientada a objetos con Java
Introducción a la progrogramación orientada a objetos con JavaIntroducción a la progrogramación orientada a objetos con Java
Introducción a la progrogramación orientada a objetos con Java
 
Como crear un diagrama de clases
Como crear un diagrama de clasesComo crear un diagrama de clases
Como crear un diagrama de clases
 
Diagrama de clases - Ejemplo monográfico 02
Diagrama de clases - Ejemplo monográfico 02Diagrama de clases - Ejemplo monográfico 02
Diagrama de clases - Ejemplo monográfico 02
 
Diagrama de clases - Ejemplo monográfico 01
Diagrama de clases - Ejemplo monográfico 01Diagrama de clases - Ejemplo monográfico 01
Diagrama de clases - Ejemplo monográfico 01
 
Otro ejemplo de diagrama de clases UML
Otro ejemplo de diagrama de clases UMLOtro ejemplo de diagrama de clases UML
Otro ejemplo de diagrama de clases UML
 
Un ejemplo de diagrama de clases
Un ejemplo de diagrama de clasesUn ejemplo de diagrama de clases
Un ejemplo de diagrama de clases
 

Último

Tema 4. Gráfica Tridimiensional 25-02-24.pdf
Tema 4. Gráfica Tridimiensional 25-02-24.pdfTema 4. Gráfica Tridimiensional 25-02-24.pdf
Tema 4. Gráfica Tridimiensional 25-02-24.pdfNoe Castillo
 
La mano de Irulegi y los Vascones: del mito a la ciencia
La mano de Irulegi y los Vascones: del mito a la cienciaLa mano de Irulegi y los Vascones: del mito a la ciencia
La mano de Irulegi y los Vascones: del mito a la cienciaJavier Andreu
 
Tema 3 Clasificación de los seres vivos 2024.pdf
Tema 3 Clasificación de los seres vivos 2024.pdfTema 3 Clasificación de los seres vivos 2024.pdf
Tema 3 Clasificación de los seres vivos 2024.pdfIES Vicent Andres Estelles
 
RM N° 587-2023-minedu norma para elñ año escolar 2024pdf
RM N° 587-2023-minedu norma para elñ año escolar 2024pdfRM N° 587-2023-minedu norma para elñ año escolar 2024pdf
RM N° 587-2023-minedu norma para elñ año escolar 2024pdfmiguelracso
 
LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...
LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...
LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...JAVIER SOLIS NOYOLA
 
Hitos históricos de la transformación del PODER GLOBAL II.pptx
Hitos históricos de la transformación del PODER GLOBAL II.pptxHitos históricos de la transformación del PODER GLOBAL II.pptx
Hitos históricos de la transformación del PODER GLOBAL II.pptxsubfabian
 
Comunidad de aprendizaje virtuales Presentacion Slide Share.
Comunidad de aprendizaje virtuales Presentacion Slide Share.Comunidad de aprendizaje virtuales Presentacion Slide Share.
Comunidad de aprendizaje virtuales Presentacion Slide Share.NoelyLopez1
 
Sopa de letras - vocabulario Cuerpo humano.pdf
Sopa de letras - vocabulario Cuerpo humano.pdfSopa de letras - vocabulario Cuerpo humano.pdf
Sopa de letras - vocabulario Cuerpo humano.pdfEspanhol Online
 
Los lambayecanos no son mochicas (ni mocheros)
Los lambayecanos no son mochicas (ni mocheros)Los lambayecanos no son mochicas (ni mocheros)
Los lambayecanos no son mochicas (ni mocheros)yevivo4827
 
SEMANA DE GESTION I LAS DUNAS primaria.pptx
SEMANA DE GESTION I LAS DUNAS primaria.pptxSEMANA DE GESTION I LAS DUNAS primaria.pptx
SEMANA DE GESTION I LAS DUNAS primaria.pptxMaryCruzHernandez6
 
VIDEOS DE APOYO TECNOLOGIA PRIMER PERIODO
VIDEOS DE APOYO TECNOLOGIA PRIMER PERIODOVIDEOS DE APOYO TECNOLOGIA PRIMER PERIODO
VIDEOS DE APOYO TECNOLOGIA PRIMER PERIODOSofiaDiaz692624
 
Diapositivas abarcando el tema del citosol
Diapositivas abarcando el tema del citosolDiapositivas abarcando el tema del citosol
Diapositivas abarcando el tema del citosolchacaguasaydayana284
 
Diapositivas acerca de la Mitocondria.pdf
Diapositivas acerca de la Mitocondria.pdfDiapositivas acerca de la Mitocondria.pdf
Diapositivas acerca de la Mitocondria.pdfchacaguasaydayana284
 
Cambios en los seres vivos , evolución, evidencia.
Cambios en los seres vivos , evolución, evidencia.Cambios en los seres vivos , evolución, evidencia.
Cambios en los seres vivos , evolución, evidencia.CrisEli1
 
Diapositivas acerca de la Biología celular
Diapositivas acerca de la  Biología celularDiapositivas acerca de la  Biología celular
Diapositivas acerca de la Biología celularchacaguasaydayana284
 
c2.hu2.p3.p9.Políticas de lo colectivo.pptx
c2.hu2.p3.p9.Políticas de lo colectivo.pptxc2.hu2.p3.p9.Políticas de lo colectivo.pptx
c2.hu2.p3.p9.Políticas de lo colectivo.pptxMartín Ramírez
 
Sesión: ¡Bendito el que viene en el nombre del Señor!
Sesión: ¡Bendito el que viene en el nombre del Señor!Sesión: ¡Bendito el que viene en el nombre del Señor!
Sesión: ¡Bendito el que viene en el nombre del Señor!https://gramadal.wordpress.com/
 
240.Exam1.Rev. Spring24.pptxadsfadfadfdd
240.Exam1.Rev. Spring24.pptxadsfadfadfdd240.Exam1.Rev. Spring24.pptxadsfadfadfdd
240.Exam1.Rev. Spring24.pptxadsfadfadfddbrianjars
 
Comunidad virtual sus características principales
Comunidad virtual sus características principalesComunidad virtual sus características principales
Comunidad virtual sus características principalesJoselinMaldonadoRami
 

Último (20)

Tema 4. Gráfica Tridimiensional 25-02-24.pdf
Tema 4. Gráfica Tridimiensional 25-02-24.pdfTema 4. Gráfica Tridimiensional 25-02-24.pdf
Tema 4. Gráfica Tridimiensional 25-02-24.pdf
 
1ER GRADO PRESENTACIÓN PEDAGOGÍA PRODUCTIVA.
1ER GRADO PRESENTACIÓN PEDAGOGÍA PRODUCTIVA.1ER GRADO PRESENTACIÓN PEDAGOGÍA PRODUCTIVA.
1ER GRADO PRESENTACIÓN PEDAGOGÍA PRODUCTIVA.
 
La mano de Irulegi y los Vascones: del mito a la ciencia
La mano de Irulegi y los Vascones: del mito a la cienciaLa mano de Irulegi y los Vascones: del mito a la ciencia
La mano de Irulegi y los Vascones: del mito a la ciencia
 
Tema 3 Clasificación de los seres vivos 2024.pdf
Tema 3 Clasificación de los seres vivos 2024.pdfTema 3 Clasificación de los seres vivos 2024.pdf
Tema 3 Clasificación de los seres vivos 2024.pdf
 
RM N° 587-2023-minedu norma para elñ año escolar 2024pdf
RM N° 587-2023-minedu norma para elñ año escolar 2024pdfRM N° 587-2023-minedu norma para elñ año escolar 2024pdf
RM N° 587-2023-minedu norma para elñ año escolar 2024pdf
 
LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...
LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...
LOS NÚMEROS Y EL ECLIPSE SEGURO. Cuento literario escrito y diseñado por JAVI...
 
Hitos históricos de la transformación del PODER GLOBAL II.pptx
Hitos históricos de la transformación del PODER GLOBAL II.pptxHitos históricos de la transformación del PODER GLOBAL II.pptx
Hitos históricos de la transformación del PODER GLOBAL II.pptx
 
Comunidad de aprendizaje virtuales Presentacion Slide Share.
Comunidad de aprendizaje virtuales Presentacion Slide Share.Comunidad de aprendizaje virtuales Presentacion Slide Share.
Comunidad de aprendizaje virtuales Presentacion Slide Share.
 
Sopa de letras - vocabulario Cuerpo humano.pdf
Sopa de letras - vocabulario Cuerpo humano.pdfSopa de letras - vocabulario Cuerpo humano.pdf
Sopa de letras - vocabulario Cuerpo humano.pdf
 
Los lambayecanos no son mochicas (ni mocheros)
Los lambayecanos no son mochicas (ni mocheros)Los lambayecanos no son mochicas (ni mocheros)
Los lambayecanos no son mochicas (ni mocheros)
 
SEMANA DE GESTION I LAS DUNAS primaria.pptx
SEMANA DE GESTION I LAS DUNAS primaria.pptxSEMANA DE GESTION I LAS DUNAS primaria.pptx
SEMANA DE GESTION I LAS DUNAS primaria.pptx
 
VIDEOS DE APOYO TECNOLOGIA PRIMER PERIODO
VIDEOS DE APOYO TECNOLOGIA PRIMER PERIODOVIDEOS DE APOYO TECNOLOGIA PRIMER PERIODO
VIDEOS DE APOYO TECNOLOGIA PRIMER PERIODO
 
Diapositivas abarcando el tema del citosol
Diapositivas abarcando el tema del citosolDiapositivas abarcando el tema del citosol
Diapositivas abarcando el tema del citosol
 
Diapositivas acerca de la Mitocondria.pdf
Diapositivas acerca de la Mitocondria.pdfDiapositivas acerca de la Mitocondria.pdf
Diapositivas acerca de la Mitocondria.pdf
 
Cambios en los seres vivos , evolución, evidencia.
Cambios en los seres vivos , evolución, evidencia.Cambios en los seres vivos , evolución, evidencia.
Cambios en los seres vivos , evolución, evidencia.
 
Diapositivas acerca de la Biología celular
Diapositivas acerca de la  Biología celularDiapositivas acerca de la  Biología celular
Diapositivas acerca de la Biología celular
 
c2.hu2.p3.p9.Políticas de lo colectivo.pptx
c2.hu2.p3.p9.Políticas de lo colectivo.pptxc2.hu2.p3.p9.Políticas de lo colectivo.pptx
c2.hu2.p3.p9.Políticas de lo colectivo.pptx
 
Sesión: ¡Bendito el que viene en el nombre del Señor!
Sesión: ¡Bendito el que viene en el nombre del Señor!Sesión: ¡Bendito el que viene en el nombre del Señor!
Sesión: ¡Bendito el que viene en el nombre del Señor!
 
240.Exam1.Rev. Spring24.pptxadsfadfadfdd
240.Exam1.Rev. Spring24.pptxadsfadfadfdd240.Exam1.Rev. Spring24.pptxadsfadfadfdd
240.Exam1.Rev. Spring24.pptxadsfadfadfdd
 
Comunidad virtual sus características principales
Comunidad virtual sus características principalesComunidad virtual sus características principales
Comunidad virtual sus características principales
 

UWE

  • 2. Introducción. En los años 1980 se propuso que la mejor forma de desarrollar un sistema software era por medio de una planificación rígida y meticulosa del proyecto, soportada por herramientas CASE (Ingeniería de Software Asistida por Computador) y algunos procesos de desarrollo rigurosos y altamente controlados, que eran sinónimo de garantía y calidad en el software. Estas metodologías tenían una carga de trabajo pesada en planificación, diseño y documentación, absorbiendo gran parte del tiempo destinado al desarrollo del sistema.
  • 3. Introducción. En los años 1990 se comenzaron a proponer métodos ágiles para el desarrollo de software, que permitieran a los desarrolladores concentrarse en el software y no totalmente en el diseño y documentación del mismo. Éstas metodologías tienen un enfoque iterativo para la especificación, el desarrollo y la entrega del producto, teniendo como principio que los requerimientos podían cambiar permanentemente y durante el proceso de desarrollo, entregando sistemas funcionales más rápidamente con la posibilidad de agregar nuevos cambios en las especificaciones.
  • 4. Introducción. En la actualidad, el proceso de desarrollo de software ha sido abordado desde diferentes metodologías, las cuales tienen diferentes enfoques para la captura de requerimientos y el proceso de desarrollo del sistema software, algunas de ellas se basan en analizar y documentar rigurosamente las especificaciones del sistema, para luego realizar un desarrollo y posteriormente efectuar las pruebas. Otros métodos proponen centrarse en la organización del equipo de trabajo, incluir al cliente activamente y en arrojar resultados satisfactorios más rápidamente. Sea cual fuere la metodología es conveniente saber que éstas se eligen e implementan de acuerdo a la naturaleza del proyecto, llegando incluso a combinarse entre sí para lograr mejores resultados.
  • 5. Introducción. El avance de Internet y las comunicaciones ha provocado en los últimos años el nacimiento de nuevas propuestas metodológicas para la web. La web se ha convertido por méritos propios en el medio de comunicación por excelencia del siglo XXI. Resulta difícil decir algo original para justificar el tremendo impacto que tiene y seguirá teniendo en el devenir de nuestra civilización. Entre sus muchos aportes, destaca la rapidez con la cual se intercambia la información que unida a la eliminación de las barreras geográficas, han convertido Internet en un terreno fértil en el cual las empresas pueden extender sus negocios.
  • 6. Introducción. Como consecuencia ha proliferado el número de aplicaciones web para la resolución de las necesidades de las organizaciones. A diferencia de las aplicaciones tradicionales desarrolladas para una plataforma tecnológica concreta, las aplicaciones web potencialmente pueden llegar a cualquier tipo de dispositivo. Por tanto este nuevo paradigma de desarrollo se está utilizando cada vez más para implementar aplicaciones gubernamentales, de enseñanza a distancia o de gestión empresarial entre otras.
  • 8. Introducción. ¿Qué es una Aplicación Web? Es un Sistema de Información donde una gran cantidad de datos volátiles, altamente estructurados, van a ser consultados, procesados y analizados mediante navegadores. Una de las principales características va a ser su alto grado de interacción con el usuario, y el diseño de su interfaz debe ser claro, simple y debe estar estructurado de tal manera que sea orientativo para cada tipo de usuarios.
  • 9. Introducción. DEMORAS EN CARGA NECESITO INFORMACIÓN ENCONTRE LO QUE BUSCO NECESIDAD INSATISFECHA SITIO CAÍDO ERRORES EN NAVEGACIÓN CONTENIDOS POBRES NO CUMPLE EXPECTATIVAS POCA IDENTIFICACIÓN CONFUSO DIFICULTAD DE USO POCO ATRACTIVO ¿EL SISTEMA ES USABLE?
  • 10. Introducción. Arquitectura de las aplicaciones web. DOS NIVELES: Es la más simple, se tiene el nivel del “Cliente” y el nivel del “Servidor”.
  • 11. Introducción. Arquitectura de las aplicaciones web. TRES NIVELES: 1. El primer nivel consiste en la capa de presentación que incluye no sólo el navegador, sino también el servidor web que es el responsable de dar a los datos un formato adecuado. 2. El segundo nivel está referido habitualmente a algún tipo de programa o script. 3. Finalmente, el tercer nivel proporciona al segundo los datos necesarios para su ejecución.
  • 12. Introducción. Arquitectura de las aplicaciones web. TRES NIVELES:
  • 13. Introducción. El servidor web Es un programa que implementa el protocolo HTTP. Este protocolo pertenece a la capa de aplicación del modelo OSI y está diseñado para transferir lo que se llama hipertextos, páginas web o páginas HTML: textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de música.
  • 14. Introducción. Algunos ejemplos de servidor web • CERN httpd. • Apache (Libre, servidor más usado del mundo, según Wikipedia.) • IIS. • Resin. • Tomcat (Libre, del proyecto Jakarta de Apache.) • Geronimo (Libre, orientado a J2EE, del proyecto Jakarta de Apache, actualmente se encuentra en desarrollo.) • JBoss. • JOnAS. • Cherokee.
  • 15. Introducción. Son varias las ventajas que proporciona resolver la problemática de una organización a través de una aplicación web. En primer lugar para su uso, el usuario final sólo necesita conocer el uso de un navegador Web. Por lo tanto, no es necesario que asimile conocimientos de instalación o configuración. En segundo lugar, debido a que el desarrollo web se basa en estándares aceptados (HTTP, HTML, XML, etc.) y tecnologías multiplataforma (JavaScript, etc.) se soluciona el problema de generar software para distintos sistemas operativos o dispositivos. La misma aplicación web puede usarse con Internet Explorer de Windows o en un smartphone con un navegador móvil.
  • 16. Introducción. Lenguajes de programación del lado del cliente. 1. Los programas del lado del cliente están incluidos dentro de la página HTML, se descargan del servidor junto con este. 2. Los programas se ejecutan dentro del ámbito del browser.
  • 17. Introducción. Tecnologías y lenguajes del lado del cliente. 1. Navegadores para Web. 2. HTML. 3. Javascript y Vbscript. 4. Applets en Java. 5. Flash (Lenguaje ActionScript.) 6. XML. 7. PDF. 8. AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML.)
  • 18. Introducción. Tecnologías y lenguajes del lado del cliente. 1. Algunos de estos lenguajes y tecnologías requieren de un programa especial (plug-in) instalado en la computadora del usuario. Ejemplo: Adobe Flash Player. 2. Un complemento (o plug-in en inglés) es una aplicación que se relaciona con otra para aportarle una función nueva y generalmente muy especifica. Esta aplicación adicional es ejecutada por la aplicación principal e interactúan por medio de la API.
  • 19. Introducción. Lenguajes de programación del lado del servidor. 1. Se ejecutan en el servidor de Web y son dependientes de la plataforma del servidor. 2. Se usan para acceder a recursos del servidor, como bases de datos y generación de contenido dinámico para las páginas.
  • 20. Introducción. Lenguajes de programación del lado del servidor. • Por ejemplo, el ámbito de ejecución de una página ASP.NET.
  • 21. Introducción. Algunos ejemplos de lenguajes del lado del servidor: • ASP, ASP.NET (son tecnologías, soportan diferentes lenguajes como VB, C#, C++, etc.) • PHP. • JSP. • Perl. • Ruby. • Python. • XML.
  • 22. Introducción. Ambientes para el desarrollo de aplicaciones Web.: • Los IDE (ambientes integrados de desarrollo) para aplicaciones Web son muy numerosos. • Considerar los que permitan trabajar con los diferentes lenguajes para Web. • Algunos son específicos para lenguajes del lado del servidor. Por ejemplo, Visual Studio solo soporta ASP.NET del lado del servidor. • Existen IDE’s de buena cantidad, libres y gratuitos de buena calidad.
  • 23. Introducción. Algunos ejemplos de IDE para Web: • Microsoft Visual Studio. • Microsoft Web Developer Express. • Mono (para ASP.NET.) • NetBeans. • Jbuilder. • Eclipse.
  • 24. Introducción. Las aplicaciones web están más expuestas a ataques. Se pueden tener ataques en tres niveles: • A la computadora del usuario. • Al servidor. • A la información en tránsito. La seguridad en web tiene 3 etapas primarias: • Seguridad de la computadora del usuario. • Seguridad del servidor web y de sus datos. • Seguridad de la información que viaja entre el servidor Web y el usuario.
  • 25. Introducción. Seguridad de la computadora del usuario: Los usuarios deben contar con navegadores y plataformas seguras, libres de virus y vulnerabilidades. También debe garantizarse la privacidad de los datos del usuario. Seguridad del servidor web y de sus datos: Se debe garantizar la operación continua del servidor, que los datos no sean modificados sin autorización (integridad) y que la información sólo sea distribuida a las personas autorizadas (control de acceso.) Seguridad de la información que viaja entre el servidor web y el usuario: Garantizar que la información en tránsito no sea leída (confidencialidad), modificada o destruida por terceros. Asegurar que el enlace entre cliente y servidor no pueda interrumpirse fácilmente (disponibilidad.)
  • 26. Introducción. Se deben considerar los siguientes puntos: • Asegurar el servidor en una forma fundamental: el sistema operativo, ya sea por medio de actualizaciones (parches) y habilitando los mecanismos propios de la plataforma. • Garantizar la seguridad del servidor web propiamente (IIS, Apache, etc.) • Auditar las aplicaciones que interactúan en las dos capas anteriores (módulos, bibliotecas.) • Asegurando la red físicamente (switches en lugar de hubs). • Esconder la información (esteganografía). • Cifrar la información (criptografía) por medio de algoritmos diversos (SSL, VPNs). • Actualizar (parchar) el sistema operativo de los clientes. • Uso de antivirus, firewalls personales. • Educar a los usuarios.
  • 27. Introducción. En web se simplifica notablemente el mantenimiento de la aplicación, pues siempre se accede en el mismo servidor y ante un cambio no es necesario instalar una nueva versión en todos los dispositivos. Pero debido a esta rápida evolución y a la complejidad tecnológica añadida, el desarrollo de aplicaciones web se caracteriza por ser más costoso y complejo que el desarrollo tradicional de software. Lamentablemente los métodos de Ingeniería de Software tradicionales, no están adaptados para resolver los requisitos específicos de las aplicaciones web 2.0.
  • 28. Introducción. La Ingeniería Web surge para aplicar los fundamentos de la Ingeniería de Software sobre el desarrollo sistemático de aplicaciones web, atendiendo las características particulares propias de este tipo de aplicaciones. La mayoría de las propuestas metodológicas ha centrado su trabajo principalmente en las etapas de diseño e implementación y tratamiento de requisitos ha sido tratado con una menor importancia. En el año 1993 un grupo de expertos (F. Garzoto, D. Schwabe y P. Paolini) comienzan a desarrollar HDM. La hipermedia necesita métodos de trabajo específicos para tratar aspectos como la navegación o la interfaz. En 1995 se comienza a evolucionar hacia la orientación a objetos y nacen OOHDM y EORM.
  • 29. Introducción. A partir de ahí comienzan elaborarse diferentes metodologías de trabajo para la web. Sin embargo, desde 1999 (HFPM, WSDM, UWE, etc) se comienza a potenciar la ingeniería de requisitos. (Ferreira & Loucopoulos, 2001): El tratamiento de requisitos es el proceso mediante el cual se especifican y validan los servicios que debe proporcionar el sistema así como las restricciones sobre las que se deberá operar. Consiste en un proceso iterativo y cooperativo de análisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido.
  • 30. En el ámbito del desarrollo web no es usual modelar mucho las aplicaciones. Quizá es una de las razones por las que los desarrollos se tornan más complejos de lo pensado. En la mayoría de los proyectos complejos ya sean estos basados en web o de otro tipo, el cliente espera ver resultados rápidamente, de modo que se suele desestimar la importancia del buen análisis y modelado. Esta es una muy mala práctica, tomando en cuenta que muchas de la aplicaciones que se desarrollan hoy día y que interactúan en la red son sistemas de complejidad media o alta con la salvedad que opera sobre una plataforma web. Introducción.
  • 31. Y si el software que representan los sistemas de información web suelen ser la realización de las reglas de negocios de cada organización. En la medida que cambian estas reglas, el software tiene que cambiar también. Cuando se intentan modificar esas reglas para lograr una mayor efectividad y competitividad, el software tiene que adaptarse, en algunos casos implica la creación de un nuevo software, pero en otros significa la modificación o reconstrucción de algo ya existente para que pueda seguir satisfaciendo las necesidades cambiantes de los negocios. Ejemplos son la necesidad o conveniencia de colocar el sistema en Internet, la inestabilidad de la aplicación, la aparición de efectos colaterales graves e inesperados. Introducción.
  • 32. Por ello toda organización necesita una estrategia para la migración de sus sistemas antiguos basada en una metodología moderna que contenga toda clase de controles. Las metodologías web permiten especificar de mejor manera una aplicación, su proceso de creación, diseño entre otros. Proceden de manera iterativa e incremental y coinciden con UML en su mayoría. Las metodologías de Web maduras tal como OOHDM, UWE, WebML, OO-H, entre otras son ejemplos de metodologías que facilitan el diseño de una aplicación Web atacando los aspectos (conceptual, navegacional y de interfaz de usuario) por separado. Introducción.
  • 33. El análisis de requerimiento de aplicaciones web implica adquirir un entendimiento de las necesidades de todos aquellos interesados en el sistema; aquellos que están interesados en el mismo negocio corporativo. La mayoría de las veces, los requerimientos son acordados por los interesados de tal forma que la semántica y el significado de cada término o concepto utilizado es bien entendido. Sin embargo, cuando existen diferentes puntos de vista del mismo concepto de negocio, ambigüedades o inconsistencias pueden surgir, siendo estas perjudiciales para la Especificación de Requerimientos de Software (ERS.) Introducción.
  • 34. Tradicionalmente, las tareas de conciliación son realizadas utilizando técnicas y herramientas basadas principalmente en reuniones; con el objetivo de eliminar ambigüedad e inconsistencias en los requerimientos. Cuando la inconsistencia en requerimiento no es detectada a tiempo, ellos pueden convertirse en defectos en el software; siendo éste una de las razones más severas de que los proyectos superen el costo estimado ya que estos defectos deben ser resueltos en las etapas finales del proceso de desarrollo de software. Introducción.
  • 35. En este contexto, el esfuerzo para corregir las fallas es varios órdenes de magnitud mayor que corregir los requerimientos en las etapas tempranas del desarrollo del software. Las inconsistencias pueden surgir desde nuevos requerimientos, que introducen nuevas funcionalidades o mejoras a la aplicación, o, incluso, desde requerimientos existentes que cambian durante el proceso de desarrollo. Introducción.
  • 36. Por ejemplo, un sitio de comercio electrónico que provee un servicio pago de entrega a domicilio de productos, del tipo que ha sido utilizado en los ejemplos hasta el momento, puede planear una promoción para “Navidad”, donde algunos productos tienen el servicio de envío sin costo por un período de tiempo; mientras que el resto de los productos mantienen el costo usual del servicio. Este nuevo requerimiento introduce cambios que son percibidos por el usuario porque él puede ver banners promociónales en diferentes páginas. Introducción.
  • 37. Durante la especificación de requerimientos, existen casos donde dos o más escenarios que reflejan la misma lógica de negocio difieren sutilmente uno de otro produciendo una inconsistencia. Cuando estas inconsistencias están basadas en comportamientos contradictorios, nos encontramos con un conflicto de requerimientos. Los conflictos están caracterizados por tener diferencias en las características, conflictos lógicos (lo que se espera) o temporales (cuando se espera) entre acciones, o incluso diferencias en terminología que crea ambigüedad. Introducción.
  • 38. RUP es una metodología que tiene como objetivo ordenar y estructurar el desarrollo de software, en la cual se tienen un conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. Inicialmente fue llamada UP (Unified Process) y luego cambió su nombre a RUP por el respaldo de Rational Software de IBM. Ésta metodología fue lanzada en 1998 teniendo como sus creadores a Ivar Jacobson, Grady Booch y James Rumbaugh. El RUP nació del UML (Unified Modeling Language) y del UP. Introducción.
  • 39. Características del RUP El RUP es un proceso basado en los modelos en Cascada y por Componentes, el cual presenta las siguientes características:  Es dirigido por los casos de uso.  Es centrado en la arquitectura.  Es iterativo e incremental. Lo cual es fundamental para el proceso de desarrollo de software. A continuación se explican las tres características: Introducción.
  • 40. Características del RUP a. Casos de Uso: Describe un servicio que el usuario requiere del sistema, incluye la secuencia completa de interacciones entre el usuario y el sistema. Introducción.
  • 41. Características del RUP b. Centrado en la arquitectura: Comprende las diferentes vistas del sistema en desarrollo, que corresponden a los modelos del sistema: Modelos de casos de uso, de análisis, de diseño, de despliegue e implementación. La arquitectura del software es importante para comprender el sistema como un todo y a la vez en sus distintas partes, sirve para organizar el desarrollo, fomentar la reutilización de componentes y hacer evolucionar el sistema, es decir, agregarle más funcionalidad. Introducción.
  • 42. Características del RUP c. Iterativo e Incremental: Significa que la aplicación se divide en pequeños proyectos, los cuales incorporan una parte de las especificaciones, y el desarrollo de la misma es una iteración que va incrementando la funcionalidad del sistema de manera progresiva. Introducción.
  • 43. Características del RUP Una iteración está compuesta por los requisitos, análisis, diseño, implementación y pruebas; pero dicha iteración sólo entrega una parte pequeña pero funcional del sistema, de tal forma que los requisitos y demás modelos no se desarrollan en una sola iteración sino progresivamente, ello con la finalidad de poder garantizar entregas funcionales e iterativas y de tal forma ir completando el sistema software paso a paso. Cabe aclarar que una iteración también incluye otros artefactos, tales como la planificación y el análisis de la iteración, entre otras actividades específicas concebidas dentro de esa iteración. Introducción.
  • 44. Relaciones entre las metodologías web existentes.
  • 46. Introducción. WSDM SOHDM DDDP NDT UWA W2000 UWE RNA HFPM OOHDM 1. Seleccionar una metodología 2. Justificar por que usar la metodología seleccionada. 3. Seguir las etapas que establece la metodología seleccionada.
  • 47. La problemática propuesta estaría en relación al hecho si un sistema de información orientado a la web es usable o no. La solución a la problemática implementaría una metodología que investigue el comportamiento de los usuarios y que determine cuáles son las necesidades de información que buscan los usuarios en un sistema de información Web. Esta metodología entregaría las estrategias necesarias para estructurar y organizar el contenido utilizando estándares y herramientas dedicadas al tratamiento de usuarios. Introducción.
  • 49. La usabilidad mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la satisfacción y la productividad al encontrar rápidamente la información que buscan. La accesibilidad es que todos los usuarios pueden acceder en condiciones de equidad a los contenidos. La arquitectura de la información 2.0 aminora el costo en la búsqueda de información, la construcción y mantenimiento y la educación y capacitación. Introducción.
  • 51. Introducción. Fases de la metodología: IMPLEMENTACIÓN Y MANTENCIÓN IDENTIFICACIÓN DE REQUERIMIENTOS ANÁLISIS DISEÑO CONSTRUCCIÓN PLANIFICACIÓN ESTUDIO DE VIABILIDAD
  • 52. Introducción. PLANIFICACIÓN ESTRATÉGICA ABSTRACCIÓN Y ESTUDIO DE PROCESOS VISIÓN GENERAL Y ESTRATÉGICA DEL SISTEMA DEFINICIÓN DE OBJETIVOS Y NECESIDADES IDEA DE SISTEMA
  • 53. Introducción. ESTUDIO DE VIABILIDAD ESTUDIO DE IMPACTO EN LA ORGANIZACIÓN BENEFICIOS Y RIESGOS DEL PROYECTO SELECCIÓN DE ALTERNATIVA MODELO CONCEPTUAL DE SISTEMA
  • 55. Introducción. ANÁLISIS INTENCIÓN DE USO DEFINICIÓN DE INTERFACES MODELADO DE DATOS Y PROCESOS MODELO DE SISTEMA DE INFORMACIÓN PERFILES VALIDACIÓN REQUERIMIENTOS DEFINICIÓN DE REQUERIMIENTOS
  • 56. Introducción. DISEÑO VISUAL DISEÑO DE INTERACCIÓN ARQUITECTURA DE LA INFORMACIÓN PROTOTIPO WEB DEL SISTEMA VISTAS DE DISEÑO HERRAMIENTAS TECNOLÓGICAS DISEÑO DE CONTENIDO MODELO DE SISTEMA WEB DISEÑO
  • 58. Introducción. IMPLEMENTACIÓN Y MANTENIMIENTO IMPLEMENTACIÓN MANTENIMIENTO SISTEMA DE INFORMACIÓN WEB APROBADO PRUEBAS Y VALIDACIÓN REVISIÓN DE TAREAS SISTEMA CONSTRUIDO
  • 59. Introducción. INTERNET NECESITO INFORMACIÓN ENCONTRE LO QUE BUSCO FACTORES DE ÉXITO CONOCER A LOS USUARIOS TECNOLOGÍAS ACTUALES EL SISTEMA ES USABLE Y ACCESIBLE FACTORES CRÍTICOS EVALUACIÓN HUMANA RESPONSABLES COMPROMISO ORGANIZACIÓN
  • 60. WSDM: Web Site Design Method. 1997. • Define el sistema basado en los grupos de usuario. • Su proceso de definición de requisitos tiene por objetivo detectar los perfiles de usuario mediante dos tareas. • Clasificación de usuarios mediante el estudio del entorno. • Descripción de los grupos de usuario.
  • 61. SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology. 1998 • Esta propuesta ofrece un modelo de escenarios propia, denominada SAC, para representar los requisitos. • Para el desarrollo de los mismos hace uso del diagrama de contexto propuesto en los DFD. • Ha caido en desuso, principalmente por el uso de los DFD.
  • 62. RNA: Relationship Navigational Analysis. 1998 • Plantea una secuencia de pasos en la que separa el tratamiento de diferentes requisitos: • Análisis del Entorno • Elementos de Interés • Análisis del Conocimiento • Análisis de la Navegación • Implementación del Análisis • Está muy enfocada en un grupo de sistemas: Los sistemas legales y en la actualidad no es muy usada.
  • 63. HFPM: Hypermedia Flexible Process Modeling. 1999 Define un proceso detallado que cubre todo el ciclo de vida y que está compuesto por 13 fases. En la primera de ellas, modelado de requisitos, propone las tareas siguientes: • Descripción breve del problema. • Descripción de los requisitos funcionales. • Realización del modelo de datos. • Modelado de la interfaz de usuario. • Modelado de los requisitos no funcionales. No está siendo trabajada actualmente, sin embargo, fue la primera en definir ciertos aspectos:
  • 64. HFPM: Hypermedia Flexible Process Modeling. 1999 • Incluye al usuario desde el principio del desarrollo. • Introduce el concepto de la separación de aspectos, propuesto para el análisis, ya desde la Ingeniería de Requisitos. • Establece la necesidad de definir modelos específicos para el usuario. Aunque no define ninguno. • Establece la necesidad de elaborar manuales de usuario e incluir esto en el ciclo de vida.
  • 65. OOHDM: Object Oriented Hypermedia Design Model. 1999 Es un método orientado a modelos para el desarrollo de aplicaciones web. Permite a los diseñadores especificarla mediante el uso de varios meta-modelos especializados: conceptual, navegación y de interfaz de usuario. Cada meta-modelo pone foco en diferentes aspectos de una aplicación. Una vez que estos modelos han sido especificados para una aplicación dada, es posible generar código en tiempo de ejecución que implemente la aplicación; es decir, los diseños de la aplicación. Existen varios intérpretes de estos modelos encargados de producir una aplicación web basada en ellos: el ambiente HyperDE y el framework Cazon.
  • 66. OOHDM: Object Oriented Hypermedia Design Model. 1999 OOHDM utiliza mecanismos de abstracción y composición diferentes en un framework orientado a objetos, para permitir una descripción concisa de elementos de información correspondientes al negocio subyacente y la especificación de escenarios de navegación complejos según los datos del modelo conceptual y transformaciones de interfaz para hacer percibible la información indicada en el modelo anterior.
  • 67. OOHDM: Object Oriented Hypermedia Design Model. 1999 OOHDM, sucesor de HDM, es una propuesta (Rossi y Schwabe) ampliamente aceptada para la web, es una metodología de desarrollo para la elaboración de aplicaciones multimedia y tiene como objetivo simplificar y a la vez hacer más eficaz el diseño de aplicaciones hipermedia. Inicialmente no proponía la fase de Ingeniería de Requisitos y centraba su desarrollo en cuatro etapas:
  • 68. OOHDM: Fases de desarrollo 1. Análisis (o determinación) de requerimientos 2. Modelo (o diseño) conceptual (Análisis del dominio.): Obtiene esquemas conceptuales de las clases y las relaciones entre las mismas. 3. Modelo (o diseño) navegacional. 4. Modelo (o diseño) de interfaz abstracta. 5. Implementación.
  • 69. OOHDM: Object Oriented Hypermedia Design Model. 1999 OOHDM es una mezcla de estilos de desarrollo basado en prototipos, en desarrollo interactivo y de desarrollo incremental. En cada fase se elabora un modelo que recoge los aspectos que se trabajan en esa fase. Este modelo parte del modelo conseguido en la fase anterior y sirve como base para el modelo de la siguiente fase. Cada paso de diseño se enfoca en un aspecto de diseño particular, y, en consecuencia, un modelo es elaborado a partir de esto.
  • 70. OOHDM: Object Oriented Hypermedia Design Model. 1999 Propone un modelo para representar a las aplicaciones multimedia, propone un proceso predeterminado para el que indica las actividades a realizar y los productos que se deben obtener en cada fase del desarrollo. Toma como partida el modelo de clases que se obtiene en el análisis del Proceso Unificado de UML. A este modelo lo denomina modelo conceptual. Partiendo de este modelo conceptual, OOHDM propone ir añadiendo características que permitan incorporar a esta representación del sistema todos los aspectos propios de las aplicaciones multimedia.
  • 71. OOHDM: Object Oriented Hypermedia Design Model. 1999 En una segunda etapa de diseño, se parte de ese modelo y se le añaden los aspectos de navegación, generándose un nuevo modelo de clases denominado modelo navegacional. Por último, este modelo sirve como base para definir el modelo de interfaz abstracta, que representa la visión que del sistema tendrá cada usuario del mismo. En 2001, OOHDM tuvo una propuesta orientada a la ingeniería de requisitos denominada User Interaction Diagrams (UID.) La única herramienta disponible relacionada con OOHDM es HyperDE, pero se enfoca en SHDM (Semantic Hypermedia Design Method), una extensión original para construir aplicaciones semánticas.
  • 72. OOHDM: Fase 1. Determinación de Requerimientos. Se fundamenta en los diagramas de casos de usos, los cuales son diseñados por escenarios con la finalidad de obtener de manera clara los requerimientos y acciones del sistema. Primero es necesario la recopilación de requerimientos. Para ello, se necesitan identificar los actores y las tareas que ellos deben realizar. Luego, se determinan los escenarios para cada tarea y tipo de actor. Los casos de uso que surgen a partir de aquí, serán luego representados mediante los Diagramas de Interacción de Usuario (UIDs), los cuales proveen de una representación gráfica concisa de la interacción entre el usuario y el sistema durante la ejecución de alguna tarea.
  • 73. OOHDM: Fase 1. Determinación de Requerimientos. Con este tipo de diagramas se capturan los requisitos de la aplicación de manera independiente de la implementación. Para ello se deben proporcionar las respuestas a las siguientes interrogantes:  ¿Cuáles son los tópicos principales que serán atendidos?  ¿Cómo los tópicos están relacionados entre sí?  ¿Qué categoría de usuarios serán atendidos?  ¿Cuáles son las tareas principales que serán abordadas?  ¿Qué tareas corresponden a qué categoría de usuarios?  ¿Los recursos disponibles son competitivos con la información levantada?
  • 74. OOHDM: Fase 1. Determinación de Requerimientos. Con este tipo de diagramas se capturan los requisitos de la aplicación de manera independiente de la implementación. Para ello se deben proporcionar las respuestas a las siguientes interrogantes:  ¿Cuáles son los tópicos principales que serán atendidos?  ¿Cómo los tópicos están relacionados entre sí?  ¿Qué categoría de usuarios serán atendidos?  ¿Cuáles son las tareas principales que serán abordadas?  ¿Qué tareas corresponden a qué categoría de usuarios?  ¿Los recursos disponibles son competitivos con la información levantada? Se inicia obteniendo los requerimientos de los stakeholders (interesados en el sistema). Para ello, es necesario identificar los actores y las tareas que ellos deben realizar en casos de uso. Luego, los casos de uso son acopiados (o bosquejados) para cada tarea y tipo de actor utilizando Diagramas de Interacción de Usuario (UID, User Interaction Diagram). Estos diagramas proveen una representación concisa utilizando una metáfora gráfica del flujo de información entre el usuario y la aplicación durante la ejecución de una tarea. Los UIDs son validados con el actor del caso de uso y rediseñado, si fuese necesario, a partir del retorno que haya brindado este último.
  • 75. OOHDM: Fase 1. Determinación de Requerimientos. UID del caso de uso “Buscar película por nombre”.
  • 76. OOHDM: Fase 1. Determinación de Requerimientos. UID del caso de uso “Buscar película por nombre”. Con las elipses se grafican los paso de interacción (Interaction), dentro de estos se enumeran los elementos de datos que participarán de la interacción tanto de escritura (utilizando un rectángulo) o de solo lectura (sin detalle.) También es posible indicar conjuntos de datos usando puntos suspensivos “…” como prefijo al nombre del dato. La transición de una interacción a otra se especifica mediante una flecha llamada transición (Interaction) y las operaciones que son disparadas desde una interacción dada se especifican con una línea que se desprende de la interacción con una cabeza redonda y rellena en el otro extremo.
  • 77. OOHDM: Fase 2. Diseño Conceptual. Se construye un modelo orientado a objetos según (KOCH 2002) que represente el dominio de la aplicación usando las técnicas propias de la orientación a objetos. La finalidad principal durante esta fase es capturar el dominio semántico de la aplicación en la medida de lo posible, teniendo en cuenta el papel de los usuarios y las tareas que desarrollan. El resultado de esta fase es un modelo de clases relacionadas que se divide en subsistemas.
  • 78. OOHDM: Fase 2. Diseño Conceptual. Se construye un modelo orientado a objetos según (KOCH 2002) que represente el dominio de la aplicación usando las técnicas propias de la orientación a objetos. La finalidad principal durante esta fase es capturar el dominio semántico de la aplicación en la medida de lo posible, teniendo en cuenta el papel de los usuarios y las tareas que desarrollan. El resultado de esta fase es un modelo de clases relacionadas que se divide en subsistemas. En este paso se elabora un Modelo Conceptual de dominio de la aplicación utilizando principios de modelado orientados a objetos. En este paso solo se enfoca en la semántica del dominio de aplicación y no en los tipos de usuarios y tareas. OOHDM utiliza el meta-modelo de clases de UML (Unified Modelling Language), con pequeñas extensiones, para expresar el diseño conceptual.
  • 79. OOHDM: Fase 2. Diseño Conceptual. Fase de diseño conceptual de OOHDM.
  • 80. OOHDM: Fase 2. Diseño Conceptual. En OOHDM una aplicación se ve a través de un sistema de navegación. En la fase de diseño navegacional se debe diseñar la aplicación teniendo en cuenta las tareas que el usuario va a realizar sobre el sistema. Para ello, hay que partir del esquema conceptual desarrollado en la fase anterior. Hay que tener en cuenta que sobre un mismo esquema conceptual se pueden desarrollar diferentes modelos navegacionales (cada uno de los cuales dará origen a una aplicación diferente.) La estructura de navegación de una aplicación hipermedia está definida por un esquema de clases de navegación específica, que refleja una posible vista elegida.
  • 81. OOHDM: Fase 2. Diseño Conceptual. En OOHDM hay una serie de clases especiales predefinidas, que se conocen como clases navegacionales: • Nodos. • Enlaces. • Estructuras de acceso. Los cuales se organizan dentro de un: • Contexto navegacional.
  • 82. OOHDM: Fase 2. Diseño Conceptual. Nodos: Son contenedores básicos de información de las aplicaciones hipermedia. Son vistas orientadas a objeto de las clases definidas durante el diseño conceptual usando un lenguaje predefinido, permitiendo que un nodo sea definido mediante la combinación de atributos de clases diferentes relacionadas en el modelo de diseño conceptual. Los nodos contendrán atributos de tipos básicos (donde se pueden encontrar tipos como imágenes o sonidos) y enlaces.
  • 83. OOHDM: Fase 2. Diseño Conceptual. Enlaces: Los enlaces reflejan la relación de navegación que puede explorar el usuario. Para un mismo esquema conceptual puede haber diferentes esquemas navegacionales y los enlaces van a ser imprescindibles para poder crear esas vistas diferentes. Este modelo se obtiene a partir de una versión básica derivada desde los UIDs a la que se le aplicaron iteraciones de refinamientos donde se elimina información redundante; se aplican buenas prácticas de diseño de software tal como generalizaciones y especializaciones, patrones de diseño orientado a objetos, entre otro.
  • 85. OOHDM: Fase 3. Diseño Navegacional. Una aplicación web es concebida como una vista navegacional sobre un Modelo Conceptual. Esto refleja la mayor innovación de OOHDM también adoptado por UWE y WebML) la cual reconoce que los objetos que el usuario navega no son objetos conceptuales sino un tipo de objetos que se construye a partir de ellos para soportar tareas y una presentación adecuada de la información. Es decir, para cada perfil de usuario se puede definir una vista navegacional basada en la tarea que este tipo de usuario debe realizar, dicha vista refleja los datos y relaciones en el esquema conceptual.
  • 86. OOHDM: Fase 3. Diseño Navegacional. Estas definiciones pertenecen al Modelo Navegacional. En OOHDM existe un conjunto de tipos de básicos predefinidos de clases navegacionales usuales en aplicaciones de hipermedia: Nodo, Links, Anchors y estructuras de acceso. Los nodos representan la vista lógica sobre el Modelo Conceptual definidos a partir de un lenguaje de consulta. Desde una perspectiva O.O., los nodos implementan una variante del patrón Observer ya que presentan una vista particular de los objetos de negocio.
  • 87. OOHDM: Fase 3. Diseño Navegacional. Los cambios en el Modelo Conceptual son notificados inmediatamente a los nodos (objetos observadores) y, por otro lado, los nodos pueden invocar mensajes de los objetos del modelo conceptual a partir de eventos surgidos en la interfaz de usuario. En la actualidad, el patrón Observer es implementado utilizando requerimientos HTTP para actualizar la información presentada al usuario bajo demanda y solo un conjunto de tecnologías basadas en Javascript con XML de forma asincrónica (AJAX, Asynchronous JavaScript and XML) tal como Google Web Toolkit (GWT) soporta la notificación de cambios tal como lo indica el patrón.
  • 88. OOHDM: Fase 3. Diseño Navegacional. Links, se refiere a la realización hipermedial de las relaciones del modelo conceptual así como también las asociaciones. Pueden existir Links que no reflejen relaciones en el Modelo Conceptual que permiten mejorar, por ejemplo, la navegación de la aplicación. Las estructuras de acceso, tal como los índices, representan puntos de inicio de la navegación. Aplicaciones web diferentes (en el mismo dominio) pueden contener topologías de Nodos y Links debido a los perfiles de usuario.
  • 89. OOHDM: Fase 3. Diseño Navegacional.
  • 90. OOHDM: Fase 3. Diseño Navegacional. En el ejemplo Internet Movie Database (IMDB), la vista administrativa de un DVD puede indicar que por cada copia disponible cuándo esta debe ser retornada mientras que la perspectiva de un cliente no lo mostrará. Puede verse el Modelo de Navegación compuesto por Nodos y Links que rigen la navegación de la aplicación. Los nodos son usualmente contrapartes del modelo navegacional, pero muchas veces nodos específicos de la navegación pueden definirse como el caso del nodo “Orden” que permite modelar el pedido de compras que está realizando el usuario en el momento y agrupa todas las películas que éste desea adquirir.
  • 91. OOHDM: Fase 3. Diseño Navegacional. Los nodos navegacionales son objetos que pueden poseer métodos que encapsulan lógica específica de navegación de la aplicación tal como la resolución de ciertos datos mediante la ejecución de una consulta sobre el Modelo Conceptual. La mayoría de las aplicaciones web permiten realizar tareas que involucran un conjunto de objetos que representan conceptos similares tal como libros por autor, CDs por cantante, hoteles en una ciudad, etc.
  • 92. OOHDM: Fase 3. Diseño Navegacional. OOHDM estructura el espacio de navegación en conjuntos llamados contextos de navegación. Estos poseen las mismas alternativas de navegación y son significativos para cierto paso de alguna tarea que un usuario realice. Cada contexto navegacional es un conjunto de nodos, y es descrito especificando sus elementos, su estructura interna e índices asociados.
  • 93. OOHDM: Fase 3. Diseño Navegacional. Los contextos navegacionales juegan un rol análogo con respecto a la navegación que las clases con respecto a la estructura y comportamiento de los objetos. Se puede modelar un conjunto de actores en una película dirigida por un director, el conjunto de copias de DVD de una película, etc.
  • 94. OOHDM: Fase 4. Diseño de Interfaces. El diseño de interfaces puede separarse en dos tareas: 1. Diseño estructural. 2. Diseño de comportamiento.
  • 95. OOHDM: Fase 4. Descripción del contenido de interfaces. OOHDM utiliza Vistas de Datos Abstractas (ADV, Abstract Data View) para representar las interfaces de usuario que requiere una aplicación web. Un ADV tiene una estructura (expresada como un conjunto de atributos), comportamiento (definido como un conjunto de mensajes o eventos externos que éste puede manejar) y puede ser definido recursivamente componiendo otros ADVs. Dado su naturaleza estructurada, los ADVs pueden ser mapeados fácilmente en documentos XML facilitando así su escritura y edición.
  • 96. OOHDM: Fase 4. Descripción del contenido de interfaces. ADV del componente ChangeablePicture de la interfaz web. Este ADV está compuesto de forma anidada por otros ADVs primitivos como Imagen Picture o Text, mostrando como los componentes serán percibidos por el usuario.
  • 97. OOHDM: Fase 4. Descripción del contenido de interfaces. Pantalla esperada del ADV y con líneas punteadas se muestra la relación entre los elementos concretos y abstractos. La posición de los objetos anidados en el ADV refleja la apariencia (look and feel) de la interfaz siendo un medio efectivo para validar con el cliente cómo será el resultado final del desarrollo de la interfaz.
  • 98. OOHDM: Fase 4. Descripción del contenido de interfaces.
  • 99. OOHDM: Fase 4. Descripción del contenido de interfaces. Los ADVs observan Objetos de Datos Abstractos (ADO, Abstract Data Objects), conocidos como “dueños” de ADV, con dos objetivos: ser una vista de los datos y disparar comportamientos de aplicación o interfaz. Los ADV de la ilustración obtiene sus contenidos del correspondiente ADO; en este caso, un nodo del modelo navegacional.
  • 100. OOHDM: Fase 4. Descripción del contenido de interfaces. La relación entre el ADV y su ADO es descripta utilizando diagramas de configuración (configuration diagram), una combinación entre clases UML y diagramas de colaboración, mostrando qué mensajes son intercambiados entre el ADV (actuando como cliente de consulta) y el ADO (en role de servidor de datos). En la ilustración, el ADV ChangeablePicture resuelve información invocando los métodos getImage() y getText() del nodo ChangeablePicture. Esta información es utilizada para presentar los componentes de la interfaz concreta: Image, Description y SmallImage (arreglo de elementos). El parámetro “i” hace referencia al índice de la imagen seleccionada en el arreglo.
  • 101. OOHDM: Fase 4. Descripción del contenido de interfaces. En las aplicaciones web convencionales, usualmente se especifica un ADV anidado observando un único ADO. Esto puede ser la causa que el mismo nodo tenga varios ADVs (por ejemplo para proveer muchas interfaces), pero no es común que dos nodos (ADOs) yuxtapongan un único ADV. En aplicaciones web tipo RIA, puede necesitarse que un ADV consuma información desde diferentes ADOs (nodos) de acuerdo con las características de las interfaces. Nótese que los aspectos de comportamiento de una interfaz de aplicación web convencional son simples.
  • 102. OOHDM: Fase 4. Descripción del contenido de interfaces. Cuando un anchor es seleccionado, el ADV del nodo actual debe cerrarse y el correspondiente destino del link (otro nodo) debe abrirse. En consecuencia, hay otros comportamientos en aplicaciones Web interesantes pero no simples como, por ejemplo, permitir autocompletado de formularios.
  • 103. OOHDM: Fase 4. Descripción del contenido de interfaces. Luego que la interfaz ha sido completamente especificada, los modelos conceptuales, navegacionales y de interfaz son implementados en plataformas particulares. Para facilitar la adopción de la metodología OOHDM, se ha implementado un framework de ejecución, llamado Cazon, que soporta la generación semi-automática de código de modelos OOHDM, incluyendo la instanciación de páginas desde modelos navegacionales OOHDM.
  • 104. OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts. Las aplicaciones web RIAs se caracterizan por una interfaz dinámica y comportamiento rico que permite mejorar la experiencia del usuario. Mientras que los ADV permiten expresar características estáticas de las aplicaciones convencionales, OOHDM utiliza ADV-Charts para especificar aspectos dinámicos de estas aplicaciones. Los ADV-Charts son una variante de las máquinas de estado que permiten expresar las transformaciones de una interfaz que pueden surgir a partir de la interacción con un usuario.
  • 105. OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts. Una transición en un ADV-Chart es anotada con un identificador (ID), el/los evento/s que la causan, una precondición que debe ser satisfecha para disparar la transición, y una post-condición que es obtenido después que esta transición se procesa. La post-condición es expresada en términos de propiedades de objetos que son alterados luego que la transición ocurre.
  • 106. OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts. 1 Event: MouseOver PreCond: Focus (Icons[i]) PostCond: Image.getURL() = owner.getImage(i).getURL() Description.getText() = owner.getDescription(i)
  • 107. OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts. En el ejemplo, también se utiliza la función Focus que indica la posición del cursor y una pseudo variable PerCont (para referir el contexto de percepción) para indicar los objetos que son percibibles por el usuario. Cuando un objeto es “agregados” al conjunto PerCont este pasa a ser percibible por el usuario, caso contrario, cuando es “retirados”, este deja de ser visible. La palabra clave owner refiere al ADO observado que puede ser utilizado como parte de una definición de transición para consultar su estado.
  • 108. OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts. En la ilustración, puede verse el ADV-Chart especificando el comportamiento del ADV ChangeablePicture: cuando el mouse se encuentra sobre un ícono, los Widget gráficos correspondientes a la imagen actual y la descripción deben ser actualizados con datos icono seleccionado. El objeto propietario, u owner, del ADV es consultado por la información requerida en la actualización utilizando la posición en la lista (o índice) como parámetro. La flecha negra hacia el mismo estado señala que el componente SmallImage va a retornar al estado inicial luego que la transición está completa.
  • 109. OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts. Los ADV-Charts pueden componerse(a través del anidamiento de estados) indicando como los ADVs internos son afectados cuando el usuario interactúa con el sistema. Estos pueden también ser utilizados (en combinación con los diagramas de configuración) para indicar la forma como las operaciones navegacionales son disparadas por los eventos de interfaz. Mientras que los estados anidados en un ADV siguen la semántica de los Statecharts, significando que un ADV puede estar en algunos estados (mediante los operadores lógicos “Y” u “O”), el anidamiento de ADVs dentro de estados indica que el ADV es perceptible por el usuario en ese estado.
  • 110. UWE UML - Based Web Enginereeing. 1999.
  • 111. UWE. El desarrollo de aplicaciones web involucra decisiones no triviales de diseño e implementación que inevitablemente influyen en todo el proceso de desarrollo, afectando la división de tareas. Los problemas involucrados, como el diseño del modelo del dominio, modelo navegacional y la construcción de la interfaz de usuario, tienen requerimientos disjuntos que deben ser tratados por separado. A partir de esta separación de intereses, surgen las metodologías de desarrollo de aplicaciones web que permiten especificar los requerimientos atacando cada uno de sus aspectos más importantes: el modelo conceptual, navegacional y de interfaz de usuario.
  • 112. UWE. El modelo conceptual define cuáles serán los conceptos u objetos del negocio que serán manipulados en la aplicación. El modelo navegacional permite describir la información que será presentada usualmente agrupada en un nodo y la forma como interactuará con esta información a partir de las relaciones conceptuales; un nodo, por ejemplo, indica el criterio con el que se mostrarán lo objetos de negocio. Finalmente el modelo de interfaz de usuario especifica de qué forma se presentará la información al usuario y como éste la percibirá en términos de elementos visuales.
  • 113. UWE.  La utilización de UWE en los proyectos, es una de las buenas practicas de desarrollo y además provee la documentación necesaria para dar soporte a las aplicaciones desarrolladas, facilitando la implementación de las mismas.  Se podrían señalar muchas razones para que el uso de herramientas de representación adecuadas dos de ellas sin embargo pueden ser significativas a mediano plazo.  Los lenguajes de programación web están evolucionando hacia la orientación a objetos, PHP y ASP:net ya están en ese camino, otros como Java, Python y C# son ya orientados a objetos.  Las aplicaciones, programas y servicios están cada vez más integradas o encaminadas a la web. Pese a esto muchos programadores, desarrolladores y analistas aún no actualizan sus "cajas de herramientas".
  • 114. UWE.  La principal característica de UWE es el hecho de ser una aproximación basada en estándares, la cual no se limita al uso de UML, además integra:  XMI como modelo de intercambio de formatos,  MOF para los metamodelos.  Principios de la aproximación MDA (dirigida por el modelo),  El modelo de transformación del lenguaje QVT y  XML
  • 115. UWE. La razón principal para extender UML en lugar de crear una técnica de modelamiento propietaria, es la aceptación de UML en el proceso de desarrollo de software, la flexibilidad para la definición de un lenguaje de modelamiento específico en el dominio WEB, también llamado perfil UML, y un gran soporte del modelo de visualización con las herramientas existentes de UML CASE.
  • 116. UWE.  Es una herramienta para modelar aplicaciones web, utilizada en la ingeniería web, prestando especial atención en la sistematización y la personalización.  Es una propuesta basada en el proceso unificado y UML pero adaptada a la web.  Es una metodología detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Modelado.  En requisitos separa las fases de captura, definición y validación. Hace además una clasificación y un tratamiento especial dependiendo del carácter de cada requisito.
  • 117. UWE.  UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.  Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la definición de un meta- modelo (modelo de referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para la definición de restricciones sobre los modelos.
  • 118. UWE.  UWE cubre todo el ciclo de vida de este tipo de aplicaciones centrando además su atención en aplicaciones personalizadas o adaptativas.  Su proceso de desarrollo se basa en tres fases principales: la fase de captura de requisitos, la fase de análisis y diseño y la fase de implementación.  UWE detalla el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado.
  • 119. UWE.  UWE se caracteriza por la importancia que da a la segunda fase, la de análisis y diseño. Todo el proceso de desarrollo de UWE se encuentra detallado y definido, así como la estructura de los modelos que se van generando. Sin embargo es en el análisis y diseño donde se enfoca más la propuesta.  Su iteratividad e incrementalidad incluye flujos de trabajo y puntos de control; y sus fases coinciden con las propuestas de RUP.
  • 120. UWE. Características principales.  Notación estándar.  Métodos definidos: Pasos definidos para la construcción de cada modelo.  Especificación de restricciones: Recomendables de forma escrita.  Se basa en OCL (Objetc Constraint Language, lenguaje de restricciones para objetos.)
  • 121. UWE.  Los principales de aspectos en los que se fundamenta UWE son los siguientes: Lenguaje de modelado unificado). Uso de una notación estándar, para todos los modelos (UML)  En requisitos separa las fases de captura, definición y  validación.  Hace además una clasificación y un tratamiento especial dependiendo del carácter de cada requisito.  Entra las ventajas más importantes de UWE es su uso 100% UML.  Ofrece una herramienta denominada ArgoUWE.
  • 122. UWE.  UWE apunta a construir un modelo conceptual de una aplicación Web, procurando hacer caso en la medida de lo posible de cuestiones relacionadas con la navegación, y de los aspectos de interacción de la aplicación Web.  La construcción de este modelo lógico-conceptual se debe llevar a cabo de acuerdo con los casos de uso que se definen en la especificación de requerimientos.  Es una notación y en un método. La notación se basa en UML (OMG, 2003): para aplicaciones web en general y para aplicaciones adaptativas en particular.
  • 123. UWE. El método consta de seis modelos:  Modelo de casos de uso para capturar los requisitos funcionales del sistema.  Modelo conceptual para el contenido (modelo del dominio). Usa el diagrama de clase con gran porcentaje de detalle.  Modelo de usuario: modelo de navegación que incluye modelos estáticos y dinámicos.  Modelo de estructura de presentación, modelo de flujo de presentación.  Modelo abstracto de interfaz de usuario y modelo de ciclo de vida del objeto.  Modelo de adaptación.
  • 124. UWE.  El modelo conceptual incluye los objetos implicados en las actividades típicas que los usuarios realizarán en la aplicación Web.  Modelo de navegación: Consta de la construcción de dos modelos de navegación, el modelo del espacio de navegación y el modelo de la estructura de navegación. El primero especifica que objetos serán visitados por el navegador a través de la aplicación. El segundo define como se relacionarán, amplía el modelo con estructuras de acceso como índices, consultas, etc.  Modelo de presentación: Describe dónde y cómo los objetos de navegación y accesos primitivos serán presentados al usuario, es decir, una representación esquemática de los objetos visibles al usuario.
  • 125. UWE. En el modelo de presentación se incluyen las interfaces de usuario por medio de vistas estándares de interacción. En este modelo se distinguen dos vistas diferentes:  Estructura de la vista: Muestra la estructura del espacio de presentación.  Interfaz de usuario: Vista que presenta detalles acerca de los elementos de la interfaz de usuario dentro de las páginas.
  • 126. UWE.  Interacción Temporal: Presenta los objetos que participan en la interacción y la secuencia de los mensajes enviados entre ellos.  Escenarios Web: Permiten detallar la parte dinámica del modelo de navegación, especificándoles eventos que disparan las situaciones, definen condiciones y explícitamente incluyen las acciones que son realizadas. Junto con el modelo de interacción temporal, los escenarios web proveen la representación funcional dinámica del modelo de navegación.  Diagramas: Los diagramas usados por UWE, son diagramas UML puro. Entre los más importantes tenemos: Diagramas de estado, de secuencia, de colaboración y diagramas de actividad.
  • 127. UWE.  UWE permite que un diseñador Web pueda también hacer uso de otra técnica de modelado UML que agreguen otras vistas de la aplicación, en otras palabras, UWE no limita el número de vistas posibles de una aplicación.
  • 128. UWE. Capturar requisitos Analizar y diseñar Implementar
  • 129. UWE: Fases. 1. Captura, análisis y especificación de requisitos: Durante esta fase, se adquieren, reúnen y especifican las características funcionales y no funcionales que deberá cumplir la aplicación web. Trata de diferente forma las necesidades de información, las necesidades de navegación, las necesidades de adaptación y las de interfaz de usuario, así como algunos requisitos adicionales. Centra el trabajo en el estudio de los casos de uso, la generación de los glosarios y el prototipado de la interfaz de usuario.
  • 130. UWE: Fases. 2. Diseño del sistema: Se basa en la especificación de requisitos producido por el análisis de los requerimientos (fase de análisis), el diseño define cómo estos requisitos se cumplirán, la estructura que debe darse a la aplicación web. UWE engloba más aspectos que OOHDM, distingue entre diseño conceptual, de modelo de usuario, de navegación, de presentación, de adaptación, de la arquitectura, en el diseño detallado de las clases y en la definición de los subsistemas e interfaces.
  • 131. UWE: Fases. 3. Codificación del software: Durante esta etapa se realizan las tareas que comúnmente se conocen como programación; que consiste, esencialmente, en llevar a código fuente, en el lenguaje de programación elegido, todo lo diseñado en la fase anterior.
  • 132. UWE: Fases. 4. Pruebas: Las pruebas se utilizan para asegurar el correcto funcionamiento de secciones de código.
  • 133. UWE: Fases. 5. La instalación o fase de implementación: Proceso por el cual los programas desarrollados son transferidos apropiadamente al computador destino, inicializados, y, eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el usuario final. Incluye la implementación de la arquitectura, la estructura del hiperespacio, el modelo de usuario, la interfaz de usuario, los mecanismos adaptativos y las tareas referentes a la integración de estas implementaciones.
  • 134. UWE: Fases. UWE considera los requisitos de navegación como un tipo de requisito funcional y, aunque realmente no propone técnicas específicas para este tratamiento, principalmente se basa en los casos de uso, los separa con la idea de identificar mejor los aspectos que influirán en el modelo navegacional que se realiza en la fase de análisis y diseño.
  • 135. UWE: Fases. 6. El mantenimiento: Es el proceso de control, mejora y optimización del software ya desarrollado e instalado, que también incluye depuración de errores y defectos que puedan haberse filtrado de la fase de pruebas de control.
  • 137. UWE: Etapas.  Planificación: Se utilizaron métodos como el Abordaje a la comunidad, un Diagnostico Participativo, un inventario de los equipos, identificación del problema y detectar las necesidades de la institución y tener buena aceptación del proyecto, conjuntamente con la recolección de información para el desarrollo de la página.
  • 138. UWE: Etapas.  Diseño: La etapa de Diseño es el momento del proceso de desarrollo para la toma de decisiones acerca de cómo diseñar o rediseñar, en base al conocimiento obtenido en la etapa de planificación, así como a los problemas de usabilidad descubiertos en etapas de prototipado y evaluación.
  • 139. UWE: Etapas.  Usabilidad y Accesibilidad: En esta fase los usuarios tendrán fácil uso y acceso las veces que deseen,siempre y cuando haya un grado de eficacia y se cumplan con los objetivos y a una vez planteados.
  • 140. UWE: Beneficios.  La reducción de los costes de aprendizaje.  Disminución de los costes de asistencia y ayuda al usuario.  Disminución en la tasa de errores cometidos por el usuario.  Optimización de los costes de diseño, rediseño y mantenimiento.  Aumento de la satisfacción y comodidad del usuario.  Mejora la imagen y el prestigio de la institución.  Mejora la calidad de vida de los usuarios, ya que reduce su estrés, incrementa la satisfacción y la productividad de la institución y la comunidad en general.
  • 141. UWE: Beneficios.  UWE se acepta ampliamente por ser extensión de UML en el desarrollo de software, es flexible en la definición de un lenguaje de modelado específico de dominio Web: el llamado perfil UM , y tiene amplio apoyo de modelado visual por herramientas CASE UML existentes.  UWE utiliza "puro" notación UML y tipos de diagramas UML siempre que sea posible para el análisis y diseño de aplicaciones web, es decir, sin las extensiones de cualquier tipo.
  • 142. UWE: Etapas.  Prototipado: Una semejanza de cómo quedara cuando esté terminada a nivel de interfaz.  Implementación y lanzamiento: En la implementación de la página web es recomendable utilizar estándares (HTML, XHTML...) para asegurar la futura compatibilidad y escalabilidad del sitio.  En esta etapa se debe llevar un control de calidad de la implementación, supervisando que todo funcione y responda a cómo había sido planificado, ya que la usabilidad del sitio depende directamente de la funcionalidad. Si algo no funciona, sencillamente no se puede usar.  Una vez implementada la página web y aprobada su funcionalidad se procede al lanzamiento del sitio.
  • 143. UWE: Etapas.  Mantenimiento y seguimiento: Una vez puesta la página web a disposición de los usuarios hay que ir cambiando datos y mantener este sitio actualizado, ya que esta página no puede permanecer en el olvido.  Los problemas de uso no detectados durante el proceso de desarrollo pueden descubrirse a través de varios métodos, principalmente a través de los mensajes, opiniones de los usuarios, el comportamiento y uso del sitio.
  • 144. UWE  Estudio de la metodología.  4.5.1. Obtención de requerimientos de los sistemas de información Web.  4.5.2. Casos de uso de procesos y casos de uso navegacionales.  4.5.2. Diseño Conceptual.  4.5.3. Diseño Navegacional.  4.5.4. Diseño de la presentación (Interfaces abstractas.)  4.5.5. Diseño de la Infraestructura tecnológica del sistema de información Web.  4.5.6. Integración y prueba de servicios.
  • 145. UWE: Diseño conceptual. Para hacerse una redefinición o definición sobre el sistema que realimente se necesita, debe diseñarse un modelo conceptual incluyendo el modelo obtenido del sistema actual si lo hubiera, tomando en cuenta las propiedades de la nueva arquitectura de software. El diseño conceptual pretende definir claramente el problema que se debe solucionar y elaborar una solución para el mismo, en términos que todos los involucrados lo puedan comprender.
  • 146. UWE: Diseño conceptual. Este modelado proporciona una visión más amplia del problema. Trata de mantener esos requisitos en contexto y tomar decisiones racionales. Captura las tareas y la información esencial necesaria de las actividades del negocio, dando como resultado una visión de la solución enfocada en el proceso y centrada en el usuario. Especifica la ubicación, las capacidades y las expectativas de los usuarios. Es similar a un análisis de actividades, consiste en la solución de negocios para el usuario y se expresa con casos de uso.
  • 147. UWE: Diseño conceptual. Perfiles de usuario. Para indicar a los actores del sistema, se analizan las personas que utilizan el sistema actual o utilizarán el sistema propuesto; y sus roles o papeles que juegan en su interacción con el mismo. Se toman en cuenta los actores externos necesarios para las interrelaciones con los actores internos. El nombre del actor, reflejará el papel que tendrá para el sistema e identificarlos permite definir los límites del sistema y desarrollar un sistema dirigido al usuario que tome en cuenta todas las funcionalidades esperadas por los diferentes actores.
  • 148. UWE: Diseño conceptual. Escenarios de uso. Estos describen los requerimientos del sistema en el contexto del usuario, mostrando cómo se efectúan los procesos de negocios o cómo se deberían efectuar. Estos escenarios toman los datos recolectados y los aplica en un documento donde paso por paso se describe qué pasa primero, luego y después en la ejecución de una tarea específica.
  • 149. UWE: Diseño conceptual. Escenarios de uso. Métodos de construcción para los escenarios de uso:  Modelo de proceso de flujo de trabajo.  Modelo de secuencia de tareas.  Modelo de ambiente físico.
  • 150. UWE: Diseño conceptual. Métodos de construcción para los escenarios de uso:  Modelo de proceso de flujo de trabajo. Permite crear escenarios de uso, que muestran cómo los trabajos específicos son ruteados a través de una organización. Indica las condiciones necesarias para que el trabajo sea encaminado de un área a otra y lo necesario para que cada paso pueda efectuarse. Requiere definir pre y pos condiciones.
  • 151. UWE: Diseño conceptual. Métodos de construcción para los escenarios de uso:  Modelo de secuencia de tareas: Posee una serie de acciones o secuencias de tareas que un usuario efectúa para completar una actividad. Se usa con texto estructurado o no estructurado. El rol del usuario debe estar identificado en el escenario, de manera que cualquier persona pueda saber quien efectúa cada actividad.
  • 152. UWE: Diseño conceptual. Métodos de construcción para los escenarios de uso:  Modelo de ambiente físico: Cuando el lugar donde la aplicación se use afecte el diseño de la misma, se requiere este modelo; pues documenta cómo las actividades se relacionan con el ambiente físico de la empresa y permite determinar cómo los datos se mueven a determinadas localizaciones.
  • 153. UWE: Diseño conceptual.  Diagramas de casos de uso: Basándose en la secuencia de tareas de los escenarios de uso, se crean los casos de uso, de manera que se pueda tener una idea clara, de lo que se quiere funcionalmente del sistema y de la forma en la que se realizan los procesos. La conjugación de todos los casos de uso en un único diagrama, crea el diagrama de casos de uso el cual modela la vista de los casos de uso del sistema e involucra el modelado del contexto del sistema, subsistema, o clase.
  • 154. UWE: Diseño conceptual.  Modelado del contexto del sistema: Envuelve al sistema total dentro de un cuadro que dibuja los límites del modelo y los actores que interactúan con éste. Debe especificar los actores y el significado de sus roles.
  • 155. UWE: Diseño conceptual.  Modelado de requerimientos del sistema: Especifica qué hace el sistema desde el punto de vista externo. De esta forma el diagrama de casos de uso permite ver el sistema total como una caja negra, en el cual se pueden ver las reacciones del sistema a las cosas externas, pero no se puede ver cómo ess sistema trabaja en el interior.
  • 156. UWE: Diseño conceptual. Figura rica de un sistema centralizado.
  • 157. UWE: Diseño conceptual. Sistema migrado hacia Internet.
  • 158. UWE: Diseño conceptual. Abstracción de clases del sistema antiguo.
  • 159. UWE: Diseño conceptual. Abstracción de clases detallado del sistema antiguo.
  • 160. UWE: Diseño conceptual. Ejemplo de caso de uso. Nombre: Ingreso al sistema. Precondiciones: Debe existir el usuario en el sistema. Flujo principal: 1. El usuario inicia el sistema. 2. El sistema presenta formulario de ingreso. 3. El usuario ingresa credenciales. 4. El sistema verifica y valida información ingresada. 5. El sistema presenta opciones según parámetros. Flujo alterno: 4.1. El sistema detectó parámetros incorrectos. 4.2. El sistema muestra mensaje de error. Propósito: Ingresar al sistema con usuarios válidos.
  • 161. UWE: Diseño conceptual. Nombre: Ingreso de empleado nuevo. Precondiciones: El usuario debe haber ingresado al sistema y estar dentro. Flujo principal: 1. El sistema presenta formulario. 2. El usuario ingresa información. 3. El sistema verifica información ingresada. 4. El sistema retorna mensaje de verificación. 5. El usuario graba información. 6. El sistema sigue su flujo básico. Flujo alterno: 4.1. Se ingresó información incorrecta. 4.2. El sistema retorna mensaje de advertencia de error. 5.1. El sistema no pudo grabar. 5.2. El sistema retorna mensaje de error.
  • 162. UWE: Diseño conceptual. Diagrama de caso de uso: Inicio de sesión en el sistema.
  • 165. UWE: Diseño conceptual. Diagrama de secuencia para las altas, bajas y consultas a empleados.
  • 166. UWE: Diseño conceptual. Diagrama de colaboración para la administración de solicitudes de contratos.
  • 167. UWE: Diseño navegacional.Diagrama de espacio de navegación por departamento.
  • 170. UWE: Diseño navegacional. Este modelo se construye en dos fases. En una primera etapa se desarrolla un modelo de espacio de la navegación, construido como vista del modelo conceptual y que indica cuáles son las clases y modelos visitables. Es decir qué objetos pueden ser navegados. Se representa mediante un modelo de clases especiales llamadas clases navegacionales que son clases de UML estereotipadas para indicar su semántica. Luego la segunda etapa con el modelo de la estructura de la navegación, indica qué es visitable y cómo estos objetos son visitados. Es decir cómo son alcanzados en la navegación.
  • 171. UWE: Diseño navegacional. Los diseños navegacionales representan el camino que se debe tomar dentro de la web para realizar las funciones autorizadas a cada tipo de usuario. Objetivos:  Representar los nodos y los enlaces en la estructura del hipertexto.  Diseñar trayectorias de navegación.  Evitar la desorientación y conocer la carga de trabajo. Resultado:  Modelo de la estructura navegacional.  Diagramas de clase UML.  Elementos específicos del modelo.
  • 172. UWE: Diseño navegacional. • Elementos de navegación básicos: - Clase de navegación, especifica el nodo que es visitado por el usuario cuando navega por el sistema. - (a la clase de navegación se le nombra de igual forma que la clase de dominio que mapea o representa.) - Enlaces de navegación, especifican que los objetos de navegación son accedidos por objetos de navegación fuentes.
  • 173. UWE: Diseño navegacional. • Definir las clases navegacionales
  • 174. UWE: Diseño navegacional. Modelo de estructura navegacional (segundo paso.) • Mejorar el modelo de estructura navegacional incluyendo las estructuras de acceso
  • 175. UWE: Diseño navegacional. • Utilizados para la selección de destinos navegacionales desde un conjunto de elementos navegacionales.
  • 179. UWE: Un proyecto de ejemplo Ejemplo. • Hacer un sistema web en el cual puedan cargarse los distintos clubes de fútbol del país, con su información particular. • Cargar diferentes ciudades del país. • Asociar clubes con ciudades. • Obtener el informe de los campeonatos logrados por cada club. • Registro de usuario y login al sistema.
  • 180. Tareas a realizar 1. Definir actores. 2. Definir relaciones entre actores. 3. Definir casos de uso para cada actor. 4. Definir capa de contenido. 5. Definir capa de navegación. 6. Definir capa de presentación. UWE: Un proyecto de ejemplo
  • 181. 1. Actores • Se definen dos tipos de actores: • Usuario no registrado. • Usuario registrado. • El no registrado podrá leer información. • El registrado podrá hacer lo mismo que el no registrado, más cargar información al sistema. • Entregar una página con todos los actores del sistema y una breve descripción de los mismos en formato tabular. UWE: Un proyecto de ejemplo
  • 182. 1. Actores Actores Descripción Usuario no registrado El usuario no registrado representa al usuario que no posee login, que no… etc. Usuario registrado Este actor representa a los usuarios que no .. y tampoco .. Etc. etc. UWE: Un proyecto de ejemplo
  • 183. 2. Relaciones entre actores • El usuario registrado puede hacer todo lo que hace el no registrado, además de sus propias funcionalidades. • Debe haber un diagrama exclusivamente para denotar esto. • Este diagrama, por sí solo, ocuparía la segunda página. UWE: Un proyecto de ejemplo
  • 184. 3. Casos de uso por actor • Hacer un diagrama por actor. • En cada diagrama colocar el actor y todos los casos de uso asociados al mismo. • No hace falta repetir los casos de uso de un actor, si la generalización ya indica que un actor está heredando los mismos de otro actor. UWE: Un proyecto de ejemplo
  • 185. 3. Casos de uso por actor Diagrama de un actor en particular. Notar el diagrama comprende solo los casos de uso particulares a este actor. UWE: Un proyecto de ejemplo
  • 186. 3. Casos de Uso por actor UWE: Un proyecto de ejemplo Diagrama del actor registrado. Notar es un diagrama separado del anterior. Solo comprende sus casos de uso. No es necesario repetir los casos de uso que “recibe” por herencia. Estos se denotan en la segunda página del documento. Y en el diagrama “generalización de actores”.
  • 187. 3. Casos de uso por actor • Una vez definidos ésto, se continua agregando los esterotipos para casos de uso definidos por UWE (Navegación, Proceso, Personalización). • Estos se agregan en los diagramas de Casos de Uso. • No hace falta crear nuevos diagramas para esto. • Si no tienen los esterotipos o no saben como crearlos, denotar que estereotipos tiene cada CU mediante notas uml sobre los mismos. UWE: Un proyecto de ejemplo
  • 188. 3. Casos de uso por actor • Luego de esto los diagramas quedarían de la siguiente manera: UWE: Un proyecto de ejemplo
  • 189. 3. Casos de uso por actor UWE: Un proyecto de ejemplo
  • 190. 4. Capa de contenido • La capa de contenido puede considerarse el diagrama presentado por cada grupo de la Base de Datos. • Diagrama Entidad/Relación (Tablas, campos con tipos de datos, asociaciones entre tablas, etc.). • Diagrama físico (Generado automáticamente por su herramienta a partir del anterior, el cual ya incluye claves foráneas, tablas intermedias, etc.) UWE: Un proyecto de ejemplo
  • 191. 4. Capa de contenido Para este ejemplo usaremos como diagrama E/R (no olvidar el físico y script de la BD) UWE: Un proyecto de ejemplo
  • 192. 5. Capa de navegación • En Magic Draw, el perfil UWE, proporciona todos los esterotipos necesarios. • En este ejemplo, de los requerimientos y funcionalidades de casos de uso, se sabe que debe buscar clubes, cargar clubes nuevos, cargar ciudades, cargar campeonatos, etc. • Está basado en todas las funcionalidades para obtener la navegación. UWE: Un proyecto de ejemplo
  • 193. 5. Capa de navegación • Conceptualmente, se supone que el usuario se logueará primero. • Posteriormente podrá buscar un club, ver los campeonatos de un club, ver los equipos en cada ciudad. • Además, si es usuario registrado, podrá cargar un club nuevo, cargar un campeonato nuevo, o cargar una ciudad. • A ejemplos demostrativos se omitió el login y registro de nuevo usuario en los CU. UWE: Un proyecto de ejemplo
  • 194. 5. Capa de navegación • En algún momento debe poder navegarse hasta una página de un club. • O una página con los campeonatos de un club. • O una página con los clubes de una ciudad. • Basar en esto para saber las páginas (nodos) a los cuales se llegará y refinaremos hacia atrás. • Todos estos serán nodos navegacionales. • Son los casos de uso que definimos con el estereotipo <<navegacional>> UWE: Un proyecto de ejemplo
  • 195. 5. Capa de navegación • Además habrá nodos de proceso. • Los casos de uso definidos como <<proceso>> derivarán en algún momento en un nodo de proceso. • Es decir donde hay algún tipo de lógica de programación, terminará en algún tipo de modificación de datos. • En otras palabras, los casos de uso cargar club implica en algún momento poder navegar hasta una página donde se cargará un nuevo club. • Cargar ciudad, igual al punto anterior. Etcetera. • Notar que un caso de uso de <<proceso>> eventualmente implicará dos nodos. Uno de navegación (la página de carga), y el otro un nodo de proceso (la lógica de negocio donde se realiza el proceso de carga y los controles necesarios para esto). • Y debe haber una asociación de proceso entre estos. UWE: Un proyecto de ejemplo
  • 196. 5. Capa de navegación • Se parte de la capa de contenido (diagrama BD) UWE: Un proyecto de ejemplo
  • 197. 5. Capa de navegación • Cuales de las tablas son importantes para la navegación y se colocan en el diagrama de navegación, junto con sus asociaciones. • Los links de navegación son dirigidos. • Si se considera necesario un link de ida y vuelta entre dos nodos, se deben colocar dos links de asociación. UWE: Un proyecto de ejemplo
  • 198. 5.Capadenavegación UWE: Un proyecto de ejemplo
  • 199. 5. Capa de navegación • Ahora deben eliminarse las multiplicidades. • Donde desde un nodo haya más de un link de navegación de salida se utiliza un menú. • Si la multiplicidad del lado final del link de navegación es mayor a uno se utiliza: • Index • Guided tour • Querie UWE: Un proyecto de ejemplo
  • 200. 5. Capa de navegación UWE: Un proyecto de ejemplo
  • 201. 5. Capa de navegación • En la imagen anterior se reemplazan asociaciones con multiplicidad por nodos con primitivas de acceso. • En la imagen se ve color gris las clases con el estereotipo index. • Ahora debe agregar la dirección en las asociaciones. • En el ejemplo anterior desde un nodo de navegación Ciudad general, se pasa a un Indice de Ciudades, donde se elige una y se ven los clubes de dicha Ciudad. • Lo mismo de un nodo Clubes, va a un nodo Índice de campeonatos de Club, donde puede elegir uno en particular. • Normalmente se quiere buscar una ciudad primero, o un club, o grupos de los mismos. • Desde los resultados de la búsqueda, tener una o varias opciones de elección para ver la información de los mismo. • Ahí se usan queries. UWE: Un proyecto de ejemplo
  • 202. 5. Capa de navegación • Ahora en verde están las clases con estereotipo query. • Las clases verdes indican un nodo donde se realiza una búsqueda (query). • La misma puede tener desde cero a varios resultados. Por tanto se utiliza un menú (nodos con links de salida con multiplicidad mayor a uno). • Desde la lista de Ciudades, puede elegir cualquiera, para ver los clubes en dicha ciudad. • Desde la lista de clubes, puede elegir cualquiera para ver sus campeonatos. • Tanto la lista de clubes, como la lista de ClubCiudad tienen el mismo contenido (un grupo de clubes) • Por tanto en ClubCiudad puede también elegir cualquier Club y ver sus campeonatos, lo que crea un link de navegación hacia CampeonatosIndex. • CampeonatosIndex es un indice porque puede tener multiplicidad mayor a uno en el lado final o de salida (un club con varios campeonatos). UWE: Un proyecto de ejemplo
  • 203. 5. Capa de navegación • También debe verse información de usuarios, buscar usuarios, elegir un usuario de una lista, etc. • De esta manera se sigue refinando el diagrama de navegación. UWE: Un proyecto de ejemplo
  • 204. UWE: Un proyecto de ejemplo
  • 205. 5. Capa de navegación • Puede verse la información general de un club desde el índice de clubes. • Sin embargo ahora hay dos links de navegación de salida de un mismo nodo. UWE: Un proyecto de ejemplo
  • 207. 5. Capa de navegación • De nuevo, nodos con más de un link de navegación se deben transformar en menúes. UWE: Un proyecto de ejemplo
  • 209. 5. Capa de navegación • Se sigue refinando la navegación de esta manera. • Luego se agregan los nodos de proceso. • Estos salen de los casos de uso de proceso. • Los mismos implican situaciones donde haya lógica de negocio, transacciones con los datos subyacentes, etc. UWE: Un proyecto de ejemplo
  • 210. 5. Capa de navegación • De nuevo, refinar los nodos con más de un link de salida. • Y luego, definir un punto de entrada a la aplicación que será simbolizado como el home. • No dejar nodos sin conexión, ya que implicaría que no se puede navegar hasta ellos. UWE: Un proyecto de ejemplo
  • 212. 5. Capa de navegación • Debe refinarse el diagrama hasta cubrir todas las funcionalidades, items en los requerimientos, etc. • Evidentemente el diagrama puede crecer demasiado, entonces debe separarse en diferentes sub-diagramas. • Otra opción sería por navegación de cada actor. UWE: Un proyecto de ejemplo
  • 213. 6. Capa de presentación • Provee una visión abstracta de la interfaz del usuario. • Esta basada en el modelo de navegación. • No tener en cuenta temas como colores, letras, posicionamiento de los elementos dentro de la página, etc. • Las clases de presentación se basan los nodos del diagrama de navegación. • Es decir, tendremos una clase de presentación por cada menú, clase de navegación, primitivas de acceso (query, guided tour, index), y clases de proceso. • Para facilitar la ubicación de la clase de presentación de un nodo de navegación se recomienda utilizar los mismos nombres. • Ejemplo: El nodo de navegación “InformaciónClub” del diagrama de Navegación. A continuación, observe la clase de representación que corresponde a este nodo. UWE: Un proyecto de ejemplo
  • 214. 6. Capa de presentación • Clase de presentación del nodo de navegación del mismo nombre. UWE: Un proyecto de ejemplo
  • 215. 6. Capa de presentación • Ya existe una clase de presentación vacía. • Para llenarla, se inicia desde la Base de Datos. • ¿Qué atributos tiene, en la BD, la tabla que produce el nodo de navegación InformacionClub, y posteriormente la clase de presentación InformacionClub? UWE: Un proyecto de ejemplo
  • 216. 6. Capa de presentación • De nuevo el diagrama de la BD. UWE: Un proyecto de ejemplo
  • 217. 6. Capa de presentación • En el nodo de presentación se verá la información relacionada con un club. • De la tabla se tienen los atributos: • Id • Nombre • Apodo Principal • Apodo Secundario • Estadio • Año de fundación • Id de la ciudad a la que pertenece (esta es una clave foránea que viaja desde la tabla ciudad) UWE: Un proyecto de ejemplo
  • 218. 6. Capa de presentación • Cada atributo de la clase será representado con un elemento de UI. • Entonces la clase de presentación InformaciónClub se verá como en la siguiente página. Notar que un elemento, el nombre de la ciudad, viene de otra tabla (Ciudad), mediante un Join, con la información que se tiene con el id de Ciudad. • Se permiten dibujar los elementos dentro de la clase que lo contiene, facilitando la visualización y entendimiento de los mismos. UWE: Un proyecto de ejemplo
  • 219. 6. Capa de presentación UWE: Un proyecto de ejemplo
  • 220. 6. Capa de presentación • Cuando un club, muestre en su presentación, el nombre de la ciudad a la que pertenece, sería conveniente que del nombre de la ciudad pueda llegarse a la lista de clubes de dicha ciudad. • Debería modificarse el diagrama navegacional permitiendo un link de salida desde InformacionClub hacia ClubesCiudad. • Hecho esto, “ciudad” en nuestra clase de presentación ya no sería solo texto, sino un enlace (link.) UWE: Un proyecto de ejemplo
  • 221. 6. Capa de presentación UWE: Un proyecto de ejemplo
  • 222. 6. Capa de presentación • De esta manera, se van tomando los diferentes nodos de navegación, y se construye su correspondiente clase de presentación. • Usualmente, en una misma página se presentará información de varios nodos de navegación. • Para esto use el estereotipo page. • Una página puede contener varias clases de presentación, así como grupos de presentación. • Los grupos de presentación son contenedores que pueden tener grupos de presentación y clases de presentación. • A continuación un ejemplo de la página de ClubesMenu. UWE: Un proyecto de ejemplo
  • 223. 6. Capa de presentación UWE: Un proyecto de ejemplo
  • 224. 6. Capa de presentación • En esta página se desea ver: • El menú principal • El menú de clubes • Información relacionada al club (información propia, campeonatos, etc). • Por lo tanto, se agregan las clases de presentación de dichos elementos a la clase (tarea para el estudiante.) UWE: Un proyecto de ejemplo
  • 226. 6. Capa de presentación • Simplemente se completan las páginas con las clases que la componen. Recuerde que los atributos salen de la BD. • Además, la navegación se hace según los links de navegación entre los nodos en el diagrama de navegación. • Quizá necesite modificar la navegación y tener un link a crear un nuevo club. • Por tanto necesita añadir esto también a los casos de uso, etc. • Así de informacionClub puede llegar a informacionClub y también a campeonatosIndex (diagrama de navegacion). Por lo tanto: UWE: Un proyecto de ejemplo
  • 228. 6. Capa de presentación • Como se ve, normalmente, los query se ven en una clase con un formulario dentro. • Un atributo que lleva a otro nodo, un anchor o ancla (link). • Debe realizar las clases de presentación individuales. • Y posteriormente, agrupar las necesarias para ir presentando las páginas. UWE: Un proyecto de ejemplo
  • 230. UWA: Ubiquituos Web Applications. 2001  El proyecto UWA ha nacido de la colaboración de varios grupos.  Su fase de tratamiento de requisitos se basa en los roles de usuario y en ir refinando los requisitos en un proceso iterativo mediante el que se clasifican los objetivos según su carácter.
  • 231. NDT: Navigational Development Tecniques. 2004  Es un proceso metodológico para especificar, analizar y diseñar sistemas web.  En el tratamiento de requisitos separa la captura, la definición y la validación de requisitos, proponiendo técnicas específicas para cada uno de ellos.  Ofrece además una herramienta, NDT-Tool, que sirve como soporte en la aplicación de sus técnicas.
  • 232. DDDP: Design-driven Requirements Elicitation. 2004  Esta propuesta para el tratamiento de requisitos es parte del proceso design-Driven propuestos por Lowe y Ekluind.  Consiste en realizar la captura, la definición y la validación de requisitos durante el proceso de diseño.  El proceso que ofrecen fue definido según un exhaustivo análisis de best practices en el desarrollo de aplicaciones comerciales para la web.
  • 233. Técnicas comúnmente utilizadas en las metodologías
  • 235. Introducción. La programación extrema o Extreme Programming, es una disciplina de desarrollo de software basada en los métodos ágiles, que evidencia principios tales como el desarrollo incremental, la participación activa del cliente, el interés en las personas y no en los procesos como elemento principal, y aceptar el cambio y la simplicidad. El trabajo fundamental se publicó por Kent Beck en 1999, y tomó el nombre de Programación Extrema por las prácticas reconocidas en el desarrollo de software y por la participación del cliente en niveles extremos. PE: Programación Extrema.
  • 236. Principios. Éste método, al igual que RUP y MSF, también tiene principios los cuales son buenas prácticas a tener presente en el desarrollo del software. Los principios XP comprenden diez buenas prácticas que involucran al equipo de trabajo, los procesos y el cliente; los cuales son: PE: Programación Extrema.
  • 237. Principios. 1. Planificación incremental. 2. Entregas pequeñas. 3. Diseño sencillo. 4. Desarrollo previamente aprobado. 5. Limpieza del código o refactorización. 6. Programación en parejas. 7. Propiedad colectiva. 8. Integración continua. 9. Ritmo sostenible. 10.Cliente presente. PE: Programación Extrema. Se toman los requerimientos en Historias de Usuario, las cuales son negociadas progresivamente con el cliente.
  • 238. Principios. 1. Planificación incremental. 2. Entregas pequeñas. 3. Diseño sencillo. 4. Desarrollo previamente aprobado. 5. Limpieza del código o refactorización. 6. Programación en parejas. 7. Propiedad colectiva. 8. Integración continua. 9. Ritmo sostenible. 10.Cliente presente. PE: Programación Extrema. Se desarrolla primero la más mínima parte útil que le proporcione funcionalidad al sistema, y poco a poco se efectúan incrementos que añaden funcionalidad a la primera entrega, cada ciclo termina con una entrega del sistema.
  • 239. Principios. PE: Programación Extrema. El ciclo de entrega de XP.
  • 240. Principios. XP describe un conjunto de prácticas para un desarrollo óptimo, ya que define con exactitud los requerimientos del usuario. Esta metodología difiere de las demás por que se basa en la adaptabilidad y la previsión, pues propone que, cambiar los requerimientos del sistema durante el desarrollo constituye un mejor acercamiento con el usuario; surge como una solución a los problemas derivados del cambio constante en los requerimientos de un sistema. Metodología XP.
  • 242. Roles XP. Metodología XP.  Pieza básica en desarrollos XP.  Más responsabilidad que en otros modos de desarrollo.  Responsable sobre la generación del código fuente.  Responsable sobre el diseño y maquetado de la aplicación.  Responsable de administrar la bases de datos.  Responsable sobre la integridad del sistema (pruebas.)  Acepta críticas (código colectivo.)
  • 243. Roles XP. Metodología XP.  Pieza básica en desarrollos XP.  Define especificaciones.  Influye sin controlar.  Confía en el grupo de desarrollo.  Define pruebas funcionales.
  • 244. Roles XP. Metodología XP.  Apoya al cliente en la preparación o realización de las pruebas funcionales.  Ejecuta las pruebas funcionales y publica los resultados.
  • 245. Roles XP. Metodología XP.  Recoge, analiza y publica información sobre la marcha del proyecto sin afectar demasiado el proceso.  Supervisa cumplimiento de estimaciones en cada iteración.  Informa sobre la marcha de la iteración en curso.  Controla la marcha de las pruebas funcionales, de los errores reportados, las responsabilidades aceptadas y la prueba añadida por los errores.
  • 246. Roles XP. Metodología XP.  Recoge, analiza y publica información sobre la marcha del proyecto sin afectar demasiado el proceso.  Supervisa cumplimiento de estimaciones en cada iteración.  Informa sobre la marcha de la iteración en curso.  Controla la marcha de las pruebas funcionales, de los errores reportados, las responsabilidades aceptadas y la prueba añadida por los errores.
  • 247. Roles XP. Metodología XP.  Experto en Metodología XP.  Responsable del proceso en su conjunto.  Identifica las desviaciones y reclama atención sobre las mismas.  Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza.)  Interviene directamente si es necesario.  Captura rápidamente el problema.
  • 248. Valores X.P. Un proyecto de software posee valores esenciales, descritos a continuación: Comunicación. Simplicidad. Retroalimentación (Feedback). Coraje. Respeto. Metodología XP.
  • 249. Comunicación. Todos son parte del equipo y la comunicación es esencial, desde los requerimientos hasta la programación. En los métodos tradicionales de desarrollo, la comunicación de los requerimientos a los desarrolladores se realiza a través de la documentación. En XP la comunicación se da por transferencia de conocimientos en reuniones frecuentes cara a cara entre usuarios y desarrolladores, lo que le da a ambos una visión compartida del sistema. Metodología XP: Valores X.P.
  • 250. Simplicidad. Todos son parte del equipo y la comunicación es esencial, desde los requerimientos hasta la programación. En los métodos tradicionales de desarrollo, la comunicación de los requerimientos a los desarrolladores se realiza a través de la documentación. En XP la comunicación se da por transferencia de conocimientos en reuniones frecuentes cara a cara entre usuarios y desarrolladores, lo que le da a ambos una visión compartida del sistema. Metodología XP: Valores X.P.
  • 251. Simplicidad. El objetivo es hacer pasos simples y pequeños, mitigando las fallas a medida que ocurran. Crear algo de lo cual pueda sentirse orgulloso y que pueda mantenerse en el largo plazo a costos razonables. Un diseño y programación simple mejora la calidad de las comunicaciones, pues es más fácil implementar y entender por todos en el equipo. Metodología XP: Valores X.P.
  • 252. Retroalimentación (Feedback). Compromisos con el usuario establecidos en todas las iteraciones, entregando software en funcionamiento en cada una. Mostrar al usuario el software frecuente y de forma temprana, escuchando cuidadosamente sus observaciones y realizando los cambios necesarios. Adaptar los procesos al proyecto y no al contrario. Metodología XP: Valores X.P.
  • 253. Retroalimentación (Feedback).  Retroalimentar el sistema: Por medio de la ejecución de pruebas unitarias y de integración, los programadores reciben retroalimentación directa del estado del sistema.  Retroalimentación del cliente (usuario): Las pruebas de aceptación, son diseñadas conjuntamente por el cliente y los analistas de pruebas, obteniendo en conjunto retroalimentación del estado actual del sistema. Esta revisión puede hacerse cada 1 o 2 semanas, permitiendo así que el cliente sea quien guíe el desarrollo del software. Metodología XP: Valores X.P.
  • 254. Retroalimentación del equipo: Cuando el cliente trae nuevos requerimientos, el equipo puede directamente proporcionar la estimación del tiempo que tomará implementarlos. Coraje: Es un valor muy importante dentro de la P.E. Un miembro de un equipo de desarrollo extremo debe tener el coraje de exponer sus dudas, miedos, experiencias sin "embellecerlas." Es muy importante ya que el equipo se basa en la confianza para con sus miembros. Faltar a esta confianza es una falta muy grave. Metodología XP: Valores X.P.