Contenido

1. Marco terico........................................................................................3 1.1. 1.2. 1.3. 1.4. Introduccin.......................................................................................3 Objetivos...........................................................................................3 Objetivo general..........................................................................3 Formulacin del problema.................................................................4 Alcance..............................................................................................4 Requisitos funcionales.................................................................4

1.2.1.

1.4.1.

Proceso Unificado.....................................................................................4 UML..........................................................................................................5 FLUJOS DE TRABAJO.......................................................................................6 2.1. Contexto..............................................................................................7 2. FLUJO DE TRABAJO: REQUERIMIENTOS....................................................9 2.1. 2.2. 2.3. 2.4. 2.5. 3. 3.1. Modelo de dominio............................................................................9 Identificar casos de uso y actores......................................................9 Priorizacin de casos de uso............................................................10 Detallar casos de uso......................................................................10 Diagrama general de casos de uso..................................................12 Anlisis de casos de uso..................................................................12 Diagrama de colaboracin para el CU1: Crear grupos...............12 Diagrama de colaboracin para el CU2: Asignar privilegios......12 Diagrama de colaboracin para el CU3: Gestionar usuarios......13 Anlisis de clase del CU1...........................................................13 Anlisis de clase del CU2..........................................................14 Anlisis de clase del CU3...........................................................14

FLUJO DE TRABAJO: ANALISIS.................................................................12 3.1.1. 3.1.2. 3.1.3. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.3.

Anlisis de clase..............................................................................13

Anlisis de paquete.........................................................................15 Arquitectura de diseo....................................................................15 Escenario de usuario.................................................................15 Diagrama de paquete organizado en capas....................................16 Disear casos de uso.......................................................................16 Diagramas de secuencia...........................................................16 1

4.

FLUJO DE TRABAJO: DISEO...................................................................15 4.1. 4.2. 4.3. 4.1.1.

4.3.1.

5.

Implementacin.....................................................................................18 5.1. Diagrama de componentes.........................................................18

6. Eleccin de la plataforma de desarrollo de software...................18 6.1. Sistema Operativo.......................................................................18 6.2. Lenguaje de programacin.........................................................18 6.2.1. Herramientas Case................................................................19 7. PRUEBA................................................................................................19 7.1. Mtodo de Prueba........................................................................19 8. Manual de usuario..............................................................................21

COMPONENTE PARA LA GESTION DE USUARIOS, ASIGNACION DE PRIVILEGIOS PARTE I

1. Marco terico. 1.1.Introduccin. La complejidad de 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. Al comparar la evolucin del ambiente de IT con el crecimiento de las metrpolis actuales, podemos entender el origen de muchos problemas que se han presentado histricamente en la construccin de software y vislumbrar las posibles y probables soluciones que nos llevarn hacia la industrializacin del software moderno. Si hay algo que ha aprendido el ser humano desde tiempos muy antiguos es a reutilizar el conocimiento existente para sus cada vez ms ambiciosas empresas. En efecto, al reutilizar trozos de experiencias, ideas y artefactos, no solo nos aseguramos de no cometer los mismos errores del pasado, sino que logramos construir cosas cada vez ms grandes y maravillosas, con bases firmes y calidad incomparable. Este concepto de la reutilizacin, uno de los primeros que se nos ensean a quienes entramos al mundo del desarrollo de software, habremos de utilizarlo desde el mismo instante en que escribamos nuestra primera lnea de cdigo. Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y, de la misma forma, muchos se preguntan da a da el por qu son tan pocos los que realmente alcanzan el xito siguiendo esta filosofa. En realidad, hasta ahora solo hemos tanteado un poco con las posibilidades del software basado en componentes, y es justo hora, en la presente dcada, que la industria del software despegar y se perfeccionar para estar a la par de cualquier otra industria del medio. Las analogas que nos han llevado a estudiar a los sistemas comparndolos con las complejas metrpolis de la actualidad, as como las iniciativas ms innovadoras como las Fbricas de Software de Microsoft, son la clara representacin de que estamos a punto de presenciar un nuevo gran cambio en la forma como pensamos en software. 1.2.Objetivos. 1.2.1. Objetivo general.

Desarrollar un componente reutilizable que se encargue de la administracin de usuarios, asignacin de privilegios en un sistema de informacin. 1.2.2. Objetivos especficos. Analizar y establecer los datos de entrada, los procesos y la salida, para determinar las tareas que debe realizar nuestro componente. Realizar un diseo conceptual adecuado. Implementar el componente en base a las especificaciones del diseo. Disear las interfaces en forma interactiva y fcil de utilizar. Proceder a realizar pruebas del componente con el objetivo de eliminar todos los errores que pueda tener.

1.1.Formulacin del problema. Los sistemas de hoy en da son cada vez ms complejos, deben ser construidos en tiempo rcord y deben cumplir con los estndares ms altos de calidad. Para hacer frente a esto, se concibi y perfeccion lo que hoy conocemos como Ingeniera de Software Basada en Componentes (ISBC), la cual se centra en el diseo y construccin de sistemas computacionales que utilizan componentes de software reutilizables. Esta ciencia trabaja bajo la filosofa de "comprar, no construir", una idea que ya es comn en casi todas las industrias existentes, pero relativamente nueva en lo que a la construccin de software se refiere. Es por esta razn que surge la necesidad de desarrollar un componente para la administracin de usuarios, asignacin de privilegios, etc. 1.2. Alcance. 1.2.1. Requisitos funcionales Crear, actualizar usuarios. Asignacin de privilegios. Registro de las acciones realizadas por el sistema que estarn encriptados. Habilitar o deshabilitar determinado componente del sistema de informacin. 1.1.1. Requisitos no funcionales. La aplicacin ser desarrollada en NetBeans 6.8. Sistema operativo Windows 7. Proceso Unificado El Proceso Unificado (UP, Unified Process) se basa principalmente en la especificacin de requerimientos de un sistema mediante casos de usos. El proceso unificado tiene como aspecto esencial del desarrollo de software que parte de la arquitectura del sistema, siguiendo un proceso iterativo e incremental. El proceso integra diferentes aspectos, como son los ciclos, fases, flujo de trabajo,

mitigacin de riesgos, control de proyectos y control de configuracin. Fases del ciclo

calidad,

administracin

de

El Proceso de Modelado Unificado El Proceso Unificado divide el proceso de desarrollo en ciclos, teniendo producto al final de cada ciclo. Cada ciclo se divide en cuatro Fases: Iniciacin.- Se establece la planificacin del proyecto se delimita su alcance. Elaboracin.- Se analiza el dominio del problema, se establece una base arquitectnica slida, se desarrolla el plan del proyecto y se elimina los elementos de ms alto riesgo del proyecto. Construccin.- Se desarrolla de forma iterativa e incremental un producto completo que esta preparado para la transicin hacia la comunidad del usuario. UML UML es un lenguaje grfico para: Modelar, disear, estructurar, visualizar, especificar y documentar software. Su vocabulario y sintaxis estn ideados para la representacin conceptual y fsica de un sistema. Sus modelos son precisos, no ambiguos y se pueden trasladar a una gran variedad de lenguajes de programacin, como Java, C++, Visual Basic, pero tambin a base de datos relacionales y orientados a objetos. Existen dos clases de ingeniera que se realizan con UML: Ingeniera directa: Es posible generar cdigo a partir de un modelo UML. Ingeniera inversa: Es posible generar cdigo un modelo UML a partir de la implementacin. UML tiene nueve diagramas fundamentales, clasificados en dos grupos, uno para modelar la estructura esttica del sistema y otro para modelar el comportamiento dinmico. 5

Los Diagramas estticos implementados en el sistema son: Clases, componentes y desplegu. Diagrama de Clases Sirven para Describir los componentes esenciales de la arquitectura de un sistema. A diferencia de los diagramas de flujos de datos, los diagramas de clases muestran relaciones de asociacin entre clases y no flujo de datos entre ellas. Diagrama de Componentes Un componente es un modulo de cdigo, de modo que los diagramas de componentes son anlogos fsico a los diagramas de clases. Muestra la organizacin y dependencias de un conjunto de componentes. Cubren la vista de implementacin esttica de un sistema. Diagrama de despliegue Los diagramas de despliegues sirven para modelar la configuracin hardware del sistema, mostrando qu nodos lo componen. Los Diagramas dinmicos utilizados en el sistema son: Casos de Uso, secuencia y navegacin. Diagrama de Casos de casos de uso Describe lo que hace el sistema desde el punto de vista de un observador externo. Plantea escenarios, lo que pasa cuando alguien interacta con el sistema. Proporcionan un resumen para un objetivo. Los actores son papeles que determinadas personas u objetos desempean. Las lneas que unen los Actores con los casos de uso (valos) representan una asociacin de comunicacin. Diagrama de Secuencia Conocidos como diagramas de interaccin o eventos, los cuales describen los diferentes casos de usos segn la interaccin o eventos enviados entre los objetos de la arquitectura de modelo de anlisis. Describen como los objetos del sistema se colaboran. Detalla como las operaciones se llevan a cabo en trminos de que mensajes son enviados y cuando (en torno al tiempo). Diagramas de Navegacin Modela las pginas Web que son los principales componentes de la arquitectura Web. Usando UML se puede ver una pgina Web como un objeto.

FLUJOS DE TRABAJO Captura de los requisitos Es el proceso de averiguar, normalmente en circunstancias difciles, lo que se debe construir. Anlisis Analizamos los requisitos que se describieron en la captura de requisitos, refinndolos y estructurndolos. El objetivo de hacerlo es conseguir una comprensin ms precisa de los requisitos y una descripcin de los mismos que sea fcil de mantener y que nos ayude a estructurar el sistema entero. Diseo

En el diseo modelamos el sistema y encontramos su forma para que soporte todos los requisitos incluyendo los requisitos no funcionales y otras restricciones que se le suponen. Implementacin En la implementacin empezamos con el resultado del diseo e implementamos el sistema en trminos de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binarios ejecutable y similar. El propsito principal de la implementacin es desarrollar la arquitectura y el sistema como un todo. Prueba

Verificamos el resultado de la implementacin probando cada construccin, incluyendo tanto construcciones internas como intermedias, as como las versiones finales del sistema a ser entregadas a terceros. El producto El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual artefactos modelados con el Lenguaje Unificado de Modelado.

COMPONENTES Y CARACTERSTICAS DE DESCRIPCIN

2.1. Contexto
El concepto de componentes para el desarrollo de software no es un concepto nuevo; para muchos autores simplemente es la evolucin del la metodologa orientada a objetos. De hecho, muchas de las caractersticas de los componentes para el desarrollo parten de la idea del diseo orientado a objetos. Pero la historia del desarrollo de software basado en componentes proviene an desde ms atrs. Uno de los logros de la revolucin industrial fue el desarrollo por componentes, surgiendo a partir de la necesidad de estandarizar los elementos de los productos realizados en lnea, como los automviles. Los desarrollos tradicionales de aplicaciones incurren en altos costos y en una inversin de tiempo extensa. El iniciar un desarrollo de software desde cero es un reto muy grande, incluso para una empresa que pueda soportar este proceso. Esto sesgara el desarrollo de software a las grandes empresas, y no le dara cabida a las pequeas y medianas empresas que desean adquirir tecnologas o construir sus propias soluciones. Las empresas pequeas han estado siempre al margen del desarrollo de software; solo hasta la dcada pasada se les permiti la introduccin a este campo. Esta introduccin se origin ante la demanda de estas por buscar sus propios productos para dejar de depender de aquellos que las grandes empresas ponan en el mercado. Por otra parte, las empresas buscaban la reduccin de costos en la tecnologa (Hardware, Software e Infraestructura de Comunicacin). El DSBC busca, dentro de otros objetivos, reducir el tiempo de trabajo, el esfuerzo que requiere implementar una aplicacin y los costos del proyecto, y, de esta forma, incrementar el nivel de productividad de los grupos desarrolladores y minimizar los riesgos globales sin incurrir en gastos exorbitantes. De esta manera, las pequeas empresas pueden tener una mayor confiabilidad a la hora de realizar una inversin tecnolgica. Otra ventaja es poder integrar lo mejor de las tecnologas para desarrollar una aplicacin de manera personalizada, a la medida de las necesidades de los clientes. Esto permite a los desarrolladores y a la empresa adquirir las tecnologas que ms se adapten a sus necesidades, y no incurrir en gastos de licenciamiento o soporte y actualizacin de las grandes soluciones, ya que muchas de estas tecnologas son gratis y existen bajo la premisa de Freeware y GNU (General Public License)1, lo cual aade otra gran ventaja. Otro punto a tomar en cuenta es que el DSBC, pertenece al paradigma de programacin de sistemas abiertos, los cuales son extensibles y tienen una interaccin con componentes heterogneos que ingresan o abandonan el sistema de forma dinmica, es decir que los componentes pueden ser remplazados, por otros independientemente de su arquitectura y desarrollo . De esta manera se puede hacer un paralelo entre el mundo percibido por el hombre y el DSBC desde un punto de vista menos formal y con una perspectiva del mundo cotidiano donde se tienen sistemas abiertos y cerrados. Por ejemplo, el ser humano es un sistema abierto y realiza interacciones con el medio (otro sistema), la mayora de los sistemas en el mundo percibido por el hombre son abiertos y necesitan una interaccin con el medio para poder sobrevivir como en el caso del hombre (alimentos, aire, relaciones, etc). Esta interaccin es la que permite que crezca el sistema 8

(extensin), dndole la posibilidad de mejorar con el tiempo y lograr una estabilidad (evolucin para el caso del hombre). 2.2. Concepto Lo ms importante que se debe tener en cuenta al definir el concepto de DSBC, es el de diferenciar las caractersticas existentes entre el DSBC y el paradigma de objetos, la Programacin Orientada a Objetos (POO) es cuando el software puede ser desarrollado de acuerdo a un modelo mental de un objeto real o imaginado, mientras que el DSBC dice que el software debe ser desarrollado a partir de componentes prefabricados. Existen varias definiciones de componentes realizadas por expertos que han sido los encargados del desarrollo de esta metodologa, ellos han tomado como base la metodologa de la programacin orientada objetos y el modelado a travs de UML: Un componente es una parte no trivial, casi independiente, y reemplazable de un sistema que llena claramente una funcionalidad dentro de un contexto en una arquitectura bien definida. Un componente se conforma y provee la realizacin fsica por medio de un conjunto de interfaces. Un componente de software en tiempo de ejecucin es un paquete dinmicamente vinculado con uno o varios programas manejados como una unidad y que son accedidos mediante interfaces bien documentadas que pueden ser descubiertos en tiempo de ejecucin. Un componente de software es una unidad de composicin con interfaces contractualmente especificadas y explcitas slo con dependencias dentro de un contexto. Un componente de software puede ser desplegado independientemente y es sujeto a la composicin de terceros. Un Componente de Negocio representa la implementacin de software del concepto de un negocio autnomo o un proceso de negocio. Que consiste de artefactos de software necesarios para expresar, implementar y poner en marcha el concepto de elemento reusable de un sistema mas grande de negocios.

Estas definiciones no son mutuamente excluyentes, por el contrario, se complementan y construyen el significado no slo de componente, tambin el significado del desarrollo basado en componentes. Sin embargo ms all de su definicin existen algunas caractersticas claves para que un elemento pueda ser catalogado como componente: Identificable: Debe tener una identificacin que permita acceder fcilmente a sus servicios y que permita su clasificacin. Auto contenido: Un componente no debe requerir de la utilizacin de otros para finiquitar la funcin para la cual fue diseado. Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore. Con acceso solamente a travs de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementacin. Sus servicios no varan: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementacin s. Bien Documentado: Un componente debe estar correctamente documentado para facilitar su bsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc. Es genrico: Sus servicios debe servir para varias aplicaciones. 9

Reutilizado dinmicamente: Puede ser cargado en tiempo de ejecucin en una aplicacin. Independiente de la plataforma: Hardware, Software, S.O.

PARTE II 1. FLUJO DE TRABAJO: REQUERIMIENTOS. 1.1.Modelo de dominio.

analysis Analysis Vi...

Ev ento Tipo: int Nombre: string Activo: boolean +1...* registra FGrupo -

Formulario Nombre: string Activo: boolean -

GrupoFormulario Grupo: int Acti vo: boolean

TablaGV

TablaGrupo +1...1 Bitacora Archiv oGrupo +1...* realiza Grupo Nombre: string Activo: boolean Archiv oTGV FGrupoPriv ilegios

+1...1 Usuario Nombre: string Apellidos: string Login: string Password: string Activo: boolean

TablaUsuario

Archiv oUsuario FUsuario

1.2.Identificar casos de uso y actores. 1.2.1. Identificar de casos de uso. CU1: Crear grupos CU2: Asignar privilegios. CU3: Gestionar usuarios. CU4: Ver bitcora. 1.2.2. Identificar actores. Administrador: Es la persona encargado de crear usuarios, darles privilegios. 1.3.Priorizacin de casos de uso. Caso de uso CU1: Crear grupos CU2: Asignar privilegios CU3: Gestionar usuarios CU4: Ver bitcora

Estado Aprobad o Aprobad o Aprobad o Aprobad

Priorida d Importan te Critico Importan te Importan

Riesg o Norma l Critico Norma l Norma 10

te

1.4.Detallar casos de uso. Caso de Uso CU 1: Crear grupos Propsito Actor Actor Iniciador Pre-Condicin Flujo Principal <<1. Registrar>> 1.1.Insertar el nombre del nuevo grupo 1.2.Registrar. << 2. Modificar >> 2.1. Cambiar el nombre del grupo. 2.2 Guardar las modificaciones. << 3. Salir >> 3.1. Presionar salir. Crear y guardar el grupo. 1.1. 1.2. 1.1. 4.1. No se permite caracteres invlidos. No se permite caracteres nulos. Error el nombre del grupo ya existe. No existe el cdigo ingresado. Registrar, modificar grupos. Administrador Administrador

Post-Condicin Excepciones

Caso de Uso Propsito Actor Actor Iniciador

CU2: Asignar privilegios Asignacin de privilegios a los grupos. Administrador Administrador 11

Pre-Condicin Flujo Principal

CU1: Crear grupos. <<1. Registrar>> 1.1.Presione el botn grupos, para verlos. 1.2.Seleccione un grupo. 1.3.Despliegue el combobox para elegir el formulario. 1.4.Tickee habilitar a los eventos que el grupo podr acceder. 1.5.Registrar. << 2. Salir >> 2.1. Presionar salir. Asignacin de formularios, botones a los grupos.

Post-Condicin Excepciones

Caso de Uso Propsito Actor Actor Iniciador Pre-Condicin Flujo Principal

CU3: Gestionar usuarios. Creacin de usuarios. Administrador Administrador CU1: Crear grupos. CU2: Asignar privilegios. <<1. Registrar>> 1.1.Insertar nombre, apellido, usuario y contrasea. 1.2.Seleccione un grupo. 1.3.Registrar. << 2. Salir >> 2.1. Presionar salir. Asignacin de formularios, botones a los grupos.

Post-Condicin Excepciones

Caso de Uso Propsito Actor Actor Iniciador Pre-Condicin

CU4: Ver bitcora Registrar todas las acciones que se efectan en el sistema. Administrador Administrador CU1: Crear grupos. CU2: Asignacin de privilegios. 12

CU3: Gestionar usuarios. Flujo Principal

1.1.Diagrama general de casos de uso.

analysis Analysis Vi...

CU1: Crear grupos

CU2: Asignar privilegios Administrador

CU2: Gestionar usuarios

2. FLUJO DE TRABAJO: ANALISIS. 2.1.Anlisis de casos de uso. 2.1.1. Diagrama de colaboracin para el CU1: Crear grupos.
analysis Analysis Vi... 3: Salir() 2: Modificar() 1: Agregar() FGrupo Administrador Grupo 2.1: Insertar nuevo nombre() 1.1: Insertar nombre grupo()

2.2: Guardar cambios() 1.2: Agregar() ArchivoGrupo

2.1.2. Diagrama de colaboracin para el CU2: Asignar privilegios.

analysis Analysis Vi...

3: Salir() 2: Guardar() 1: Grupo() 2.1: tickee en las opciones() 1.1: Mostrar grupos()

1.2: Obtener grupos() ArchivoGrupo

FGrupoPrivilegios Administrador

GrupoFormulario

2.2: Guardar() 1.3: Guardar()

ArchivoT GF

13

2.1.3. Diagrama de colaboracin para el CU3: Gestionar usuarios.

a na lys is Ana lys is V i...

A rch i vo G ru p o 1 .2 : O b te n e r g ru p o () 2 .1 : S a l i r d e l si ste m a () 1 .1 : In se rta r d a to s() 1 .3 : G u a rd a r u su a ri o () u su a ri o A rch i vo Usu a ri o

2 : S a l i r() 1 : G u a rd a r()

Adm inis tra dor

FUsu a ri o

2.2.Anlisis de clase. 2.2.1. Anlisis de clase del CU1. Interfaz: FGrupo Nombre FGrupo Tipo Formulario Propsito Permite crear los grupos. Atributos Nombre del grupo Operaciones Agregar, Salir Control: Grupo Nombre Propsito Entrada Retorno Proceso

Grupo Controlar los datos del grupo. Cliente = (Nombre) mensajes Obtiene las caractersticas del grupo. Valida datos del cliente

Entidad: Grupo Responsabilidad Atributos Relacin

Capturar datos del grupo Nombre ----------

2.2.2. Anlisis de clase del CU2. Interfaz: Asignar privilegios. Nombre Tipo Propsito Atributos Operaciones FGrupoPrivilegios Formulario Asigna privilegios al grupo. Grupo Guardar, Salir 14

Control: GrupoFormularios Nombre GrupoFormularios Propsito Controla al asignacin de privilegios a los grupos Entrada GrupoPrivilegios = (Grupo, Formulario, Botones, labels, jtexfield ). Retorno mensajes Proceso Entidad: ArchivoTGV Responsabilidad Atributos Relacin

Guardar datos del archivo Grupo, formularios, eventos. ----------

2.2.3. Anlisis de clase del CU3. Interfaz: FUsuario. Nombre Tipo Propsito Atributos Operaciones Control: Usuario Nombre Propsito Entrada Retorno Proceso FUsuario Formulario Gestionar usuarios del sistema. Nombre, apellidos, usuario, contrasea y grupo. Guardar, Salir

Usuario. Crear usuarios, asignacin de grupos. Usuario = (Nombre, Apellidos, Usuario, Contrasea y Grupo ). mensajes

Entidad: ArchivoUsuario Responsabilidad Guardar datos en el archivo Atributos Nombre, Apellidos, Usuarios, Contrasea y Grupo Relacin ---------2.3.Anlisis de paquete. 3. FLUJO DE TRABAJO: DISEO. 3.1.Arquitectura de diseo. Diseo Integrado del Sistema Informacin

15

analysis Analysis Vi... Componente de seguridad

Gestionar

Bitacora

Seguridad

3.1.1. Escenario de usuario. 3.1.1.1.Vista del sistema principal con los subsistemas. Gestionar.
a a s Aa s V n ly is n ly is i... Gs nr e tio a

A m is ra o d in t d r

C a g p re r ru o

G s n r u u rio e tio a s a s

Bitcora
an sis A aly aly n sis V i... B itaco ra

V b er itaco ra A m istrad r d in o

Seguridad.

16

a a s A a ssV n ly is n ly i i... B a oa i cr t

V rb a oa e it c r Am isr d r d in t a o

3.2. Diagrama de paquete organizado en capas.

Reportes Capa especificada

G estionar

Bitacora

Capa general de la

Programacion JDEVELOPER

Capa intermedia de

Capa del software

3.3.Disear casos de uso. 3.3.1. Diagramas de secuencia. 3.3.1.1.Diagrama de secuencia del CU1.

17

sd Interaction FGrupo Administrador 1. Agregar() 1.1. Insertar nombre grupo() Grupo ArchivoGrupo

Validar() 1.2. Guardar grupo() 2. Modificar() 2.1. Insertar nuevo nombre() 2.2. Modificar()

3. Salir()

3.3.1.2.Diagrama de secuencia del CU2.

sd Interaction FGrupoUsuario Administrador GrupoFormulario ArchivoGrupo ArchivoTGF

1. Grupos() 1.1. Mostrar() 1.2. Obtener datos()

2. Guardar() 2.1. Insertar datos() 2.2. Guardar() 3. Salir()

3.3.1.3.Diagrama de secuencia del CU3.

18

sd Interaction FUsuario Administrador Usuario ArchivoGrupo ArchivoUsuario

1. Guardar() 1.1. Insertar datos() 1.2. Obtener grupos() 1.3. Guardar usuario() 2. Salir()

4. Implementacin. 4.1.Diagrama de componentes Diagrama general de componente

Ges tion ar <<tra ce>> C om pon ente.JAR <<trace>> Bitaco ra

<<trace >>

Seg urid ad

6. Eleccin de la plataforma de desarrollo de software. 6.1. Sistema Operativo. Sistema Operativo Windows XP, Vista, 7 Escogimos este SO porque es el ms conocido y ms utilizado a nivel empresarial y domestico. 6.2. Lenguaje de programacin Lenguaje de Programacin JAVA, NeatBeans 6.8

El Lenguaje elegido para desarrollar ha sido JAVA aprovechando la diversidad de herramientas que ste presenta las cuales usadas adecuadamente pueden facilitar en gran parte el desarrollo de software. Una de las caractersticas ms notables del lenguaje es su multiplataforma.

19

JAVA es el lenguaje preferido para el desarrollo de componentes debido a su ya larga tradicin como lenguaje sencillo y de fcil manejo. JAVA aporta un buen nmero de caractersticas, entre las novedades aportadas tenemos: Plenas capacidades de orientacin a objetos Ms Liviano al momento de ejecutar

6.1.1.Herramientas Case. Enterprise Architect UML 7.5 6. PRUEBA

La estrategia de pruebas que se planifico en el sistema de gestin para la Administracin de Compra, Venta e Inventario de la Microempresa FAMECH, siguiendo el proceso unificado, son bsicamente los casos de uso como casos de prueba, partiendo por la prueba de unidad. Las pruebas de integracin sern realizadas en los casos de uso ms importantes del sistema, ya que para que estos funcionen necesariamente los CU Bsicos tienen que funcionar bien, es por eso que realizando la prueba al Gestionar Venta, se podr realizar una prueba satisfactoria. Las pruebas de validacin sern dirigidas por los casos de uso, validando las entradas y analizando las salidas o resultados que se obtengan del sistema. En las pruebas de validacin se aplicara los mtodos de prueba de la caja negra, los que se centran en los casos de uso. 6.1. Mtodo de Prueba.

En el modelo de prueba se describe algunos casos de prueba y procedimiento de prueba que se aplica a los componentes ejecutables del modelo de implementacin, con pruebas de integracin y validacin. Los casos de pruebas especifican la forma de probar el sistema, probando las entradas y el resultado a probarse. En los modelos de prueba se utiliza los mtodos de prueba de la caja blanca, caja negra, las pruebas basadas en fallos y tambin la pruebas de escenario para verificar que le sistema se adapte a los requisitos del cliente. REGISTRAR USUARIO 1. Entrada: Se genera un ID por cada usuario El administrador introduce los datos del usuario. 20

2. Resultado: Si es valida la condicin. Insertar los datos satisfactoriamente.

1. Condicin: Para acceder al caso de uso: Registrar usuario se tienen las siguientes condiciones: Si EsNuevo(Nombre) Entonces Adicionar_Usuario() Sino No adicionarlo REGISTRAR GRUPO 1. Entrada: Se genera un ID por cada grupo El administrador introduce el nombre del grupo.

2. Resultado: Si es valida la condicin. Insertar los datos satisfactoriamente.

1. Condicin: Para acceder al caso de uso: Registrar grupo se tienen las siguientes condiciones: Si EsNuevo(Nombre) Entonces Adicionar_Grupo () Sino No adicionarlo

21

PARTE III. 6. Manual de usuario.

En el proyecto creamos dos componentes. Seguridad: Que tiene los formularios y clases, para la gestin de usuarios, asignacin de privilegios, etc. Configuracin: Este componente nos cargara Ya tenemos los componentes agregados a la paleta, como muestra en la figura.

Componente configuracin

Componente seguridad

1. Arrastramos los dos componentes hasta el formulario principal (donde se esta implementando el sistema de informacin) 2. Hacemos la conexin. 3. Luego vemos que el componente se muestra en el men principal del proyecto.

4. Usuario: 22

A travs de este formulario insertaremos los datos de los usuarios elegir el grupo al cual pertenecer. 5. Grupos.

Mediante este formulario crearemos los grupos adems tendremos la opcin de modificarlos. 6. Asignacin de privilegios al grupo.

23

Primero le damos clic en el botn grupo, este nos mostrara a todos lo grupos creados. En el combobox escogemos el formulario a capturar, a continuacin la tabla nos mostrara los elementos que tiene el formulario como ser los botones, textfield, si queremos habilitar dicho botn simplemente marcamos la casilla habilitado, en caso contrario lo desmarcamos.

24