PARTE I.

- PERFIL
1.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. Alcance
1.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

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
3

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 software

Los 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 Integracin
Servicios de Portabilidad
Sistema operativo
Plataforma Hardware(HW)
Arquitectura de entorno

Los 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-theshelf). 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,
7

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
8

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).

10

PARTE III.- FLUJO DE TRABAJO: REQUISITOS

3.1. Identificar actores y casos de uso:
DSBC
Desarrollo de Software
Basado en Componentes

Usuario General

709098ytry7890
Un 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.
11

CU7.- Actualizar Componente.

CU8.- Crear diseo.
CU9.- Seleccionar archivo.
CU10.- Guardar diseo.
CU11.- Adicionar Componente.

3.2. Priorizar casos de uso:

Nombre CU

Descripcin

Prioridad

CU1

Nuevo

Alto

CU2

Abrir

Medio

CU3

Guardar

Alto

CU4

Seleccionar Componente

Alto

CU5

Eliminar Componente

Bajo

CU6

Modificar propiedades del Componente

Bajo

CU7

Actualizar Componente

Medio

CU8

Crear diseo.

Medio

CU9

Seleccionar archivo

Alto

CU10

Guardar diseo

Medio

CU11

Adicionar componente.

Medio

3.3. Especificar o detallar casos de uso:

CU1: Nuevo
CU2: Abrir
CU1
Propsito
Actor
Actor Iniciador
Precondicin
Poscondicin
CAMINO BSICO
Acciones del Actor
1. Nuevo

Abrir
NUEVO
CU2

Crea un nuevo diseo por defecto.

Diagramador
Usuario
Crear diseo(CU8)
Respuesta del Sistema
2. Adiciona componente (CU11).
12

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

CAMINO ALTERNO
2. El software no funciona.

CU2
Propsito
Actor
Actor Iniciador
Precondicin
Poscondicin
CAMINO BSICO
Acciones del Actor
1. Abrir

ABRIR
Abre el archivo o diseo del formulario que fue guardado.
Usuario
Usuario

2. Seleccionar el

4. Muestra el diseo al usuario como fue guardado.

Seleccionar archivo(CU9)
Respuesta del Sistema
3. Verifica si el archivo existe.

archivo.
CAMINO ALTERNO
3. Seleccion otro archivo.
1. Crear nuevo diseo (CU1).
CU3: Guardar
Usuario

CU3
Propsito
Actor
Actor Iniciador
Precondicin
Poscondicin
CAMINO BSICO
Acciones del Actor
1. Guardar

CU3
Guardar

<<include>>

CU10
Guardar diseo

GUARDAR
Guarda el archivo o diseo del formulario que fue creado.
Usuario
Usuario
Nuevo (CU1), Crear diseo (CU8).
Especificar el nombre y Guardar diseo(CU10).

3. Asignarle un nombre al archivo.

Respuesta del Sistema

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.

13

CU4: Seleccionar Componente

CU6
Modificar propiedades
del Componente
<<extends>>

Usuario

CU4
Seleccionar
Componente

<<extends>>

CU5
Eliminar
Componente

include

CU7
Actualizar
Componente

14

CU4
Propsito

SELECCIONAR COMPONENTE
- Puede modificar sus propiedades o atributos de cada
componete (CU6).
- Puede eliminar un componente que desee (CU5).

Actor
Actor Iniciador
Precondicin
Poscondicin
CAMINO BSICO
Acciones del Actor
1. Seleccionar componte.

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

Usuario
Usuario
Nuevo (CU1), Crear diseo (CU8).
CU6, CU5 y CU7.
Respuesta del Sistema
2. Actualizar sus atributos del componente.

3. Mover componente.

4. caso 2.

5. Presionar la tecla Supr.

CAMINO ALTERNO
5. No existe un diseo.

6. Se elimina el componete.

3.4. Diagrama General de CU:

15

CU10
Guardar diseo

<<include>>

CU5
Eliminar
Componente

CU3
Guardar

CU6
Modificar propiedades
del Componente

<<extends>> <<extends>>

CU2
Abrir

CU4
Seleccionar
Componente

Usuario

<<include>>
<<include>>
<<include>>
CU1
Nuevo

CU9
Selecionar archvo

CU7
Actualizar
Componente

<<include>>

CU11
Adicionar
Componente

<<include>>
<<extends>>

CU8
Crear diseo

16

PARTE IV.-

FLUJO DE TRABAJO: ANALISIS

4.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).

DSBC
Datos
CU11
Adicionar
Componente

CU5
Eliminar
Componente

<<trace>>
CU9
Selecionar archvo

<<trace>>

<<trace>>

<<trace>>
CU3
Guardar

Negocio

<<trace>>

Presentacion
<<trace>>

<<trace>>
CU1
Nuevo

<<trace>>
Diseo

<<trace>>

<<trace>>
<<trace>>

CU2
Abrir

CU10
Guardar diseo

<<trace>>

CU4
Seleccionar
Componente

CU8
Crear diseo

17

CU6
Modificar
propiedades del
Componente

<<trace>>

CU7
Actualizar
Componente

4.2. Anlisis o Descripcin de Paquetes:

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

<<trace>>

CU2
Abrir

<<trace>>
Presentacion

CU3
Guardar

<<trace>>
<<trace>>

CU9
Selecionar archvo

<<trace>>

CU10
Guardar diseo

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

CU4
Seleccionar
Componente

CU6
Modificar
propiedades del
Componente

<<trace>> <<trace>>
<<trace>>
Diseo
<<trace>>

<<trace>>

CU11
Adicionar
Componente

<<trace>>

CU8
Crear diseo

18

CU7
Actualizar
Componente

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
2. crearDiseo
4. cargarPaleta()
5. cargarPropiedad()

1. Nuevo()
Usuario

DSBC

6. obtenerDiseo
7. getPaleta()
8. getPropiedad()

diseoDSBC

3. addComponente()

component

4.3.2. Diagrama de Colaboracin de CU2: Abrir

2. crearDiseo
4. cargarPaleta()
5. cargarPropiedad()

1. Abrir()
2. selecionar file
Usuario

DSBC

6. obtenerDiseo
7. getPaleta()
8. getPropiedad()

diseoDSBC

4.3.3. Diagrama de Colaboracin de CU3: Guardar

2. getComponente()

1. Guardar()
Usuario

diseoDSBC

DSBC
4. setComponente()

3.getComponente()

componente

estructuraHML

6. guardarArchivo()
archivo

19

4.3.4. Diagrama de Colaboracin de CU4: Seleccionar componente

2. podem os m odificar una de
las propiedades que tiene
c/com ponente

1. Seleciona un
com ponente
Us uario

dis eoDSBC

5. tecla delete
6. delCom ponente()

3, 8. cargarPropiedad()
4, 9. actualiza la propiedad
m odificada

propiedad

7. delCom ponente()

com ponente

4.4. Anlisis de Clases:

4.4.1. Clase Interfaz:
DSBC

Nombre
Tipo
Propsito

DSBC
Formulario
Permitir crear un nuevo, abrir, guardar y

Atributos
Operaciones
Observaciones

modificar un diseo de formulario.

diseoDSBC objdiseoDSBC
Nuevo, Abrir, Guardar, Salir.
Solo muestra un men y paleta que tiene
nuevo, abrir, guardar, salir.

4.4.2. Clase Control o proceso:

diseoDSBC

Nombre
Propsito

diseoDSBC
Crea un diseo por defecto, por cada componente que

Entrada
Retorno
Operaciones

adicione puede hacer, modificaciones y actulizaciones.

Cuando adiciona un componente.
Todas las propiedades que tiene dicho comp.
getPaleta(),
getPropiedad(),
actualizarBarra(),
cargarPaleta(), cargarPropiedad(), addComponente(),
delComponente(),

actualizarComponente(),

verificarComponente()
4.3.3. Clase Entidad:

archivo

20

Nombre

archivo

Responsabilidades Mantener

los

datos

referente

todos

Atributos

componentes que tiene un diseo de formulario.

url, filename, file

Relaciones

escribe y lee de un archivo.

los

PARTE V.- FLUJO DE TRABAJO: DISEO.

5.1. Diseo de la Arquitectura:

<server>
Herram ienta donde es tan todos los
form ularios creado por DSBC

archivo
Browser:
Mozilla
Firefox

Una herramienta de
DSBC, para la creacion
de formularios.

<Es critorio>
PC

<cliente>
PC

21

5.1.1.-Organizado por capas:

Capa Aplicacin
Presentacion

Diseo

Capa Negocio
Negocio

Capa Datos
Datos

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

5.2.1: Diagrama de Secuencia de CU1: Nuevo

Usuario

diseoDSBC

DSBC

componente

2. crearDiseo ()
4. cargarPaleta()
5. cargarPropiedad()
1. Nuevo ()

3. addComponente ()
obtenerDiseo ()
7. getPaleta()
8. getPropiedad()

5.2.2. Diagrama de Secuencia de CU2: Abrir

DSBC

Usuario

diseoDSBC
2. crearDiseo ()
4. cargarPaleta()
5. cargarPropiedad()

1. Abrir ()
2. selecionar file

obtenerDiseo ()
7. getPaleta()
8. getPropiedad()

5.2.3. Diagrama de Secuencia de CU3: Guardar

22

Usuario

diseoDSBC

DSBC

2. getComponente()

componente

estructuraHTML

archivo

3. getComponente ()

1. Guardar ()
4. setComponente()

guardarArchivo ()

5.2.4. Diagrama de Secuencia de CU4: Seleccionar componente

Usuario

diseoDSBC

propiedad
2. podemos modificar una
de las propiedades que
tiene c/ componente

1. Seleciona un componente
5. tecla delete
6. delComponente()

3, 8. cargarPropiedad()
4, 9. actualiza la propiedad
modificada
7. delComponente ()

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

23

componente

PARTE VI.- FLUJO DE TRABAJO: IMPLEMENTACION:

6.1. Arquitectura de la Implementacin:

24

Presentacion

Diseo

Negocio

Datos

Componente.dll

6.2. Diagrama de Componente Especifico para cada SubSistema:

Diseo

barraHerramienta.v
b

paleta.vb

color.vb

propiedades .vb

diseoDSBC.vb

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:
25

7.2.- Algunos componentes creados en el formulario:

26

PARTE VIII.- FLUJO DE TRABAJO: PRUEBAS:

8.1. Escritorio (Programa Principal):
27

Entrada
Salida
Condiciones
Procedimientos

Componentes que tienen la paleta y sus propiedades.

Guarda el formulario en archivo persistente y php.
1.- 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.
1.- 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.

28

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.

29

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.
30

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
31

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

32

ANEXO

INDICE : CREACION DE FORMULARIO

PARTE I.- PERFIL....................................................................................................................1
1.1. Introduccin:.......................................................................................................................... 1
1.2. Objetivo:................................................................................................................................. 1
33

1.2.1. Objetivo general:......................................................................................................... 1

1.2.2. Objetivos especficos:................................................................................................. 1
1.3. Antecedentes:......................................................................................................................... 1
1.4. Descripcin del problema:..................................................................................................... 2
1.5. Alcance................................................................................................................................... 2
1.5.1. Requerimientos funcionales:....................................................................................... 2
1.5.2. Plataforma de desarrollo:............................................................................................ 2
1.6. Modelo de Negocio:............................................................................................................... 2
1.6.1. Diagrama de Actividad: Adicionar Componente.........................................................2
PARTE II.- FUNDAMENTO TERICO:.............................................................................3
2.1. Herramientas KEY:................................................................................................................ 3
2.2. Desarrollo Basado en Componentes:...................................................................................... 5
2.3. Lenguaje de Programacin Java:............................................................................................ 8
2.3.1. Persistencia en Java:.................................................................................................. 10
PARTE III.- FLUJO DE TRABAJO: REQUISITOS....11
3.1. Identificar actores y casos de uso:........................................................................................ 11
3.2. Priorizar casos de uso:.......................................................................................................... 12
3.3. Especificar o detallar casos de uso:......................................................................................12
3.4.
Diagrama General de CU:............................................................................................... 16
PARTE IV.-FLUJO DE TRABAJO: ANALISIS.....................................................................17
4.1. Anlisis de la Arquitectura:.................................................................................................. 17
4.2. Anlisis o Descripcin de Paquetes:..................................................................................... 18
4.3.
Anlisis de Caso de Uso:................................................................................................ 19
4.3.1. Diagrama de Colaboracin de CU1: Nuevo..............................................................19
4.3.2. Diagrama de Colaboracin de CU2: Abrir................................................................19
4.3.3. Diagrama de Colaboracin de CU3: Guardar...........................................................19
4.3.4. Diagrama de Colaboracin de CU4: Seleccionar componente.................................20
4.4. Anlisis de Clases:................................................................................................................ 20
4.4.1. Clase Interfaz:........................................................................................................... 20
4.4.2. Clase Control o proceso:........................................................................................... 20
4.3.3. Clase Entidad:........................................................................................................... 21
PATERTE V.- FLUJO DE TRABAJO: DISEO....................................................................22
5.1.
Diseo de la Arquitectura:.............................................................................................. 22
5.2.
Diseo de Casos de Uso: Diagrama de Secuencia:.........................................................22
5.2.1: Diagrama de Secuencia de CU1: Nuevo...................................................................22
5.2.2. Diagrama de Secuencia de CU2: Abrir.....................................................................23
5.2.3. Diagrama de Secuencia de CU3: Guardar.................................................................23
5.2.4. Diagrama de Secuencia de CU4: Seleccionar componente.......................................23
5.3.
Diseo de Datos: Diagrama general de Clases:..............................................................24
5.4.
Diseo de Interfaz Humana:........................................................................................... 26
PARTE VI.- FLUJO DE TRABAJO: IMPLEMENTACION:................................................25
6.1. Arquitectura de la Implementacin:..................................................................................... 25
6.2. Describir componentes por paquetes:............................................................................... 25
6.3. Plataforma de desarrollo:................................................................................................. 25
PARTE VII.- FLUJO DE TRABAJO: PRUEBAS:.................................................................28
7.1. Escritorio (Programa Principal):...................................................................................... 28
7.2. Web:................................................................................................................................. 29
PARTE VIII.- Manual del Software: DSBC............................................................................29
8.1. Formulario Principal: Escritorio....................................................................................... 29
Men y barra son las mismas funciones:............................................................................30
Paleta:................................................................................................................................. 30
34

Propiedades:........................................................................................................................ 30
Formulario de diseo:......................................................................................................... 31
PARTE IX.- CONCLUCION 32
PARTE X.- Bibliografa:..........................................................................................................32
PARTE XII.-ANEXO.33

35