Pregunta 2

PARTE I.- PERFIL1.1. Introduccin:Hoy en da los sistemas computacionales actuales nos ha llevado a buscar la reutilizacin del software existente. El desarrollo de software basado en componentes permite reutilizar piezas de cdigo pre elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reduccin del ciclo de desarrollo y el mayor retorno sobre la inversin. Los continuos avances en la Informtica y las Telecomunicaciones estn haciendo cambiar la forma en la que se desarrollan actualmente las aplicaciones software. En particular, el incesante aumento de la potencia de los ordenadores personales, el abaratamiento de los costes del hardware y las comunicaciones, y la aparicin de redes de datos de cobertura global han disparado el uso de los sistemas abiertos y distribuidos. Esto ha provocado, entre otras cosas, que los modelos de programacin existentes se vean desbordados, siendo incapaces de manejar de forma natural la complejidad de los requisitos que se les exigen para ese tipo de sistemas. Comienzan a aparecer por tanto nuevos paradigmas de programacin, como pueden ser la coordinacin, la programacin orientada a componentes, o la movilidad, que persiguen una mejora en los procesos de construccin de aplicaciones software. En ellos se trabaja tanto en extensiones de los modelos existentes como en nuevos modelos, en la estandarizacin de sus interfaces y servicios, y la pertinaz bsqueda del cada vez ms necesario mercado global de componentes software. Estos son parte de los nuevos retos con los que se enfrenta actualmente la ingeniera del software.

1.2. Objetivo:1.2.1. Objetivo general:Desarrollar una herramienta para diseo de Formulario con ambiente Web

1.2.2. Objetivos especficos:a) Identificar las funciones que el software debe cumplir.

b) Obtener informacin sobre cmo desarrollar un sistema basado en Componentes.

c) Realizar el anlisis del los requisitos ya identificado.d) Realizar el diseo en baso a los anlisis ya realizados para el desarrollo del sistema.

e) Implementar el software de acuerdo al diseo realizado, con la herramienta de programacin java.

f) Realizar las pruebas para identificar las posibles fallas que pudiera presentar el software.

1.3. Antecedentes:Existen en el mercado y en Internet una gran variedad de componentes y herramientas desarrolladas en distintos que son utilizadas por millones de programadores alrededor del mundo en proyectos de software de mltiple envergadura.Algunas de ellas son de libre distribucin y otras son comerciales regidas por su copyright. A continuacin se cita algunas de ellas: JfreeChart, y el iReport es un constructor/diseador de informes visual.

1.4. Descripcin del problema:Hoy en da muchas empresas y desarrolladores han optado por desarrollar Componente para que estas puedan ser usadas en infinidad de proyectos para no as retrasar el trabajo, y estas puedan ser reutilizadas por cualquier persona.1.5. Alcance1.5.1. Requerimientos funcionales: Gestionar el diseo de Formularios (nuevo, abrir, guardar, web, etc.).

1.5.2. Plataforma de desarrollo: El sistema se desarrollar bajo la plataforma JAVA.

La informacin persistente de esta aplicacin ser guardada en archivos.

El software desarrollado esta basado en el Proceso Unificado de Desarrollo de Software.

Para visualizar, especificar, construir y documentar utilizamos el Lenguaje Unificado de Modelado (UML).1.6. Modelo de Negocio:

1.6.1. Diagrama de Actividad: Adicionar Componente

PARTE II.- FUNDAMENTO TERICO:2.1. Herramientas KEY:2.1.1.-Historia

En la dcada de los setenta el proyecto ISDOS desarroll un lenguaje llamado "Problem Statement Language" (PSL) para la descripcin de los problemas de usuarios y las necesidades de solucin de un sistema de informacin en un diccionario computarizado. PSA era un producto asociado que analizaba la relacin de problemas y necesidades. Pero la primera herramienta KEY como hoy la conocemos fue "Excelerator" en 1984, era para PC. Actualmente la oferta de herramientas KEY es muy amplia y tenemos por ejemplo el EASYKEY o WINPROJECT.

2.1.2.-Definicin:

Las herramientas KEY son un conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de vida del desarrollo de los sistemas de informacin, completamente o en alguna de sus fases.

Las herramientas KEY ayudan a los gestores y practicantes de la Ingeniera de Software en todas las actividades asociadas a los procesos de software. Automatizan las actividades de gestin de proyectos, gestionan todos los productos de los trabajos elaborados a travs del proceso, y ayudan a los ingenieros en el trabajo de anlisis, diseo y codificacin. Las herramientas KEY se pueden integrar dentro de un entorno sofisticado.

El empleo de herramientas KEY permiten integrar el proceso de ciclo de vida:

Anlisis de datos y procesos integrados mediante un repositorio.

Generacin de interfaces entre el anlisis y el diseo.

Generacin de cdigo a partir del diseo.

Control de mantenimiento.

2.1.3.-Un taller de ingeniera de softwareLos ingenieros de software reconocen que necesitan herramientas ms variadas (las herramientas manuales por s mismas, no satisfacen los requisitos de los sistemas basados en componentes modernos) tambin ellos necesitan un taller organizado y eficiente en el cual situar sus herramientas:

El taller de la Ingeniera del Software se denomina un entorno de proyectos integrados, y el conjunto de herramientas que llena ese taller se denomina ingeniera del software asistida por computadora (KEY).

Las herramientas KEY son un complemento de la caja de herramientas del ingeniero de software. KEY proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visin general de la ingeniera.

2.1.4.- Bloques de construccin de KEY:La arquitectura de entorno, compuesta por la plataforma de hardware y el soporte del sistema operativo constituye la base del KEY. Pero el entorno KEY, en s mismo, necesita otros componentes. Un conjunto de servicios de portabilidad constituyen un puente entre las herramientas KEY y su marco de integracin y la arquitectura de entorno. El marco de integracin es un conjunto de programas especializados que permiten a cada herramienta KEY comunicarse con las dems, para crear una base de datos de proyectos y mostrar una apariencia homognea al usuario final (el ingeniero de software). Los servicios de portabilidad permiten que las herramientas KEY y su marco de integracin pueden migrar a travs de diferentes plataformas hardware y sistemas operativos sin grandes esfuerzos de adaptacin. Los bloques se muestran en la ste. Figura.

Fig. # Pirmide de Construccin KEY

Herramientas keys Marco de IntegracinServicios de Portabilidad Sistema operativo

Plataforma Hardware(HW)Arquitectura de entornoLos bloques de construccin representados en la anterior figura representan el fundamento completo para la integracin de herramientas KEY. Sin embargo la mayor parte de las herramientas KEY que se utilizan en la actualidad no han sido construidas empleando todos los bloques de construccin anteriormente descritos. Es decir una herramienta no se comunica directamente con otras, no est unida a una base de datos del proyecto, y no forma parte de un entorno integrado.

Las herramientas KEY de solucin puntual proporcionan un beneficio sustancial, pero un equipo de software necesita herramientas que se comuniquen entre s. Las herramientas integradas ayudan a que el equipo desarrolle, organice y controle los productos del trabajo.

2.2. Desarrollo Basado en Componentes :Uno de los enfoques en los que actualmente se trabaja constituye lo que se conoce como Desarrollo de Software Basado en Componentes (DSBC), que trata de sentar las bases para el diseo y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables. Dicha disciplina cuenta actualmente con un creciente inters, tanto desde el punto de vista acadmico como desde el industrial, en donde la demanda de estos temas es cada da mayor.

Las siguientes secciones pretenden servir como una breve introduccin a algunos de los conceptos y mtodos fundamentales sobre los que se apoya el DSBC. En particular, se hablar de las arquitecturas software y los marcos de trabajo, la programacin orientada a componentes, y en las plataformas de componentes distribuidas.

2.2.1.- Conceptos Bsicos:Un sistema es abierto si es concurrente, reactivo, independientemente extensible, y permite a componentes heterogneos ingresar o abandonar el sistema de forma dinmica. Estas condiciones implican que los sistemas abiertos son inherentemente evolutivos, y que la vida de sus componentes es ms corta que la del propio sistema. No se desea incluir en la definicin de sistema abierto la propiedad de ser distribuido, puesto que se considera que ambas caractersticas son independientes entre s. Sin embargo, los sistemas objeto del presente estudio comprenden ambas propiedades, siendo tanto abiertos como distribuidos.

Como consecuencia de dichas caractersticas, el desarrollo de aplicaciones para este tipo de sistemas se ve afectado por una serie de problemas especficos, como son la gestin de la evolucin del propio sistema y de sus componentes, la falta de una visin global del sistema, la dificultad para garantizar la seguridad y confidencialidad de los mensajes, la heterogeneidad de los componentes, o su dispersin, lo que puede implicar retrasos y errores en las comunicaciones.

El tratamiento de estas situaciones es lo que ha hecho ver la necesidad de nuevos modelos, pues la programacin tradicional se ha visto incapaz de tratarlos de una forma natural. As, la Programacin Orientada a Objetos (POO) ha sido el sustento de la ingeniera del software para los sistemas cerrados. Sin embargo, se ha mostrado insuficiente al tratar de aplicar sus tcnicas para el desarrollo de aplicaciones en entornos abiertos. En particular, se ha observado que no permite expresar claramente la distincin entre los aspectos computacionales y meramente composicionales de la aplicacin, y que hace prevalecer la visin de objeto sobre la de componente, estos ltimos como unidades de composicin independientes de las aplicaciones. Asimismo, tampoco tiene en cuenta los factores de mercadotecnia necesarios en un mundo real, como la distribucin, adquisicin e incorporacin de componentes a los sistemas.

A partir de estas ideas nace la programacin orientada a componentes (POC) como una extensin natural de la orientacin a objetos para los entornos abiertos. Este paradigma propugna el desarrollo y utilizacin de componentes reutilizables dentro de lo que sera un mercado global de software.

Sin embargo, disponer de componentes no es suficiente tampoco, a menos que seamos capaces de reutilizarlos. Y reutilizar un componente no significa usarlo ms de una vez, sino que implica la capacidad del componente de ser utilizado en contextos distintos a aquellos para los que fue diseado. En este sentido, uno de los sueos que siempre ha tenido la ingeniera del software es el de contar con un mercado global de componentes, al igual que o curre con otras ingenieras, o incluso con el hardware. De hecho, la analoga con los circuitos integrados (IC) lleg a poner de moda los trminos software IC, software bus y software backplane, aunque nunca se haya podido llegar ms all de la definicin de estos conceptos.

Para hablar de la existencia de un mercado de componentes software es necesario que los componentes estn empaquetados de forma que permitan su distribucin y composicin con otros componentes, especialmente con aquellos desarrollados por terceras partes. Esto nos lleva a la definicin de componente:

Un componente es una unidad de composicin de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio

Las interfaces de un componente determinan tanto las operaciones que el componente implementa como las que precisa utilizar de otros componentes durante su ejecucin. Y los requisitos determinan las necesidades del componente en cuanto a recursos, como por ejemplo las plataformas de ejecucin que necesita para funcionar. Obsrvese que los conceptos de objeto y componente son ortogonales, y que ninguno de los dos depende del otro.

Finalmente, a partir de los componentes reutilizables dentro de un mercado global de software nace el concepto fundamental en estos entornos, el de componente COTS (commercial off-the-shelf). Este concepto va a cambiar la idea tradicional del desarrollo de software en donde todo es propietario o la reutilizacin se reduce a un mbito local (el de la empresa que desarrolla el software), hacia nuevas metodologas de desarrollo de software en donde es posible contar con elementos externos. Esto se va a traducir, como veremos en la ltima seccin, no slo en nuevas formas de desarrollo e implementacin de aplicaciones, sino tambin en alteraciones durante las fases de especificacin y diseo para tener en cuenta este tipo de elementos. Aparecen tambin nuevos problemas, como el de la bsqueda y reconocimiento de los componentes que se necesitan, su posible adaptacin, o la resolucin de solapamientos entre las funciones y servicios que ofrecen.

Una vez disponemos del concepto de componente, un modelo de componentes define la forma de sus interfaces y los mecanismos para interconectarlos entre ellos (p.e. COM, JavaBeans o CORBA). Basada en un modelo de componentes concreto, una plataforma de componentes es un entorno de desarrollo y de ejecucin de componentes que permite aislar la mayor parte de las dificultades conceptuales y tcnicas que conlleva la construccin de aplicaciones basadas en los componentes de ese modelo. En este sentido, p o demos definir una plataforma como una implementacin de los mecanismos del modelo, junto con una serie de herramientas asociadas. Ejemplos de estas plataformas son ActiveX/OLE, Enterprise Beans y Orbix, que se apoyan en los modelos de componentes COM, JavaBeans y CORBA, respectivamente.

Por otro lado, un mercado global necesita tambin de estndares que garanticen la interoperabilidad de los componentes a la hora de construir aplicaciones. En el mundo de los sistemas abiertos y distribuidos estamos presenciando la clsica guerra de estndares que sucede antes de la maduracin de cualquier mercado. Todos los fabricantes y vendedores de sistemas tratan de convertir sus mecanismos en estndares, a la vez que pertenecen a varios consorcios que tambin tratan de definir estndares, pero de forma independiente. Pensemos por ejemplo en Sun, que intenta imponer JavaBeans como modelo de componentes, mientras que participa junto con otras empresas en el desarrollo de los estndares de CORBA. Actualmente la interoperabilidad se resuelve mediante pasarelas (bridges) entre unos modelos y otros, componentes especiales que se encargan de servir de conexin entre los distintos componentes heterogneos. La mayora de los modelos comerciales ofrecen pasarelas hacia el resto, pues reconocen la necesidad de ser abiertos.

2.2.2.-La Programacin Orientada a Componentes:La Programacin Orientada a Componentes (POC) aparece como una variante natural de la programacin orientada a objetos (POO) para los sistemas abiertos, en donde la POO presenta algunas limitaciones; por ejemplo, la POO no permite expresar claramente la distincin entre los aspectos computacionales y meramente composicionales de la aplicacin, no define una unidad concreta de composicin independiente de las aplicaciones (los objetos no lo son, claramente), y define interfaces de demasiado bajo nivel como para que sirvan de contratos entre las distintas partes que deseen reutilizar objetos.

La POC nace con el objetivo de construir un mercado global de componentes software, cuyos usuarios son los propios desarrolladores de aplicaciones que necesitan reutilizar componentes ya hechos y probados para construir sus aplicaciones de forma ms rpida y robusta.

Las entidades bsicas de la POC son los componentes, en el mismo sentido que se ha definido, cajas negras que encapsulan cierta funcionalidad y que son diseadas para formar parte de ese mercado global de componentes, sin saber ni quin los utilizar, ni cmo, ni cundo. Los usuarios conocen acerca de los servicios que ofrecen los componentes a travs de sus interfaces y requisitos, pero normalmente ni quieren ni pueden modificar su implementacin.

En el contexto de este documento se considera a la POC como un paradigma de programacin que se centra en el diseo e implementacin de componentes, y en particular en los conceptos de encapsulacin, polimorfismo, composicin tarda y seguridad. No discutiremos aqu sin embargo otros aspectos de marketing que lleva aso ciado un mercado de componentes software, como cualquier otro mercado: distribucin, comercializacin, empaquetamiento, almacenamiento, publicidad, licencias, etc. Aunque son de especial relevancia para la POC, hemos preferido centrarnos solamente en los aspectos de tcnicos de desarrollo y utilizacin de los componentes software.

2.3. Lenguaje de Programacin Java JDB:Java es un lenguaje de programacin orientado a objetos desarrollado por Sun Microsystems a principios de los aos 90. El lenguaje en s mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos ms simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulacin directa de punteros o memoria.

Las aplicaciones Java estn tpicamente compiladas en un bytecode, aunque la compilacin en cdigo mquina nativo tambin es posible. En el tiempo de ejecucin, el bytecode es normalmente interpretado o compilado a cdigo nativo para la ejecucin, aunque la ejecucin directa por hardware del bytecode por un procesador Java tambin es posible.

La implementacin original y de referencia del compilador, la mquina virtual y las bibliotecas de clases de Java fueron desarrollados por Sun Microsystems en 1995. Desde entonces, Sun ha controlado las especificaciones, el desarrollo y evolucin del lenguaje a travs del Java Community Process, si bien otros han desarrollado tambin implementaciones alternativas de estas tecnologas de Sun, algunas incluso bajo licencias de software libre.

Entre noviembre de 2006 y mayo de 2007, Sun Microsystems liber la mayor parte de sus tecnologas Java bajo la licencia GNU GPL, de acuerdo con las especificaciones del Java Community Process, de tal forma que prcticamente todo el Java de Sun es ahora software libre (aunque la biblioteca de clases de Sun que se requiere para ejecutar los programas Java todava no es software libre).

2.3.1.- Historia

La tecnologa Java se cre como una herramienta de programacin para ser usada en un proyecto de set-top-box en una pequea operacin denominada the Green Project en Sun Microsystems en el ao 1991. El equipo (Green Team), compuesto por trece personas y dirigido por James Gosling, trabaj durante 18 meses en Sand Hill Road en Menlo Park en su desarrollo. 23

El lenguaje se denomin inicialmente Oak (por un roble que haba fuera de la oficina de Gosling), luego pas a denominarse Green tras descubrir que Oak era ya una marca comercial registrada para adaptadores de tarjetas grficas y finalmente se renombr a Java.

El trmino Java fue acuado en una cafetera frecuentada por algunos de los miembros del equipo. Pero no est claro si es un acrnimo o no, aunque algunas fuentes sealan que podra tratarse de las iniciales de sus creadores: James Gosling, Arthur Van Hoff, y Andy Bechtolsheim. Otros abogan por el siguiente acrnimo, Just Another Vague Acronym ("slo otro acrnimo ambiguo ms"). La hiptesis que ms fuerza tiene es la que Java debe su nombre a un tipo de caf disponible en la cafetera cercana, de ah que el icono de java sea una taza de cafe caliente. Un pequeo signo que da fuerza a esta teora es que los 4 primeros bytes (el nmero mgico) de los archivos .class que genera el compilador, son en hexadecimal, 0xCAFEBABE. Otros simplemente dicen que el nombre fue sacado al parecer de una lista aleatoria de palabras.

Los objetivos de Gosling eran implementar una mquina virtual y un lenguaje con una estructura y sintaxis similar a C++. Entre junio y julio de 1994, tras una sesin maratoniana de tres das entre John Gaga, James Gosling, Joy Naughton, Wayne Rosing y Eric Schmidt, el equipo reorient la plataforma hacia la Web. Sintieron que la llegada del navegador web Mosaic, propiciara que Internet se convirtiese en un medio interactivo, como el que pensaban era la televisin por cable. Naughton cre entonces un prototipo de navegador, WebRunner, que ms tarde sera conocido como HotJava.

En 1994, se les hizo una demostracin de HotJava y la plataforma Java a los ejecutivos de Sun. Java 1.0a pudo descargarse por primera vez en 1994, pero hubo que esperar al 23 de mayo de 1995, durante las conferencias de SunWorld, a que vieran la luz pblica Java y HotJava, el navegador Web. El acontecimiento fue anunciado por John Gage, el Director Cientfico de Sun Microsystems. El acto estuvo acompaado por una pequea sorpresa adicional, el anuncio por parte de Marc Andreessen, Vicepresidente Ejecutivo de Netscape, que Java sera soportado en sus navegadores. El 9 de enero del ao siguiente, 1996, Sun fund el grupo empresarial JavaSoft para que se encargase del desarrollo tecnolgico. Dos semanas ms tarde la primera versin de Java fue publicada.

La promesa inicial de Gosling era Write Once, Run Anywhere (Escrbelo una vez, ejectalo en cualquier lugar), proporcionando un lenguaje independiente de la plataforma y un entorno de ejecucin (la JVM) ligero y gratuito para las plataformas ms populares de forma que los binarios (bytecode) de las aplicaciones Java pudiesen ejecutarse en cualquier plataforma.

El entorno de ejecucin era relativamente seguro y los principales navegadores web pronto incorporaron la posibilidad de ejecutar applets Java incrustadas en las pginas web.

2.3.2. Persistencia en Java (JDB):Un objeto se dice persistente cuando es almacenado en un archivo u otro medio permanente. Un programa puede grabar objetos persistentes y luego recuperarlos en un tiempo posterior.

La serializacin se obtiene llamando al mtodo writeObject de la clase ObjectOutputStream para grabar el objeto, para recuperarlo llamamos al mtodo readObject de la clase ObjectInputStream.

La serializacin adems de persistencia, se puede usar para transferir objetos desde una mquina a otra a travs de un socket (ELO330).PARTE III.- FLUJO DE TRABAJO: REQUISITOS

3.1. Identificar actores y casos de uso: 709098ytry7890Un DSBC para la creacin de formulario para usuarios generales.

3.1.1.-Descripcin del actor:

Usuario General.- Se considera usuario general a todo aquel que pueda realizar operaciones en el software para la creacin de componente, podr crear nuevo, abrir, guardar, y editar diseo de formularios y cambiar caractersticas de cada componente.

Lista de Caso de Uso:

CU1.- Nuevo(New)

CU2.- Abrir(Open)

CU3.- Guardar(Save)

CU4.- Seleccionar Componente.

CU5.- Eliminar Componente.

CU6.- Modificar propiedades del Componente.

CU7.- Actualizar Componente.

CU8.- Crear diseo.

CU9.- Seleccionar archivo.

CU10.- Guardar diseo.

CU11.- Adicionar Componente.

3.2. Priorizar casos de uso:Nombre CUDescripcinPrioridad

CU1NuevoAlto

CU2AbrirMedio

CU3GuardarAlto

CU4Seleccionar ComponenteAlto

CU5Eliminar ComponenteBajo

CU6Modificar propiedades del ComponenteBajo

CU7Actualizar ComponenteMedio

CU8Crear diseo.Medio

CU9Seleccionar archivoAlto

CU10Guardar diseoMedio

CU11Adicionar componente.Medio

3.3. Especificar o detallar casos de uso:

CU1: Nuevo

Cu1Nuevo

Propsito Crea un nuevo diseo por defecto.

ActorDiagramador

Actor IniciadorUsuario

Precondicin

PoscondicinCrear diseo(CU8)

CAMINO BSICO

Acciones del ActorRespuesta del Sistema

1. Nuevo2. Adiciona componente (CU11).

3. Devuelve el diseo creado por defecto(CU8).

CAMINO ALTERNO

2. El software no funciona.

CU2: Abrir

Cu2Abrir

Propsito Abre el archivo o diseo del formulario que fue guardado.

ActorUsuario

Actor IniciadorUsuario

Precondicin

PoscondicinSeleccionar archivo(CU9)

CAMINO BSICO

Acciones del ActorRespuesta del Sistema

1. Abrir

2. Seleccionar el archivo.3. Verifica si el archivo existe.

4. Muestra el diseo al usuario como fue guardado.

CAMINO ALTERNO

3. Seleccion otro archivo.

1. Crear nuevo diseo (CU1).

CU3: Guardar

Cu3Guardar

Propsito Guarda el archivo o diseo del formulario que fue creado.

ActorUsuario

Actor IniciadorUsuario

PrecondicinNuevo (CU1), Crear diseo (CU8).

PoscondicinEspecificar el nombre y Guardar diseo(CU10).

CAMINO BSICO

Acciones del ActorRespuesta del Sistema

1. Guardar

3. Asignarle un nombre al archivo.2. Verifica si el archivo existe.

3. Renombra al archivo existente.

4. Guarda dos archivos en formatos .php y .dat.

CAMINO ALTERNO

1. No existe un diseo.

CU4: Seleccionar Componente

Cu4Seleccionar Componente

Propsito - Puede modificar sus propiedades o atributos de cada componete (CU6).

- Puede eliminar un componente que desee (CU5).

- Se actualiza al mover o modificar sus atributos (CU7).

ActorUsuario

Actor IniciadorUsuario

PrecondicinNuevo (CU1), Crear diseo (CU8).

PoscondicinCU6, CU5 y CU7.

CAMINO BSICO

Acciones del ActorRespuesta del Sistema

1. Seleccionar componte.

3. Mover componente.

5. Presionar la tecla Supr.2. Actualizar sus atributos del componente.

4. caso 2.

6. Se elimina el componete.

CAMINO ALTERNO

5. No existe un diseo.

3.4. Diagrama General de CU:

PARTE IV.- FLUJO DE TRABAJO: ANALISIS4.1. Anlisis de la Arquitectura:

El propsito del anlisis de la arquitectura es imaginar el modelo y la arquitectura mediante la identificacin de paquetes. Identifique paquete basndome en los requisitos funcionales (casos de uso).

4.2. Anlisis o Descripcin de Paquetes:

Paquete Presentacin: Este paquete permite: nuevo, guardar y recuperar Formularios, a partir de un archivo.

Paquete Diseo: Este paquete permite adicionar, eliminar, modificar a cada componente que existe en el formulario.

4.3.- Anlisis de Caso de Uso:

Se realizara el anlisis de cada caso de uso utilizando la notacin de clases de anlisis, y se desarrollara en base a diagrama de colaboracin:

4.3.1. Diagrama de Colaboracin de CU1: Nuevo

4.3.2. Diagrama de Colaboracin de CU2: Abrir

4.3.3. Diagrama de Colaboracin de CU3: Guardar

4.3.4. Diagrama de Colaboracin de CU4: Seleccionar componente

4.4. Anlisis de Clases:

4.4.1. Clase Interfaz:

NombreDSBC

TipoFormulario

PropsitoPermitir crear un nuevo, abrir, guardar y modificar un diseo de formulario.

AtributosdiseoDSBC objdiseoDSBC

OperacionesNuevo, Abrir, Guardar, Salir.

ObservacionesSolo muestra un men y paleta que tiene nuevo, abrir, guardar, salir.

4.4.2. Clase Control o proceso:

Nombre diseoDSBC

PropsitoCrea un diseo por defecto, por cada componente que adicione puede hacer, modificaciones y actulizaciones.

EntradaCuando adiciona un componente.

RetornoTodas las propiedades que tiene dicho comp.

OperacionesgetPaleta(), getPropiedad(), actualizarBarra(), cargarPaleta(), cargarPropiedad(), addComponente(), delComponente(), actualizarComponente(), verificarComponente()

4.3.3. Clase Entidad:

Nombrearchivo

ResponsabilidadesMantener los datos referente a todos los componentes que tiene un diseo de formulario.

Atributosurl, filename, file

Relacionesescribe y lee de un archivo.

PARTE V.- FLUJO DE TRABAJO: DISEO.

5.1.Diseo de la Arquitectura:

5.1.1.-Organizado por capas:

5.1.2.- Diseo de Casos de Uso: Diagrama de Secuencia:

5.2.1: XE "4.2 DISEO DE CASO DE USO." Diagrama de Secuencia de CU1: Nuevo

5.2.2. Diagrama de Secuencia de CU2: Abrir

5.2.3. Diagrama de Secuencia de CU3: Guardar

5.2.4. Diagrama de Secuencia de CU4: Seleccionar componente

5.3.- Diseo de Datos: Diagrama general de Clases:

PARTE VI.- FLUJO DE TRABAJO: IMPLEMENTACION:6.1. Arquitectura de la Implementacin:

6.2. Diagrama de Componente Especifico para cada SubSistema:

6.3. Plataforma de desarrollo:

Como plataforma se utilizo el sistema operativo WINDOWS XP Service Pack 3.

El lenguaje de programacin en que se desarrollo fue JDeveloper.

Para ejecutar nuestro formularios creado por el software utilizamos PHP v5.

Como servidor utilizamos Apache appServer.

La informacin persistente de esta aplicacin ser guardada en archivos.

El software desarrollado esta basado en el Proceso Unificado de Desarrollo de Software.

Para visualizar, especificar, construir y documentar utilizamos el Lenguaje Unificado de Modelado (UML).

PARTE VII.- Diseo de Interfaz(FORMULARIO)

7.1.-Creando un nuevo diseo de formulario:

7.2.- Algunos componentes creados en el formulario:

PARTE VIII.- FLUJO DE TRABAJO: PRUEBAS:

8.1. Escritorio (Programa Principal):

Entrada Componentes que tienen la paleta y sus propiedades.

SalidaGuarda el formulario en archivo persistente y php.

Condiciones1.- No se puede abrir un archivo sino fue guardado antes.2.- No se puede eliminar el formulario principal.3.- Guarde el archivo y no cambien de directorio.

Procedimientos1.- Seleccionar o click en unas opciones que tiene la paleta, luego nuevamente de un clic al formulario principal para adicionar los componentes de la paleta.

2.- Seleccion c/uno de los componentes que fue creado en el formulario y vera sus propiedades que tiene cada componentes.3.- Una vez selecciona puede modificar sus propiedades de dicho componente.

4.- Si se requiere eliminar un componente seleccione que no sea el formulario principal, y a continuacin presione la tecla Supr o Del.5.- Presione el men Archivo o en la barra de la parte superior para poder: guardar, crear o abrir un formulario.

8.2. Web:

Esto es un formulario Web que fue creado o generado por el software, es un ejemplo del anterior grafico fig. 7.1.

IX.- Manual del Software

9.1. Formulario Principal: Escritorio

M____Men

____ Barra de Componentes

Formulario de Diceo

Propiedades de Un

Componente

9.2.-Men y barra son las mismas funciones:

-Nuevo: Crea un nuevo diseo por defecto.

Creacin de formularios Abrir: Puede seleccionar el archivo de un formulario de diseo, siempre y cuando haya guardado antes. Guardar y Guardar Como: Guardar el formulario de diseo en un archivo (.dat).

Salir: Sale de la aplicacin del software. Ayuda: Ayuda sobre el software.

Acerca de: Autor del de quien realizo el software.

Paleta:

En la paleta tienen o son los componentes que pueden utilizarse, hacer click en uno de los componentes (jButton, jComboBox, jLabel, etc.) y nuevamente un click al formulario del diseo, se agregara el componente.

Propiedades:

Una vez que se adiciono el componente al formulario de diseo, vuelva a seleccionar dicho componente o el mismo formulario y vera que tiene cada componente sus propias caractersticas, la cual podr modificar sus propiedades (color de letra, color fondo, texto, tamao, etc.) del componente seleccionado.

Para los background y foreground solo seleccion la opcin que tiene.

Para los size, bound, name, text solo cambia a su gusto y luego presione enter.

Para los tems funciona con doble click.

Formulario de diseo:

Es el rea donde se puede adiciona los componentes, puede mover cualquier componente que seleccion y posicionarlo a su gusto.

Este formulario lista todos los archivos o formularios que fueron creados por el DSBC.PARTE X.- CONCLUCION

El desarrollo de software basado en componentes es de mucha importancia para un desarrollador por esta razn desde siempre fue la idea revolucionaria que nos llev a pensar que s era posible el construir software de calidad en corto tiempo y con la misma calidad que la mayora de las industrias de nuestro tiempo. Al mirar hacia atrs, vemos los increbles avances que hemos logrado en la comprensin de la forma correcta de reutilizar el software y el conocimiento existente, y nos asombramos cada vez ms al darnos cuenta de que este solo es el inicio.

El desarrollo de software basado de componentes se convirti en el pilar de la Revolucin Industrial del Software y se proyecta hoy en da en diversas nuevas formas de hacer software de calidad con los costos ms bajos del mercado y en tiempos que antes eran impensables. Empresas como Microsoft entendieron el potencial de esta metodologa hace aos y hoy nos ofrecen nuevas iniciativas y herramientas que buscan llevar al proceso de construccin de software hacia el sitial privilegiado en el que debi colocarse desde un principio.

PARTE XI.- Bibliografa:

IVAR JACOBSON, GRADY BOOCH, JAMES RUMBAUGH

(El proceso unificado de desarrollo de software) GRADY BOOCH, JAMES RUMBAUGH, IVAR JACOBSON

(El lenguaje unificado de modelado)

UML PUDS

WWW.JAVA2S.COM

PARTE XII.- ANEXO ANEXO

INDICE : CREACION DE FORMULARIO1PARTE I.- PERFIL

11.1. Introduccin:

11.2. Objetivo:

11.2.1. Objetivo general:

11.2.2. Objetivos especficos:

11.3. Antecedentes:

21.4. Descripcin del problema:

21.5. Alcance

21.5.1. Requerimientos funcionales:

21.5.2. Plataforma de desarrollo:

21.6. Modelo de Negocio:

21.6.1. Diagrama de Actividad: Adicionar Componente

3PARTE II.- FUNDAMENTO TERICO:

32.1. Herramientas KEY:

52.2. Desarrollo Basado en Componentes:

82.3. Lenguaje de Programacin Java:

102.3.1. Persistencia en Java:

11PARTE III.- FLUJO DE TRABAJO: REQUISITOS....

113.1. Identificar actores y casos de uso:

123.2. Priorizar casos de uso:

123.3. Especificar o detallar casos de uso:

163.4.Diagrama General de CU:

17PARTE IV.-FLUJO DE TRABAJO: ANALISIS

174.1. Anlisis de la Arquitectura:

184.2. Anlisis o Descripcin de Paquetes:

194.3.Anlisis de Caso de Uso:

194.3.1. Diagrama de Colaboracin de CU1: Nuevo

194.3.2. Diagrama de Colaboracin de CU2: Abrir

194.3.3. Diagrama de Colaboracin de CU3: Guardar

204.3.4. Diagrama de Colaboracin de CU4: Seleccionar componente

204.4. Anlisis de Clases:

204.4.1. Clase Interfaz:

204.4.2. Clase Control o proceso:

214.3.3. Clase Entidad:

22PATERTE V.- FLUJO DE TRABAJO: DISEO.

225.1.Diseo de la Arquitectura:

225.2.Diseo de Casos de Uso: Diagrama de Secuencia:

225.2.1: Diagrama de Secuencia de CU1: Nuevo

235.2.2. Diagrama de Secuencia de CU2: Abrir

235.2.3. Diagrama de Secuencia de CU3: Guardar

235.2.4. Diagrama de Secuencia de CU4: Seleccionar componente

245.3.Diseo de Datos: Diagrama general de Clases:

265.4.Diseo de Interfaz Humana:

25PARTE VI.- FLUJO DE TRABAJO: IMPLEMENTACION:

256.1. Arquitectura de la Implementacin:

256.2. Describir componentes por paquetes:

256.3. Plataforma de desarrollo:

PARTE VII.-28 FLUJO DE TRABAJO: PRUEBAS:

287.1. Escritorio (Programa Principal):

297.2. Web:

29PARTE VIII.- Manual del Software: DSBC

298.1. Formulario Principal: Escritorio

30Men y barra son las mismas funciones:

30Paleta:

30Propiedades:

31Formulario de diseo:

PARTE IX.- CONCLUCION 32PARTE X.- 32Bibliografa:

PARTE XII.-ANEXO.33

PAGE 2