miércoles, 16 de octubre de 2013

Biblioteca virtual

Nombre de la Biblioteca: Carlos Manuel Piar

Ubicación: Prolongación paseo Orinoco edificio casalta Piso 1 oficina 3 (Ciudad Bolívar - Estado Bolívar) 

Fecha de inauguracion: 31 de julio del año 2012

Horarios: (08:00am a 12:00pm) (01:00pm a 04:30pm)

Promedio de usuarios que atienden: 50 personas o mas.





Actividades que realiza:

  • Talleres
  • Cursos
  • Practicas relacionadas con la Telemática enfocada hacia la educación.














Objetivos de la Biblioteca:

  • Promover el uso de la informática y telemática como instrumento de inclusión social de los sectores populares y educativos en el desarrollo tecnológico del país.
  •  Diseñar políticas, programas y proyectos que provean a la fundación de todos los recursos necesarios para su desarrollo sostenido y continuo; haciendo particular énfasis en las áreas de investigación, conservación, promoción, difusión, educación y fomento.

  • Promover una red de bibliotecas virtuales en el Estado Bolívar, a los fines de atender a la población de los niveles de educación inicial, básica y educación especial con los cuales realizaran actividades de teorías educativas fundamentadas en las experiencias cotidianas.

Promover todas aquellas iniciativas que dentro de lo establecido como misión de la fundación contribuyan al enriquecimiento y exaltación de los valores educativos.           

Que provee la Biblioteca:


  • Herramientas Tecnológicas


Misión

La misión de la Biblioteca Virtual Manuel Carlos Piar es promover el uso de la informática y telemática como instrumento de inclusión social de los sectores populares y educativos en el desarrollo tecnológico del país.  

        

Visión

Consolidación del desarrollo tecnológico regional mediante el uso de la computadora e interne como herramienta fundamental en el proceso enseñanza-aprendizaje y como instrumento de inclusión social.





Inventario de la Biblioteca

                                                      

1.- Equipo De Computación:

  • Marca: Siragon
  • Modelo: Siragon


2.- Procesador:

  • Marca: Celeron
  • Velocidad De Trabajo: 2.4 Ghz.


3.- Memoria RAM:

  • Marca: Kingston
  • Almacenamiento De Trabajo: 512 Mb


4.-Tarjeta Madre:

  • Marca: AS Rock
  • Modelo: 945-GC.


5.- Disco Duro:

  • Capacidad De Almacenamiento: 80 Gb
  • Velocidad De Trabajo: 7200 RPM.


6.- Unidades:

  • Disqueteras, Lectora O Quemador:


7.- Teclado:

  • Marca: Microsoft
  • Estándar:      Otro


8.- Ratón:

  • Marca: Vit
  • Mecánico:             Óptico.


9.- Monitor:

  • Marca: Vit
  • Tipo: LCD: o CRT:


10: Sistema Operativo: Canaima (GNU/Linux).






miércoles, 9 de octubre de 2013

Metodologia xp



la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Simplicidad

La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente.

Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece.

También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no decrementan la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente.

Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.

Comunicacion


La comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método.

Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas.

Retroalimentacion


Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante.

Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.

Coraje o Valentia

Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir demasiado tiempo y trabajo para implementar el resto del proyecto. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Otro ejemplo de valentía es saber cuando desechar un código: valentía para quitar código fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirtió en crear ese código. Además, valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, sólo si es persistente.

Respeto

El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.


Características fundamentales



Las características fundamentales del método son:

  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas: frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
  • Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. La mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores: antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código: es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.







Metodologia AUP



La UP es un software producto ingeniería marco de proceso que puede abordarse mediante tres perspectivas, incluyendo colaboraciones, contexto y las interacciones que se centran en un ciclo de vida de compuesto por fases, disciplinas y iteraciones.

En la siguiente figura se muestra una vista conceptual de los elementos esenciales que constituyen la UP y AUP.

                     clip_image002



Una colaboración implica una interacción dentro de un contexto. En la UP, una colaboración captura quién hace qué actividades (cómo) sobre lo que funcionan los productos. Por lo tanto, establece los elementos de un proyecto. Colaboraciones implican a trabajadores (funciones), actividades y productos (artefactos) de trabajo. En el AUP, colaboraciones se centrarán en colaboradores (colaboradores y confirmantes), metas y objetivos y resultados. Un contexto se hace hincapié en el aspecto estructural o estático de una colaboración, los elementos que colaboran y su conglomerado o las relaciones espaciales.

 En la UP, un contexto captura cuando y donde estas actividades deben ser hechas, trabajo, productos (artefactos) producidos y consumidos. Por lo tanto, establece el marco para un proyecto. Contextos implican ciclos de desarrollo y fases, iteraciones y disciplinas. Las fases de la UP incluyen principio, diseño, construcción y transición. Disciplinas de la UP incluyen Business Modeling, requisitos, análisis y diseño, prueba, implementación, configuración y administración de cambios, gestión de proyectos y medio ambiente. En el AUP, contextos centrarán en objetivos.

Una interacción enfatiza el aspecto de comportamiento o dinámica de una colaboración, los elementos que colaboran y en su cooperación o la comunicación temporal. En la UP, una interacción captura cuándo y por qué esas actividades se debe hacer y los productos de trabajo (artefactos) producidos y consumidos. Así, establece la ejecución de un proyecto. Interacciones implican requisitos o casos de uso, un sistema y su arquitectura, iteraciones, y el riesgo. En el AUP, las interacciones se centran en los objetivos.

El AUP define metas y objetivos donde las colaboraciones se utilizan para lograr resultados. Una colaboración puede ser el trabajo realizado por una persona que puede interactuar con otros usuarios. Una colaboración puede ser un taller en el que participaron varios individuos que interactúan entre sí y pueden interactuar con otros fuera del taller. Objetivos son similares a UP fases en las que se utilizan como puertas que implican las partes interesadas y los usuarios. Objetivos son similares a UP iteraciones en caja el tiempo que implican a los usuarios y dar como resultado un producto de la versión.

El objetivo de iniciar (Concepción) es establecer el producto visión, plan de proyecto, negocios y justificación tecnológica e identificar los riesgos y las oportunidades. Puede haber uno o más objetivos que deben lograrse en alcanzar este objetivo.

El objetivo de ejecutar (innovación) es evolucionar el visión de producto, plan de proyecto y justificación de negocio y tecnología; identificar y hacer frente a riesgos; identificar y aprovechar oportunidades mientras diseñar, desarrollar (aplicación y pruebas) y desplegar (integración, construcción y libertad) el producto. Normalmente hay muchos objetivos y metas, cada una resultante de la implementación del producto.

El objetivo de cerrar (dejar) es retirar el producto y cerrar el proyecto (talleres de cierre). Puede haber uno o mas objetivos que debe lograrse en alcanzar este objetivo.

La visión provee dirección y un enfoque general, esta guía provee dirección específica a través de las metas y las misiones a través de los objetivos, y las colaboraciones establecen intuición, confianza, unidad, y cohesión.

Justificación del Uso del Proceso Unificado Ágil como Modelo de Desarrollo

Un modelo de ciclo de vida de software es una vista de las actividades que se llevan a cabo durante el desarrollo de éste, e intenta determinar el orden de las etapas involucradas y proporcionar unos criterios para avanzar de unas a otras. Por tanto, definir un ciclo de vida permite llevar un mayor control sobre las tareas, evitando que estas se vayan eligiendo y realizando de manera desordenada, según parezca que van surgiendo necesidades, que podrían ser puntuales y fácilmente evitables.

Interactivo e incremental:

El Proceso Unificado es un marco de desarrollo compuesto de cuatro fases:

  • Inicio
  •  Elaboración
  •  Construcción
  • Transición
Cada una de ellas es, a su vez, dividida en una serie de iteraciones que ofrecen como resultado un incremento del producto desarrollado, que añade o mejora las funcionalidades del sistema en desarrollo. Es decir, un “incremento” no implica necesariamente una ampliación de dicho sistema.

Durante cada una de estas iteraciones se realizarán a su vez las actividades definidas en el ciclo de vida clásico: requisitos, análisis, diseño, implementación, prueba e implantación. Aunque todas las iteraciones suelen incluir trabajo en casi todas estas actividades, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Por ejemplo, en la fase de inicio se centrarán más en la definición de requisitos y en el análisis, y durante la de construcción quedarán relegadas en favor de la implementación y las pruebas.

Si una iteración cumple sus metas, publicando una nueva versión del producto que implemente ciertos casos de uso, el desarrollo continúa con la siguiente. Cuando no las cumple, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.











Metodologia Rup

El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP)
es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

Principios de desarrollo



El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso

El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización, el tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área sub formal para hacer un proceso de satisfacción del software.

Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente.

Demostrar valor interactivamente.

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados.
Colaboración entre equipos.

Colaboración entre equipos.

El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción.

elevar el nivel de abstraccion

Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la calidad.

Enfoque en la calidad

El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Ciclo de vida



El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de unabaseline (Línea Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

Principales características 


  • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
  • Pretende implementar las mejores prácticas en Ingeniería de Software
  • Desarrollo iterativo
  • Administración de requisitos
  • Uso de arquitectura basada en componentes
  • Control de cambios
  • Modelado visual del software
  • Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

Fases


  • Establece oportunidad y alcance
  • Identifica las entidades externas o actores con las que se trata
  • Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

'Proceso': Las etapas de esta sección son:

  • Modelado de negocio
  • Requisitos
  • Análisis y Diseño
  • Implementación
  • Pruebas
  • Despliegue


Soporte: En esta parte nos encontramos con las siguientes etapas:

  • Gestión del cambio y configuraciones.
  • Gestión del proyecto.
  • Entorno.


La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:
  • Inicio (también llamado Incepción o Concepción).
  • Elaboración.
  • Desarrollo (también llamado Implementación, Construcción).
  • Cierre (también llamado Transición).

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.


Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.


Fase de Transición: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

Artefactos


RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:


Inicio:

  • Documento Visión.
  • Diagramas de caso de uso.
  • Especificación de Requisitos.
  • Diagrama de Requisitos.

Elaboración:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica
  • Diagrama de clases
  • Modelo E-R (Si el sistema así lo requiere)

Vista de implementacion 

  • Diagrama de Secuencia.
  • Diagrama de estados.
  • Diagrama de Colaboración.
Vista conceptual
  • Modelo de dominio
Vista fisica

  • Mapa de comportamiento a nivel de hardware.
  • Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos.
  • Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construccion
  • Especificación de requisitos faltantes.
  • Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación iterativa.
  • Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el caso.
Transición:
  • Pruebas finales de aceptación.
  • Puesta en producción.
  • Estabilización.

Metodologia uwe



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.

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.

Principales aspectos

Los principales aspectos en los que se fundamenta uwe son los siguientes:

  • Uso de denotacion estándar:  para todos los modelos UML (lenguaje de modelo unificado).
  • Definicion de metodos: definicion de los pasos para la construccion de los diferentes modelos.
  • Especificacion de restricciones: se recomienda el uso de restricciones escritas (OCL: lenguaje de restricciones de objetos). para aumentar la exactitud de los modelos.

Fases de desarrollo web.



La aplicacion uwe hace un uso exclusivo de estandares reconocidos como UML y el lenguaje de especificacion de restricciones asociado OCL. para simplifiar la captura de las necesidades de aplicacionnes web, uwe propone una extension que se utiliza a lo largo del proceso de autorias. este proceso de autorias esta dividido en cuatro fases o actividades.

  • Analisis de requisitos:  Fija los requisitos funcionales de la apliacion web para reflejarlos en un modelo de caso de uso.

  • Diseño conceptual: Materializado en un modelo de dominio, considerando los requisitos reflejados en los casos de uso.

  • Diseño navegacional: lo podemos subdividir en:

  • Modelo espacio navegacional.
  • Modelo de la estructura de navegacion: muestra la forma de navegar ante el espacio de navegacion.

  • Diseño de presentacion: Representa las vistas del interfaz del usuario mediante modelos estandares de interaccion UML.