Estructura Proyecto1

UNIVERSIDAD SAN PEDRO
SEDE BARRANCA

FACULTAD DE INGENIERA
ESCUELA DE INGENIERA INFORMTICA
Y DE SISTEMAS

PROYECTO DE PEDIDOS ONLINE AGRICOLA
CHAVES S.A.C

PRESENTADO POR:
CELESTINO DOMINGUEZ EDGAR JEISSON
RIOS ALVARADO OSCAR

BARRANCA PERU
2014

SISTEMA DE PEDIDOS ON-LINE

INGENIERIA INFORMATICA Y DE SISTEMAS X 2014 Pgina 2

DEDICATORIA
Queremos dedicar este trabajo a nuestras
familias, por acompaarnos en cada uno de
nuestros proyectos que hemos emprendido
y ser siempre nuestras ms grandes
motivaciones para seguir adelante.



AGRADECIMIENTO
El presente documento, el cual
presentamos como informe de prcticas
Pre-Profesionales II, no habra sido posible
sin el apoyo de muchas personas, a cuales
agradecemos.
A nuestra Universidad San Pedro, Alma
Mater que nos forma profesionalmente, y
en especial a la Facultad de Ingeniera,
cuyos docentes nos brindan los
conocimientos que son base importante
para nuestra formacin universitaria, en
cuyas aulas comprendimos que el estudiar
no es aprender por un instante, sino para
toda la vida, poniendo en prctica los
conocimientos adquiridos.


NDICE GENERAL
1. NOMBRE DEL PROYECTO ................................................................................................. 10
1.1. DESCRIPCION DEL PROYECTO .............................................................................. 10
1.2. LOGOTIPO DE LA ORGANIZACIN ....................................................................... 11
1.3. RAZON SOCIAL DE LA ORGANIZACIN: ............................................................ 11
1.4. DESCRIPCION DE LA ORGANIZACIN ............................................................... 11
1.5. ORGANIGRAMA ........................................................................................................... 12
1.6. SITUACION PROBLEMTICA .................................................................................. 13
1.6.1. PLANTEAMIENTO DEL PROBLEMA................................................................ 13
1.6.2. ANTECEDENTES DEL PROBLEMA ................................................................... 13
1.7. JUSTIFICACION DEL PROYECTO ........................................................................... 13
1.7.1. JUSTIFICACION TECNICA ............................................................................... 13
1.7.2. JUSTIFICACION OPERATIVA .......................................................................... 14
1.7.3. JUSTIFICACION ECONOMICA ........................................................................ 14
1.8. OBJETIVOS DEL PROYECTO .................................................................................... 14
1.8.1. OBJETIVO GENERAL .......................................................................................... 14
1.8.2. OBJETIVO ESPECIFICO ..................................................................................... 14
1.9. LIMITACIONES DEL PROYECTO ............................................................................ 15
1.9.1. LIMITACION CRONOLOGICA .......................................................................... 15
1.9.2. LIMITACION TECNOLOGICA ........................................................................... 15
1.9.3. LIMITACION TECNICA ...................................................................................... 15
2. UML .......................................................................................................................................... 16
2.1.1. Estandarizacin de UML ................................................................................... 17
2.1.2. Historia de UML ................................................................................................... 17
2.2. PROCESO UNIFICADO PARA DESARROLLO DE SOFTWARE (RUP)........... 23
2.2.1. Generalidades y aportes: ................................................................................. 23
2.2.2. Caractersticas principales .............................................................................. 24
2.2.3. Modelo de Referencia Organizacional......................................................... 25


2.2.4. Fases en el ciclo de Desarrollo ....................................................................... 27
2.2.5. Subproductos ....................................................................................................... 28
2.3. MODELO VISTA CONTROLADOR ........................................................................... 33
2.3.1. Descripcin del patrn ...................................................................................... 33
2.3.1.1. Modelo: ............................................................................................................... 33
2.3.1.2. Vista: ................................................................................................................... 34
2.3.1.3. Controlador:...................................................................................................... 34
2.4. GESTOR DE BASE DE DATOS - MySQL ................................................................. 36
2.5. HTML ............................................................................................................................... 39
2.6. PHP .................................................................................................................................. 39
2.7. CODEIGNATER ............................................................................................................. 40
2.8. CSS ................................................................................................................................... 41
2.9. JQUERY ........................................................................................................................... 43
2.10. AJAX ............................................................................................................................. 44
3. MODELO DEL NEGOCIO:........................................................................................... 46
3.1.1. PICTOGRAMA: ...................................................................................................... 46
3.1.1.1. PICTOGRAMA: VENTA AL CONTADO ........................................................ 46
3.1.1.2. PICTOGRAMA: VENTA A CREDITO ............................................................ 47
3.1.2. PROCESOS DE NEGOCIO .................................................................................. 47
3.1.3. REGLAS DEL NEGOCIO ...................................................................................... 48
3.1.5. MODELO DE CASO DE USO DEL NEGOCIO ................................................. 49
3.1.6. ESPECIFICACIN DE CASOS DE USO DEL NEGOCIO ............................. 50
3.1.7. DIAGRAMA DE ACTIVIDAD POR CADA USO DEL NEGOCIO ................ 51
3.1.8. MODELO DE OBJETO DEL NEGOCIO ............................................................ 53
3.1.9. MODELO DE DOMINIO ...................................................................................... 53
3.2. MODELO DE REQUERIMIENTOS ............................................................................ 55
3.2.1. MODELO DE CASO DE USO DE REQUERIMIENTO DETALLADO .......... 55
3.2.1.1. GESTIONAR PRODUCTO ............................................................................... 55
3.2.1.2. GESTIONAR CLIENTE .................................................................................... 55
3.2.1.3. GESTIONAR CATLOGO ................................................................................ 57
3.2.1.4. GESTIONAR PEDIDO ..................................................................................... 58


................................................................................................................................................... 58
3.2.2. DIAGRAMA DE CASO DE USO DE REQUERIMIENTOS ............................ 59
3.2.3. MATRIZ DE PRIORIZACIN DE CASO DE USOS ...................................... 60
3.2.4. ESPECIFICACION DE CASO DE USOS DE REQUERIMIENTOS ............. 61
3.2.4.1. ESPECIFICACION DEL CASO DE USO: GESTIONAR PRODUCTOS .......................... 61
3.2.4.2. ESPECIFICACION DEL CASO DE USO: GESTIONAR CLIENTE .................................. 64
3.2.4.3. ESPECIFICACION DEL CASO DE USO: GESTIONAR CATLOGO ............................ 70
3.2.4.4. ESPECIFICACION DEL CASO DE USO: GESTIONAR PEDIDO .................................. 74
3.3. ANALISIS ....................................................................................................................... 79
3.3.1. DIAGRAMA DE CLASES ENTIDAD ................................................................. 79
3.3.2. DIAGRAMA DE PAQUETE DE ANALISIS ...................................................... 80
3.4. DISEO ........................................................................................................................... 80
3.4.1. INTERFACE DE USUARIO ................................................................................. 80
3.4.2. DIAGRAMA DE SECUENCIA DE DISEO ..................................................... 83
3.4.2.1. DIAGRAMA DE SECUENCIA DE DISEO: GESTIONAR PRODUCTO
83
3.4.2.2. DIAGRAMA DE SECUENCIA DE DISEO: GESTIONAR CLIENTE .... 84
3.4.2.3. DIAGRAMA DE SECUENCIA DE DISEO: GESTIONAR CATLOGO 87
3.4.3.4. DIAGRAMA DE SECUENCIA DE DISEO: GESTIONAR PEDIDO ..... 88
3.4.3. DIAGRAMA DE CLASES DE DISEO ............................................................. 91
3.4.4. DIAGRAMA DE ESTADO - GESTIONAR PEDIDO ....................................... 92
3.4.5. DIAGRAMA DE PAQUETE DE DISEO .......................................................... 92
3.4.6. MODELO FISICO DE LA BASE DE DATOS RELACIONAL (MySql) ........ 93
3.4.7. MODELO FISICO DE LA BASE DE DATOS RELACIONAL
(Normalizado) ...................................................................................................................... 94
3.5. PRUEBA .......................................................................................................................... 94
3.5.1. PRUEBA DE LA CAJA NEGRA ........................................................................... 94
4. CONCLUSIONES .................................................................................................................. 98
5. RECOMENDACIONES ......................................................................................................... 99
6. REFERENCIAS BLIOGRAFICAS Y/O ENLACES WEB ............................................. 100
7. BILIOGRAFIAS ................................................................................................................... 101


8. APENDICE ............................................................................................................................ 102
FORMATO DE ESPECIFICACION DE LOS CASOS DE USO DE REQUERIMIENTOS
......................................................................................................................................................... 102

RESUMEN
El presente proyecto consiste en desarrollar e implementar una pgina web para la
empresa Agrcola Chaves S.A.C dedicado a la venta de productos agrcolas. La principal
caracterstica de esta pgina es la facilidad de edicin de informacin gracias a un sistema
de administracin de contenidos y galeras, resolviendo as las necesidades especficas de
la empresa.
El presente proyecto implica tres ramas. La primera de estas ramas es la Programacin
Web siendo esta la base principal del proyecto, se apoyar en la rama de Diseo Web y
sustentar toda su informacin en la rama de Base de Datos.



ABSTRACT
This project is to develop and implement a website for the company Agrcola Chaves
S.A.C dedicated to the sale of agricultural products. The main feature of this page is the
ease of editing of information through a content management system and galleries, thus
addressing the specific needs of the company.
This project involves three branches. The first of these branches is the Web Programming
being the basis of the project, will be supported in the Web Design industry and sustain all
its information in the database.



INTRODUCCION
Actualmente la presencia en internet no es un mero tem ms en la lista de aspectos a
considerar por las empresas para posicionarse y potenciar su imagen hacia el exterior. No
basta con tener una pgina web slo por cumplir con lo que dictan las tendencias actuales
o para no quedarse atrs frente a la competencia. Hoy la calidad de los sitios se mide no
por lo que muestran, sino por lo que hacen. No por lo atractivo de su diseo, sino por la
cantidad de necesidades que satisfacen, la contundencia de sus contenidos, los servicios
que permiten realizar en lnea y el valor agregado que se entrega a los usuarios.



1GENERALIDADES
1. NOMBRE DEL PROYECTO

Sistema de pedidos On-Line Agrcola Chaves S.A.C

1.1. DESCRIPCION DEL PROYECTO

El presente proyecto pretende describir las tareas generales realizadas en
los distintos procesos de Anlisis, Diseo y puesta en funcionamiento, as
como los resultados generados por cada uno, dentro del desarrollo de una
aplicacin de pedido a travs de Internet.

Un elemento que se quiso tener en cuenta es la intencin que la propia
tienda tenga un carcter comercial para la empresa que vende los
productos, y no slo como un lugar donde realizar pedidos. Para ello, se
tomaron decisiones como la de incluir informacin general de la empresa,
inclusin de banner en la pgina, permitir que cualquier usuario pudiera
navegar por el catlogo y los productos, pedir informacin sobre ellos, etc.

El usuario recibir la ayuda de un formulario el cual le ayudara a poder
elegir el producto que est buscando, mediante una seria de preguntas el
cual al finalizar le har una recomendacin de los productos que puedan
satisfacer su necesidad.
Adems, el hecho de registrarse en la web tendra otros aadidos para los
usuarios aparte del propio de poder comprar como seran la descarga del
catlogo completo o de partes de l en un formato fcilmente portable
como es el PDF.
La informacin que recaude el sistema de la pgina web podr usarse para
mostrar reportes y estadsticas en grficos.



1.2. LOGOTIPO DE LA ORGANIZACIN

1.3. RAZON SOCIAL DE LA ORGANIZACIN:

NOMBRE
Agrcola CHAVES S.A.C
DIRECCION
Jr. Olivar # 324
FONO
235-5341
E-MAIL
AgrcolaChaves@gmail.com

1.4. DESCRIPCION DE LA ORGANIZACIN
Agrcola Chaves S.A.C , es una empresa peruana encargada de la
distribucin de diversos productos, los cuales estn orientados
principalmente en la atencin del mercado agrcola.
El liderazgo en el mercado es producto de esfuerzo, seriedad, compromiso y
responsabilidad de nuestro el equipo de trabajo, el cual est conformado
por personas comprometidas en fijar nuevos estndares y excelencia en
atencin al cliente con el fin de ofrecer la mejor alternativa l mercado y de
esta manera sus clientes puedan obtener los mejores beneficios.



1.5. ORGANIGRAMA

GERENTE GENERAL

CONTABILIDAD Y
CAJA CENTRAL

ADMINISTRADOR

DEPARTAMENTO
LEGAL

TIENDA PRINCIPAL Y
ALMACEN

SUCURSAL

CAJERO VENDEDOR

CAJERO VENDEDOR

PROMOTOR DE
VENTAS Y COB. 1

PROMOTOR DE
VENTAS Y COB. 2

VENDEDOR DE
MOSTRADOR

ENCARGADO DE
ALMACEN

PROMOTOR DE
VENTAS Y COB. 1

PROMOTOR DE
VENTAS Y COB. 2

VENDEDOR DE
MOSTRADOR

Figura 01: Organigrama de la Organizacin



1.6. SITUACION PROBLEMTICA
1.6.1. PLANTEAMIENTO DEL PROBLEMA
Agrcola Chaves S.A.C actualmente no cuenta con un lugar en
internet, perdiendo as una oportunidad publicitar sus productos
en un medio de comunicacin muy usado hoy en da. Los
clientes actuales necesitan informacin las 24 horas del da sin
importar donde se encuentren. Los clientes que navegan por
internet nunca sern clientes reales porque no encontraran un
sitio web de la empresa.

1.6.2. ANTECEDENTES DEL PROBLEMA
ESCUELA SUPERIOR PLITECNICA DEL LITORAL Y
POCKET PC
TEMA: Anlisis, diseo e implementacin de un sistema de
pedido en internet
El constante avance tecnolgico nos exige ciertas actividades
que han sido llevadas de una misma manera por aos como es
la toma de decisiones de pedidos manuales. Por esta necesidad
nosotros hemos creado un sistema de pedidos en internet y
pocket pc el cual le permitir a cualquier persona consultar y
efectuar el ingreso de pedidos en lnea desde un computador lo
cual facilitara la vida diaria de las personas, quienes ya no
debern esperar al vendedor para realizar las solicitudes de sus
productos.
1.7. JUSTIFICACION DEL PROYECTO
1.7.1. JUSTIFICACION TECNICA
Brindar a la a la empresa Agrcola Chaves S.A.C un
soporte de informacin adecuado, eficiente mediante la
implementacin de Un sistema informtico para el
desarrollo de sus requerimientos en sus diversos
procesos.


1.7.2. JUSTIFICACION OPERATIVA
El beneficio que traera realizar este sistema web es de
agilizar la los pedidos de los usuarios.
Reduccin del tiempo para la realizacin de cada proceso.
Facilidad del manejo de los procesos en el sistema web de
informacin gracias a una interfaz amigable y fcil de utilizar.

1.7.3. JUSTIFICACION ECONOMICA
A mayor pedido de los usuarios, la empresa Agrcola Chaves
S.A.C va a tener mayor ingreso.

1.8. OBJETIVOS DEL PROYECTO
1.8.1. OBJETIVO GENERAL
Desarrollar una aplicacin web para realizar pedidos on-line
en la empresa Agrcola Chaves S.A.C
1.8.2. OBJETIVO ESPECIFICO
Disear una pgina web con un ambiente amigable para
facilitar su manejo, satisfaciendo las necesidades de la
empresa y sus usuarios.
Establecer las seguridades necesarias para el acceso de los
usuarios que realizan los pedidos, garantizando la
confiabilidad de los mismos.
Facilitar el proceso de los pedidos a la empresa Agrcola
Chaves S.A.C
Mejorar la calidad de servicio del cliente
Aportar al desarrollo econmico y social de Agrcola Chaves
S.A.C


1.9. LIMITACIONES DEL PROYECTO

1.9.1. LIMITACION CRONOLOGICA
La falta de tiempo por encontrarse cumpliendo otras
responsabilidades como estudiante universitario.

1.9.2. LIMITACION TECNOLOGICA
La falta de un servidor web.
La falta de hosting y dominio.
1.9.3. LIMITACION TECNICA
Falta de conocimiento de los complementos en Lenguajes de
Desarrollo Web.
Falta de conocimiento del motor de base de datos Mysql.



2MARCO TERICO
2. UML

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls,
Unified Modeling Language) es el lenguaje de modelado de sistemas
software ms conocido y utilizado en la actualidad; est respaldado por el
OMG (Object Management Group). Es un lenguaje grfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estndar
para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocio, funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programacin,
esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para
especificar o para describir mtodos o procesos. Se utiliza para definir un
sistema, para detallar los artefactos en el sistema y para documentar y
construir. En otras palabras, es el lenguaje en el que est descrito el
modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para
dar soporte a una metodologa de desarrollo de software (tal como el
Proceso Unificado Racional o RUP), pero no especifica en s mismo qu
metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programacin, solo se


diagrama la realidad de una utilizacin en un requerimiento. Mientras que,
programacin estructurada, es una forma de programar como lo es la
orientacin a objetos, sin embargo, la programacin orientada a objetos
viene siendo un complemento perfecto de UML, pero no por eso se toma
UML slo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.

2.1.1. Estandarizacin de UML
Desde el ao 1995, UML es un estndar aprobado por la ISO
como ISO/IEC 19501:2005 Information technology Open
Distributed Processing Unified Modeling Language (UML)
Versin 1.4.2.

2.1.2. Historia de UML
Antes de UML 1.x
Despus de que la Rational Software Corporation contratara a
James Rumbaugh de General Electric en 1994, la compaa se
convirti en la fuente de los dos esquemas de modelado
orientado a objetos ms populares de la poca: el OMT (Object-
modeling technique) de Rumbaugh, que era mejor para anlisis
orientado a objetos, y el Mtodo Booch de Grady Booch, que era
mejor para el diseo orientado a objetos. Poco despus se les
uni Ivar Jacobson, el creador del mtodo de ingenier de
software orientado a objetos. Jacobson se uni a Rational en
1995, despus de que su compaa Objectory AB fuera
comprada por Rational. Los tres metodologistas eran conocidos
como los Tres Amigos, porque se saba de sus constantes
discusiones sobre las prcticas metodolgicas.



En 1996 Rational concluy que la abundancia de lenguajes de
modelado estaba alentando la adopcin de la tecnologa de objetos,
y para orientarse hacia un mtodo unificado, encargaron a los Tres
Amigos que desarrollaran un Lenguaje Unificado de Modelado
abierto. Se consult con representantes de compaas competidoras
en el rea de la tecnologa de objetos durante la OOPSLA '96;
eligieron cajas para representar clases en lugar de la notacin de
Booch que utilizaba smbolos de nubes.

Bajo la direccin tcnica de los Tres Amigos fue organizado un
consorcio internacional llamado UML Partners en 1996 para
completar las especificaciones del Lenguaje Unificado de Modelado
(UML), y para proponerlo como una respuesta al OMG RFP. El
borrador de la especificacin UML 1.0 de UML Partners fue
propuesto a la OMG en enero de 1997. Durante el mismo mes la
UML Partners form una Fuerza de Tarea Semntica, encabezada
por Cris Kobryn y administrada por Ed Eykholt, para finalizar las
semnticas de la especificacin y para integrarla con otros esfuerzos
de estandarizacin. El resultado de este trabajo, el UML 1.1, fue
presentado ante la OMG en agosto de 1997 y adoptado por la OMG
en noviembre de 1997.

Como notacin de modelado, la influencia de la OMT domina UML
(por ejemplo el uso de rectngulos para clases y objetos). Aunque
se quit la notacin de "nubes" de Booch, si se adopt la capacidad
de Booch para especificar detalles de diseo en los niveles inferiores.
La notacin de Casos de Uso del Objectory y la notacin de
componentes de Booch fueron integradas al resto de la notacin,
pero la integracin semntica era relativamente dbil en UML 1.1, y
no se arregl realmente hasta la revisin mayor de UML 2.0.



Conceptos de muchos otros mtodos OO fueron integrados
superficialmente en UML con el propsito de hacerlo compatible con
todos los mtodos OO. Adems el grupo tom en cuenta muchos
otros mtodos de la poca, con el objetivo de asegurar amplia
cobertura en el dominio de los sistemas en tiempo real. Como
resultado, UML es til en una variedad de problemas de ingeniera,
desde procesos sencillos y aplicaciones de un slo usuario a
sistemas concurrentes y distribuidos.

Por qu nace el UML?
La falta de estandarizacin en la manera de representar
grficamente un modelo, un lenguaje no slo para comunicar las
ideas a otros desarrolladores sino tambin para servir de apoyo en
los procesos de anlisis de un problema. Se cre el Lenguaje
Unificado de Modelado (UML: Unified Modeling Language). UML.

Quines y cmo crearon el UML? El lenguaje UML comenz, cuando
Rumbaugh se uni a la compaa Rational fundada por Booch, para
unificar dos mtodos que haban desarrollado: el mtodo Booch y el
OMT (Object Modelling Tool ). En octubre de 1995, Jacobson, se
uni a Rational y la colaboracin de otras empresas para que
aportaran sus ideas. Condujeron a la definicin de la primera versin
de UML. El 14 de noviembre de 1997 cuando el Grupo Administrador
de Objetos (Object Management Group, OMG) public como
estndar la versin 1.1 del Lenguaje Unificado de Modelado (Unified
Modeling Language, UML)

En qu se centra el UML? UML es un lenguaje, que proporciona
un vocabulario y unas reglas para permitir una comunicacin. En
este caso, este lenguaje se centra en la representacin grfica de un
sistema. Se puede aplicar en el desarrollo de software entregando
gran variedad de formas para dar soporte a una metodologa de


desarrollo de software (tal como el Proceso Unificado Racional o
RUP), pero no especifica en s mismo qu metodologa o proceso
usar.
Los elementos de UML se clasifican en estructurales (Clases,
interfaces. Colaboraciones, casos de uso, clases activas,
componentes y nodos), de comportamiento (interacciones y
mquinas de estado), de agrupacin (paquetes) y de anotacin
(notas). A su vez, hay cuatro tipos de relaciones: De Dependencia,
de asociacin, de agrupacin y de realizacin. Para construir un
plano de software que tenga sentido, lo que se hace es combinar los
elementos estructurales con sus respectivas relaciones, segn sea el
caso, obteniendo como resultado uno de los nueve diagramas que
existen en UML, a saber: De clases, De objetos, de casos de uso, de
secuencia, de colaboracin, de estados, de actividades, de
componentes y de despliegue.
UML nos indica cmo crear y leer los modelos, pero no dice cmo
crearlos. Esto ltimo es el objetivo de las metodologas de
desarrollo.
Los objetivos de UML son muchos, pero se pueden sintetizar sus
funciones:

Visualizar: UML permite expresar de una forma grfica un
sistema de forma que otro lo puede entender.
Especificar: UML permite especificar cules son las
caractersticas de un sistema antes de su construccin.
Construir: A partir de los modelos especificados se pueden
construir los sistemas diseados.
Documentar: Los propios elementos grficos sirven como
documentacin del sistema desarrollado que pueden servir para
su futura revisin.
Aunque UML est pensado para modelar sistemas complejos con
gran cantidad de software, el lenguaje es los suficientemente


expresivo como para modelar sistemas que no son informticos,
como flujos de trabajo (workflow) en una empresa, diseo de la
estructura de una organizacin y por supuesto, en el diseo de
hardware.
Un modelo UML est compuesto por tres clases de bloques de
construccin:

Elementos: Los elementos son abstracciones de cosas reales o
ficticias (objetos, acciones, etc.)
Relaciones: relacionan los elementos entre s.
Diagramas: Son colecciones de elementos con sus relaciones.

Un Diagrama es la representacin grfica de un conjunto de
elementos con sus relaciones. UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas.

Los Diagramas de Estructura enfatizan en los elementos que
deben existir en el sistema modelado.

Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta
Diagrama de despliegue
Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe
suceder en el sistema modelado.

Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados


Los Diagramas de Interaccin son un subtipo de diagramas de
comportamiento, que enfatiza sobre el flujo de control y de datos
entre los elementos del sistema modelado.

Diagrama de secuencia
Diagrama de comunicacin, que es una versin simplificada
del Diagrama de colaboracin
Diagrama de tiempos
Diagrama global de interacciones o Diagrama de vista de
interaccin



2.2. PROCESO UNIFICADO PARA DESARROLLO DE SOFTWARE (RUP)
2.2.1. Generalidades y aportes:
Proceso de desarrollo propuesto por Rational Software
Corporation resultado del esfuerzo de las tres ltimas dcadas
en desarrollo de software y de la experiencia desus creadores
Ivar Jacobson, Grady Booch y James Rumbaugh.
2. Orgenes
El antecedente ms importante lo ubicamos en 1967 con la
Metodologa Ericsson (Ericsson Approach), sta es una
aproximacin de desarrollo basada en componentes, que
introdujo el concepto de caso de uso; entre los aos de 1987 a
1995 Jacobson funda la compaa Objectory AB y lanza el
proceso de desarrollo Objectory (abreviacin de Object Factory),
posteriormente en 1995 Rational Software Corporation
adquiere Objectory AB y es entre 1995 y 1997 que se
desarrolla Rational Objectory Process (ROP) fruto del
encuentro y evolucin de Objectory 3.8 y la Metodologa Rational
(Rational Approach) que adopta por primera vez UML como
lenguaje de modelamiento.
A principios de los noventas, la guerra de los mtodos hizo
evidente la necesidad de unificar criterios, es as como Grady
Booch autor del mtodo Booch y James Rumbaugh(desarrollador
para General Electric) se unieron en Rational en 1994, despus
en 1995 se une Jacobson y gracias al esfuerzo de varias
compaas y metodologistas evolucion UML hasta ser un
estndar en 1997, el cual es adoptado en todos los modelos del
ROP. Desde ese entonces y a la cabeza de Booch, Jacobson y
Rumbaugh, Rational ha desarrollado e incorporado diversos
elementos para expandir el ROP, destacndose especialmente el


flujo de trabajo conocido como modelamiento del negocio, es as
como en junio del 1998 se lanza Rational Unified Process 5.0
evolucionado hasta el momento de elaboracin de este
documento bajo el nombre de RUP.

2.2.2. Caractersticas principales
a.) Guiado/Manejado por casos de uso: La razn de ser de
un sistema software es servir a usuarios ya sean humanos u
otros sistemas; un caso de uso es una facilidad que el software
debe proveer a sus usuarios. Los casos de uso reemplazan la
antigua especificacin funcional tradicional y constituyen la gua
fundamental establecida para las actividades a realizar durante
todo el proceso de desarrollo incluyendo el diseo, la
implementacin y las pruebas del sistema.
b.) Centrado en arquitectura: La arquitectura involucra los
elementos ms significativos del sistema y est influenciada
entre otros por plataformas software, sistemas operativos,
manejadores de bases de datos, protocolos, consideraciones de
desarrollo como sistemas heredados y requerimientos no
funcionales. Los casos de uso guan el desarrollo de la
arquitectura y la arquitectura se realimenta en los casos de uso,
los dos juntos permiten conceptualizar, gestionar y desarrollar
adecuadamente el software.
c.) Iterativo e Incremental: Para hacer ms manejable un
proyecto se recomienda dividirlo en ciclos. Para cada ciclo se
establecen fases de referencia, cada una de las cuales debe ser
considerada como un miniproyecto cuyo ncleo fundamental


est constituido por una o ms iteraciones de las actividades
principales bsicas de cualquier proceso de desarrollo.
d.) Desarrollo basado en componentes: La creacin de
sistemas intensivos en software requiere dividir el sistema en
componentes con interfaces bien definidas, que posteriormente
sern ensamblados para generar el sistema. Esta caracterstica
en un proceso de desarrollo permite que el sistema se vaya
creando a medida que se obtienen o que se desarrollan y
maduran sus componentes.
e.) Utilizacin de un nico lenguaje de modelamiento:
UML es adoptado como nico lenguaje de modelamiento para el
desarrollo de todos los modelos.
f.) Proceso Integrado: Se establece una estructura que
abarque los ciclos, fases, flujos de trabajo, mitigacin de riesgos,
control de calidad, gestin del proyecto y control de
configuracin; el proceso unificado establece una estructura que
integra todas estas facetas. Adems esta estructura cubre a los
vendedores y desarrolladores de herramientas para soportar la
automatizacin del proceso, soportar flujos individuales de
trabajo, para construir los diferentes modelos e integrar el
trabajo a travs del ciclo de vida y a travs de todos los
modelos.
2.2.3. Modelo de Referencia Organizacional
Esta metodologa propone un modelo para la organizacin de
personal que se resume en la siguiente tabla.
CARGOS/POSICIONES TAREAS ASIGNADAS
Gestor del proyecto Establecer Condiciones de Trabajo


Analista del sistema
Encontrar Actores y Casos de Uso
Estructurar el Modelo de Casos de Uso
Arquitecto del sistema
Priorizar los Casos de Uso
Efectuar el Anlisis Arquitectural
Efectuar el Diseo Arquitectural
Efectuar la Implementacin
Arquitectural
Especificador de casos
de uso
Detallar un Caso de Uso
Diseador de interfaz
de usuario
Prototipar una Interfaz de Usuario
Ingeniero de casos de
uso
Analizar un Caso de Uso
Disear un Caso de Uso
Ingeniero de
componentes
Analizar una Clase
Analizar un Paquete
Disear una Clase
Disear un Subsistema
Implementar un Subsistema
Implementar una Clase
Realizar una Prueba de Unidad
Implementar una Prueba
Integrador del sistema Integrar el Sistema


Ingeniero de pruebas
Planear las Pruebas
Disear las Pruebas
Evaluar las Pruebas
Verificador de integracin Realizar una Prueba de Integracin
Verificador del sistema Realizar las Pruebas del Sistema
Conformacin del equipo humano de un proyecto segn RUP
2.2.4. Fases en el ciclo de Desarrollo
Este proceso de desarrollo considera que cualquier desarrollo de
un sistema software debe pasar por cuatro fases que se
describirn a continuacin, la figura 2 muestra las fases de
desarrollo y los diversos flujos de trabajo involucrados dentro de
cada fase con una representacin grfica en cual de los flujos se
hace mayor nfasis segn la fase, cabe destacar el flujo de
trabajo concerniente al negocio.

Figura 2.1 Proceso Unificado Rational
Fase 1: Preparacin Inicial (Inception)


Su objetivo principal es establecer los objetivos para el ciclo del vida
del producto. En esta fase se establece el caso del negocio con el fin
de delimitar el alcance del sistema, saber qu se cubrir y delimitar
el alcance del proyecto.
Fase 2: Preparacin Detallada (Elaboration)
Su objetivo principal es plantear la arquitectura para el ciclo de vida
del producto. En esta fase se realiza la captura de la mayor parte de
los requerimientos funcionales, manejando los riesgos que
interfieran con los objetivos del sistema, acumulando la informacin
necesaria para el plan de construccin y obteniendo suficiente
informacin para hacer realizable el caso del negocio.
Fase 3: Construccin (Construction)
Su objetivo principal es alcanzar la capacidad operacional del
producto. En esta fase a travs de sucesivas iteraciones e
incrementos se desarrolla un producto software, listo para operar,
ste es frecuentemente llamado versin beta.
Fase 4: Transicin (Transition)
Su objetivo principal es realizar la entrega del producto operando,
una vez realizadas las pruebas de aceptacin por un grupo
especial de usuarios y habiendo efectuado los ajustes y
correcciones que sean requeridos.
2.2.5. Subproductos
La tabla 2 muestra los subproductos (denominados en RUP
artifacts (artefactos)) claves de cada una de las fases de
desarrollo.
FASE Subproductos


PREPARACIN INICIAL
1.- Alcance del Sistema
1.- Lista de Caractersticas
2.- Modelo del Dominio o Modelo del
Negocio (1. versin)
3.- Modelo de Casos de Uso, Modelo de
Anlisis y Modelo de Diseo (1. versin)
4.- Requerimientos Suplementarios (1.
Versin)
2.- Arquitectura Inicial (propuesta)
3.- Lista Inicial de Riesgos (riesgos crticos
ms importantes) y Lista Priorizada de los
Casos de Uso
4.- Prototipo para Validacin de Conceptos
(prototipo de descarte)
5.- Entorno de Desarrollo Configurado
(proceso y herramientas) (configuracin
inicial)
6.- Plan Inicial del Proyecto
7.- Caso Inicial del Negocio (1. versin)
(contexto del negocio y criterios de xito)
(costo, tiempos,
calidad, utilidades)
PREPARACIN
DETALLADA
1.- Contexto del Sistema (Modelo del
Dominio o Modelo del Negocio
preferiblemente


completo)
2.- Captura del 80% de los Requerimientos
Funcionales
1.- Modelo de Casos de Uso (aprox. el
80%) y Modelo de Anlisis (realizacin de
los casos de uso ms significativos)
2.- Modelo de Diseo, Modelo de
Despliegue y Modelo de Implementacin
(menos
del 10%)
3.- Niveles para los Atributos de Calidad y
Requerimientos Suplementarios
Actualizados
4.- Manual Preliminar de Usuario
3.- Arquitectura de Referencia (lnea de
base) (descripcin de las vistas
arquitecturales
de los modelos del sistema)
4.- Lista Actualizada de Riesgos (crticos y
significativos) y Riesgos Crticos Mitigados
5. Plan del Proyecto para las fases de
Construccin y Transicin
6. Entorno de Desarrollo Adecuado
(proceso y herramientas)
7. Caso del Negocio Completo (y Contrato


o declaracin del negocio)

CONSTRUCCIN
1.- Modelos Completos (Casos de Uso,
Anlisis, Diseo, Despliegue e
Implementacin)
2.- Arquitectura ntegra (mantenida y
mnimamente actualizada)
3.- Riesgos Presentados Mitigados
4.- Plan del Proyecto para la fase de
Transicin
5.- Manual Inicial de Usuario (con suficiente
detalle)
6.- Prototipo Operacional beta
7.- Caso del Negocio Actualizado
TRANSICIN
1.- Prototipo Operacional
2.- Documentos Legales
3.- Caso del Negocio Completo
4.- Lnea de Base del Producto completa y
corregida que incluye todos los modelos del
sistema
5.- Descripcin de la Arquitectura completa
y corregida
6.- Manuales para Usuario Final, Operador
y Administrador del Sistema, y Materiales


para Entrenamiento



2.3. MODELO VISTA CONTROLADOR
Modelo Vista Controlador (MVC) es un patrn o modelo de abstraccin de
desarrollo de software que separa los datos de una aplicacin, la interfaz de
usuario, y la lgica de negocio en tres componentes distintos. El patrn de
llamada y retorno MVC (segn CMU), se ve frecuentemente en aplicaciones
web, donde la vista es la pgina HTML y el cdigo que provee de datos
dinmicos a la pgina. El modelo es el Sistema de Gestin de Base de Datos
y la Lgica de negocio, y el controlador es el responsable de recibir los
eventos de entrada desde la vista.

Figura 2.2: Modelo - Vista - Controlador
2.3.1. Descripcin del patrn
2.3.1.1. Modelo:
Esta es la representacin especfica de la informacin con
la cual el sistema opera. En resumen, el modelo se limita
a lo relativo de la vista y su controlador facilitando las
presentaciones visuales complejas. El sistema tambin
puede operar con ms datos no relativos a la
presentacin, haciendo uso integrado de otras lgicas de
negocio y de datos afines con el sistema modelado.



2.3.1.2. Vista:
Este presenta el modelo en un formato adecuado para
interactuar, usualmente la interfaz de usuario.
2.3.1.3. Controlador:
Este responde a eventos, usualmente acciones del
usuario, e invoca peticiones al modelo y, probablemente,
a la vista.
Muchos de los sistemas informticos utilizan un Sistema
de Gestin de Base de Datos para gestionar los datos: en
lneas generales del MVC corresponde al modelo. La
unin entre capa de presentacin y capa de negocio
conocido en el paradigma de la Programacin por capas
representara la integracin entre Vista y su
correspondiente Controlador de eventos y acceso a
datos, MVC no pretende discriminar entre capa de
negocio y capa de presentacin pero si pretende separar
la capa visual grfica de su correspondiente
programacin y acceso a datos, algo que mejora el
desarrollo y mantenimiento de la Vista y el Controlador
en paralelo, ya que ambos cumplen ciclos de vida muy
distintos entre s.
Aunque se pueden encontrar diferentes
implementaciones de MVC, el flujo que sigue el control
generalmente es el siguiente:
El usuario interacta con la interfaz de usuario de alguna
forma (por ejemplo, el usuario pulsa un botn, enlace,
etc.)
El controlador recibe (por parte de los objetos de la
interfaz-vista) la notificacin de la accin solicitada por el
usuario. El controlador gestiona el evento que llega,


frecuentemente a travs de un gestor de eventos
(handler) o callback.
El controlador accede al modelo, actualizndolo,
posiblemente modificndolo de forma adecuada a la
accin solicitada por el usuario (por ejemplo, el
controlador actualiza el carro de la compra del usuario).
Los controladores complejos estn a menudo
estructurados usando un patrn de comando que
encapsula las acciones y simplifica su extensin.
El controlador delega a los objetos de la vista la tarea de
desplegar la interfaz de usuario. La vista obtiene sus
datos del modelo para generar la interfaz apropiada para
el usuario donde se reflejan los cambios en el modelo
(por ejemplo, produce un listado del contenido del carro
de la compra). El modelo no debe tener conocimiento
directo sobre la vista. Sin embargo, se podra utilizar el
patrn Observador para proveer cierta indireccin entre
el modelo y la vista, permitiendo al modelo notificar a los
interesados de cualquier cambio. Un objeto vista puede
registrarse con el modelo y esperar a los cambios, pero
aun as el modelo en s mismo sigue sin saber nada de la
vista. Este uso del patrn Observador no es posible en las
aplicaciones Web puesto que las clases de la vista estn
desconectadas del modelo y del controlador. En general
el controlador no pasa objetos de dominio (el modelo) a
la vista aunque puede dar la orden a la vista para que se
actualice. Nota: En algunas implementaciones la vista no
tiene acceso directo al modelo, dejando que el
controlador enve los datos del modelo a la vista. Por
ejemplo en el MVC usado por Apple en su framework


Cocoa. Suele citarse como Modelo-Interface-Control, una
variacin del MVC ms puro.
2.4. GESTOR DE BASE DE DATOS - MySQL
MySQL es un sistema de gestin de bases de datos relacional, multihilo y
multiusuario con ms de seis millones de instalaciones.1 MySQL AB desde
enero de 2008 una subsidiaria de Sun Microsystems y sta a su vez de
Oracle Corporation desde abril de 2009 desarrolla MySQL como software
libre en un esquema de licenciamiento dual.
Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con
esta licencia, pero para aquellas empresas que quieran incorporarlo en
productos privativos deben comprar a la empresa una licencia especfica
que les permita este uso. Est desarrollado en su mayor parte en ANSI C.
Al contrario de proyectos como Apache, donde el software es desarrollado
por una comunidad pblica y los derechos de autor del cdigo estn en
poder del autor individual, MySQL es patrocinado por una empresa privada,
que posee el copyright de la mayor parte del cdigo.
Esto es lo que posibilita el esquema de licenciamiento anteriormente
mencionado. Adems de la venta de licencias privativas, la compaa ofrece
soporte y servicios. Para sus operaciones contratan trabajadores alrededor
del mundo que colaboran va Internet. MySQL AB fue fundado por David
Axmark, Allan Larsson y Michael Widenius.
Lenguajes de programacin que acceden a MySQL
Existen varias interfaces de programacin de aplicaciones que permiten, a
aplicaciones escritas en diversos lenguajes de programacin, acceder a las
bases de datos MySQL, incluyendo C, C++, C#, Pascal, Delphi (via
dbExpress), Eiffel, Smalltalk, Java (con una implementacin nativa del
driver de Java), Lisp, Perl, PHP, Python, Ruby,Gambas, REALbasic (Mac y
Linux), (x)Harbour (Eagle1), FreeBASIC, y Tcl; cada uno de estos utiliza una
interfaz de programacin de aplicaciones especfica. Tambin existe una


interfaz ODBC, llamado MyODBC que permite a cualquier lenguaje de
programacin que soporte ODBC comunicarse con las bases de datos
MySQL. Tambin se puede acceder desde el sistema SAP, lenguaje ABAP.
Aplicaciones
MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en
plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por
herramientas de seguimiento de errores como Bugzilla. Su popularidad
como aplicacin web est muy ligada a PHP, que a menudo aparece en
combinacin con MySQL.
MySQL es una base de datos muy rpida en la lectura cuando utiliza el
motor no transaccional MyISAM, pero puede provocar problemas de
integridad en entornos de alta concurrencia en la modificacin. En
aplicaciones web hay baja concurrencia en la modificacin de datos y en
cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL
ideal para este tipo de aplicaciones. Sea cual sea el entorno en el que va a
utilizar MySQL, es importante monitorizar de antemano el rendimiento para
detectar y corregir errores tanto de SQL como de programacin.
Versiones de MySQL

Figura 2.3: Versiones de MySql


Caractersticas
Inicialmente, MySQL careca de elementos considerados esenciales en las
bases de datos relacionales, tales como integridad referencial y
transacciones. A pesar de ello, atrajo a los desarrolladores de pginas web
con contenido dinmico, justamente por su simplicidad.
Poco a poco los elementos de los que careca MySQL estn siendo
incorporados tanto por desarrollos internos, como por desarrolladores de
software libre. Entre las caractersticas disponibles en las ltimas versiones
se puede destacar:
Amplio subconjunto del lenguaje SQL. Algunas extensiones son
incluidas igualmente.
Disponibilidad en gran cantidad de plataformas y sistemas.
Posibilidad de seleccin de mecanismos de almacenamiento que
ofrecen diferente velocidad de operacin, soporte fsico, capacidad,
distribucin geogrfica, transacciones...
Transacciones y claves forneas.
Conectividad segura.
Replicacin.
Bsqueda e indexacin de campos de texto.
MySQL es un sistema de administracin de bases de datos. Una base de
datos es una coleccin estructurada de tablas que contienen datos. Esta
puede ser desde una simple lista de compras a una galera de pinturas o el
vasto volumen de informacin en una red corporativa. Para agregar,
acceder a y procesar datos guardados en un computador, usted necesita un
administrador como MySQL Server. Dado que los computadores son muy
buenos manejando grandes cantidades de informacin, los administradores
de bases de datos juegan un papel central en computacin, como
aplicaciones independientes o como parte de otras aplicaciones.
MySQL es un sistema de administracin relacional de bases de datos. Una
base de datos relacional archiva datos en tablas separadas en vez de


colocar todos los datos en un gran archivo. Esto permite velocidad y
flexibilidad. Las tablas estn conectadas por relaciones definidas que hacen
posible combinar datos de diferentes tablas sobre pedido.
MySQL es software de fuente abierta. Fuente abierta significa que es
posible para cualquier persona usarlo y modificarlo. Cualquier persona
puede bajar el cdigo fuente de MySQL y usarlo sin pagar. Cualquier
interesado puede estudiar el cdigo fuente y ajustarlo a sus necesidades.
MySQL usa el GPL (GNU General Public License) para definir qu puede
hacer y qu no puede hacer con el software en diferentes situaciones. Si
usted no se ajusta al GPL o requiere introducir cdigo MySQL en
aplicaciones comerciales, usted puede comprar una versin comercial
licenciada.
2.5. HTML
HTML, siglas de HyperText Markup Language (lenguaje de marcado de
hipertexto), hace referencia al lenguaje de marcado predominante para la
elaboracin de pginas web que se utiliza para describir y traducir la
estructura y la informacin en forma de texto, as como para complementar
el texto con objetos tales como imgenes. El HTML se escribe en forma de
etiquetas, rodeadas por corchetes angulares (<,>). HTML tambin puede
describir, hasta un cierto punto, la apariencia de un documento, y puede
incluir un script (por ejemplo JavaScript), el cual puede afectar el
comportamiento de navegadores web y otros procesadores de HTML.
HTML tambin sirve para referirse al contenido del tipo de MIME text/html o
todava ms ampliamente como un trmino genrico para el HTML, ya sea
en forma descendida del XML (como XHTML 1.0 y posteriores) o en forma
descendida directamente de SGML (como HTML 4.01 y anteriores).
2.6. PHP
PHP es un lenguaje de programacin de uso general de script del lado del
servidor originalmente diseado para el desarrollo web de contenido


dinmico. Fue uno de los primeros lenguajes de programacin del lado del
servidor que se podan incorporar directamente en el documento HTML en
lugar de llamar a un archivo externo que procese los datos. El cdigo es
interpretado por un servidor web con un mdulo de procesador de PHP que
genera la pgina Web resultante. PHP ha evolucionado por lo que ahora
incluye tambin una interfaz de lnea de comandos que puede ser usada en
aplicaciones grficas independientes. PHP puede ser usado en la mayora de
los servidores web al igual que en casi todos los sistemas operativos y
plataformas sin ningn costo.
PHP fue creado originalmente por Rasmus Lerdorf en 1995. Actualmente el
lenguaje sigue siendo desarrollado con nuevas funciones por el grupo PHP.
Este lenguaje forma parte del software libre publicado bajo la licencia PHP
que es incompatible con la Licencia Pblica General de GNU debido a las
restricciones del uso del trmino PHP.
2.7. CODEIGNATER
Codeignater es un framework para desarrollo de aplicaciones en PHP, es
Open Source, muy pequeo (por lo menos comparndolo con Zend) y
posee un acceso a sus libreras bien estructurado.
Es liviano y fcil de instalar ya que slo hay que descomprimirlo y copiarlo
en una carpeta del servidor.
Llevo u|sndolo un tiempo y la verdad es que es bastante fcil de aprender
y de familiarizarse con el concepto que propone. Creo que en verdad facilita
mucho los desarrollos, ya que permite concentrarse en el problema,
evitando as tener que volver a escribir una y otra vez lo mismo.
Entre las cosas que ms me gustan figuran: como se estructura la
aplicacin y el manejo de la base de datos (includo scaffolding).



2.8. CSS
El nombre hojas de estilo en cascada viene del ingls Cascading Style
Sheets, del que toma sus siglas. CSS es un lenguaje usado para definir la
presentacin de un documento estructurado escrito en HTML o XML2 (y por
extensin en XHTML). El W3C (World Wide Web Consortium) es el
encargado de formular la especificacin de las hojas de estilo que servirn
de estndar para los agentes de usuario o navegadores.
La idea que se encuentra detrs del desarrollo de CSS es separar la
estructura de un documento de su presentacin.
La informacin de estilo puede ser adjuntada como un documento separado
o en el mismo documento HTML. En este ltimo caso podran definirse
estilos generales en la cabecera del documento o en cada etiqueta
particular mediante el atributo "<style>".
Niveles e Historia
CSS se ha creado en varios niveles y perfiles. Cada nivel de CSS se
construye sobre el anterior, generalmente aadiendo funciones al previo.
Los perfiles son, generalmente, parte de uno o varios niveles de CSS
definidos para un dispositivo o interfaz particular. Actualmente, pueden
usarse perfiles para dispositivos mviles, impresoras o televisiones.
CSS1
La primera especificacin oficial de CSS, recomendada por la W3C fue
CSS1, publicada en diciembre 1996,5 y abandonada en abril de 2008.
Algunas de las funcionalidades que ofrece son:
Propiedades de las Fuente, como tipo, tamao, nfasis...
Color de texto, fondos, bordes u otros elementos.
Atributos del texto, como espaciado entre palabras, letras, lneas,
etctera.


Alineacin de textos, imgenes, tablas u otros.
Propiedades de caja, como margen, borde, relleno o espaciado.
Propiedades de identificacin y presentacin de listas.
CSS2
La especificacin CSS2 fue desarrollada por la W3C y publicada como
recomendacin en mayo de 1998, y abandonada en abril de 2008.
Como ampliacin de CSS1, se ofrecieron, entre otras:
las funcionalidades propias de las capas (<div>) como de posicionamiento
relativo/absoluto/fijo, niveles (z-index), etctera. El concepto de "media
types", soporte para las hojas de estilo auditivas texto bidireccional,
sombras, etctera.
CSS 2.1
La primera revisin de CSS2, usualmente conocida como "CSS 2.1", corrige
algunos errores encontrados en CSS2, elimina funcionalidades poco
soportadas o inoperables en los navegadores y aade alguna nueva
especificacin.
De acuerdo al sistema de estandarizacin tcnica de las especificaciones,
CSS2.1 tuvo el estatus de "candidato" (candidate recommendation) durante
varios aos, pero la propuesta fue rechazada en junio de 2005; en junio de
2007 fue propuesta una nueva versin candidata, y sta actualizada en
2009, pero en diciembre de 2010 fue nuevamente rechazada.
En abril de 2011, CSS 2.1 volvi a ser propuesta como candidata, y despus
de ser revisada por el W3C Advisory Committee, fue finalmente publicada
como recomendacin oficial el 7 de junio de 2011.1



CSS3
A diferencia de CSS2, que fue una gran especificacin que defina varias
funcionalidades, CSS3 est dividida en varios documentos separados,
llamados "mdulos".
Cada mdulo aade nuevas funcionalidades a las definidas en CSS2, de
manera que se preservan las anteriores para mantener la compatibilidad.
Los trabajos en el CSS3, comenzaron a la vez que se public la
recomendacin oficial de CSS2, y los primeros borradores de CSS3 fueron
liberados en junio de 1999.
Debido a la modularizacin del CSS3, diferentes mdulos pueden
encontrarse en diferentes estadios de su desarrollo,10 de forma que a
fechas de noviembre de 2011, hay alrededor de cincuenta mdulos
publicados, tres de ellos se convirtieron en recomendaciones oficiales de la
W3C en 2011: "Selectores", "Espacios de nombres" y "Color".
Algunos mdulos, como "Fondos y colores", "Consultas de medios" o
"Diseos multicolumna" estn en fase de "candidatos", y considerados
como razonablemente estables, a finales de 2011, y sus implementaciones
en los diferentes navegadores son sealadas con los prefijos del motor del
mismo.
2.9. JQUERY
jQuery es una biblioteca de JavaScript, creada inicialmente por John Resig,
que permite simplificar la manera de interactuar con los documentos HTML,
manipular el rbol DOM, manejar eventos, desarrollar animaciones y
agregar interaccin con la tcnica AJAX a pginas web. Fue presentada el
14 de enero de 2006 en el BarCamp NYC.
jQuery es software libre y de cdigo abierto, posee un doble licenciamiento
bajo la Licencia MIT y la Licencia Pblica General de GNU v2, permitiendo
su uso en proyectos libres y privativos. jQuery, al igual que otras


bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que
de otra manera requeriran de mucho ms cdigo, es decir, con las
funciones propias de esta biblioteca se logran grandes resultados en menos
tiempo y espacio.
Las empresas Microsoft y Nokia anunciaron que incluirn la biblioteca en
sus plataformas. Microsoft la aadir en su IDE Visual Studio3 y la usar
junto con los frameworks ASP.NET AJAX y ASP.NET MVC, mientras que
Nokia los integrar con su plataforma Web Run-Time.
Caractersticas
Seleccin de elementos DOM.
Interactividad y modificaciones del rbol DOM, incluyendo soporte
para CSS 1-3 y un plugin bsico de XPath.
Eventos.
Manipulacin de la hoja de estilos CSS.
Efectos y animaciones.
Animaciones personalizadas.
AJAX.
Soporta extensiones.
Utilidades varias como obtener informacin del navegador, operar
con objetos y vectores, funciones para rutinas comunes, etc.
Compatible con los navegadores Mozilla Firefox 2.0+, Internet
Explorer 6+, Safari +, Opera 10.6+ y Google Chrome 8+.
2.10. AJAX
AJAX, acrnimo de Asynchronous JavaScript And XML (JavaScript asncrono
y XML), es una tcnica de desarrollo web para crear aplicaciones
interactivas o RIA (Rich Internet Applications). Estas aplicaciones se
ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se
mantiene la comunicacin asncrona con el servidor en segundo plano. De
esta forma es posible realizar cambios sobre las pginas sin necesidad de


recargarlas, lo que significa aumentar la interactividad, velocidad y
usabilidad en las aplicaciones.
Ajax es una tecnologa asncrona, en el sentido de que los datos adicionales
se solicitan al servidor y se cargan en segundo plano sin interferir con la
visualizacin ni el comportamiento de la pgina. JavaScript es el lenguaje
interpretado (scripting language) en el que normalmente se efectan las
funciones de llamada de Ajax mientras que el acceso a los datos se realiza
mediante XMLHttpRequest, objeto disponible en los navegadores actuales.
En cualquier caso, no es necesario que el contenido asncrono est
formateado en XML.
Ajax es una tcnica vlida para mltiples plataformas y utilizable en muchos
sistemas operativos y navegadores dados que est basado en estndares
abiertos como JavaScript y Document Object Model (DOM).



3APLICACIN DE LA METODOLOGIA
3. MODELO DEL NEGOCIO:
3.1.1. PICTOGRAMA:
3.1.1.1. PICTOGRAMA: VENTA AL CONTADO

Figura 3.1: Pictograma-Venta al Contado



3.1.1.2. PICTOGRAMA: VENTA A CREDITO

Figura 3.2: Pictograma-Venta a Crdito
3.1.2. PROCESOS DE NEGOCIO
Gestionar ventas
Venta al contado
- Cliente
- Vendedor
- Cajera
- Almacenero

El Cliente realiza el pedido de los productos, el vendedor le
realiza una proforma estableciendo un precio y las
cantidades, el vendedor elabora la boleta o factura y recibir
el dinero, entregando junto a la boleta/ factura a la cajera,
quien verificara el dinero, Estando conforme el pago
entregara la boleta al vendedor para solicitar al almacenero
se atienda el pedido, El almacenero, entrega los productos al


vendedor, verificando lo solicitado. Concluida la verificacin
se entregara la boleta/factura al cliente

Venta a crdito
- Cliente
- Vendedor
- Gerente
- Almacenero

El vendedor primero solicitara autorizacin y plazo de crdito
a Gerencia y de ser aprobado el crdito, elaborara para evitar
errores una proforma, estando conforme el cliente con los
productos a atender se proceder a llenar la Gua de Crdito
con los datos del cliente y productos a despachar; el
vendedor proceder a solicitar al almacenero se atienda el
pedido. El almacenero, entrega los productos al vendedor,
verificando lo solicitado. Concluida la verificacin en el
documento de crdito, el cliente en seal de conformidad
firmara, y debajo de su rbrica deber poner nombre y
apellido completo y DNI.

3.1.3. REGLAS DEL NEGOCIO

- Venta es al contado y al crdito
- En la venta al crdito de acuerdo al tipo de cliente le
corresponde tipo de crdito distinto
- Existes devoluciones de productos
- Los agroqumicos tienen 2% de inters y los fertilizantes 3%
- Hay productos que tienen IGV y otros que son libres al IGV
- Se verifica el lmite de crdito antes de conceder una venta al
crdito
- Cuando se cancela las ventas de crditos se hace el page por
una boleta o una factura correspondiente

3.1.4. VISIN DEL NEGOCIO
VISION
Ser reconocidos en el mercado como una empresa cuyos
productos son de calidad superior.
Aspiramos satisfacer la necesidad de nuestros clientes
con productos y servicios de la ms alta calidad para
consolidarnos como su primera opcin.


Convertirnos en el mediano plazo en una de los
principales distribuidores de productos qumicos agrcolas
en el norte de chico.

MISION
Consolidar y mantener el liderazgo en cada uno de los
mercados en los que participamos a travs de la
produccin y comercializacin de lneas de productos que
garanticen un valor agregado para nuestros clientes.
Proporcionar la satisfaccin de las necesidades reales de
los consumidores.
Nos hemos propuesto superar los niveles de calidad
actuales en el rubro en el cual nos desempeamos para
beneficio de nuestros clientes, trabajadores y adems de
esta manera con el proceso de desarrollo del Per.

3.1.5. MODELO DE CASO DE USO DEL NEGOCIO

Figura 3.3: Diagrama de Caso de Uso del Negocio



3.1.6. ESPECIFICACIN DE CASOS DE USO DEL NEGOCIO
GESTIONAR VENTA
VENTA AL CONTADO:
1 El vendedor, atiende al cliente y con la finalidad de evitar
errores primero le hace una proforma, acordado precio y cantidad
de productos, recin se procede hacer la boleta o factura.

2 Acordado la venta si es al contado el vendedor emitir la boleta o
factura y recibir el dinero, entregando junto a la boleta/ factura a la
cajera, quien verificara el dinero,
Estando conforme el pago entregara la boleta al vendedor para
solicitar al almacenero se atienda el pedido.

3 El almacenero, entrega los productos al vendedor, verificando lo
solicitado, y solicita la conformidad de DESPACHO, de parte de uno
de los responsables en orden de prioridades:

1.- KARLA AMAYA ALVARADO
2.- BRAYAN AMAYA ALVARADO
3.- ARTURO HUAMAN ALVARADO

4 concluida la verificacin se entregara la boleta/factura al cliente

5 si la venta es adelantada adicionalmente se le entregara el
documento: Vale para entregar mercadera, nico documento de
reclamo de mercadera.

VENTA A CREDITO:
1 El vendedor primero solicitara autorizacin y plazo de crdito a
Gerencia y de ser aprobado el crdito, elaborara para evitar errores
una proforma, estando conforme el cliente con los productos a
atender se proceder a llenar la Gua de Crdito con los datos del
cliente y productos a despachar; el vendedor proceder a solicitar al
almacenero se atienda el pedido.



2 El almacenero, entrega los productos al vendedor, verificando lo
solicitado, y solicita la conformidad de DESPACHO, de parte de uno
de los responsables en orden de prioridades:

1.- KARLA AMAYA ALVARADO
2.- BRAYAN AMAYA ALVARADO
3.- ARTURO HUAMAN ALVARADO

3 concluida la verificacin en el documento de crdito, el cliente en
seal de conformidad firmara, y debajo de su rbrica deber poner
nombre y apellido completo y DNI.

3.1.7. DIAGRAMA DE ACTIVIDAD POR CADA USO DEL
NEGOCIO

Venta al contado



Venta al crdito

Figura 3.4: Diagrama de Actividad - Gestionar Venta



3.1.8. MODELO DE OBJETO DEL NEGOCIO
MODELO DE OBJETO DEL NEGOCIO GESTIONAR VENTA

Figura 3.5: Modelo de Objeto de Negocio: Gestionar venta

3.1.9. MODELO DE DOMINIO



Figura 3.6: Modelo de Dominio


SISTEMA
3.2. MODELO DE REQUERIMIENTOS
3.2.1. MODELO DE CASO DE USO DE REQUERIMIENTO
DETALLADO
3.2.1.1. GESTIONAR PRODUCTO

Figura 4.1: Diagrama de Caso de Uso detallado: Gestionar Producto

3.2.1.2. GESTIONAR CLIENTE



SISTEMA

Figura 4.2: Diagrama de Caso de Uso detallado: Gestionar Cliente



SISTEMA
GESTIONAR CATLOGO

Figura 4.3: Diagrama de Caso de Uso detallado: Gestionar Catlogo



SISTEMA
3.2.1.3. GESTIONAR PEDIDO

Figura 4.4: Diagrama de Caso de Uso detallado: Gestionar Pedido



3.2.2. DIAGRAMA DE CASO DE USO DE
REQUERIMIENTOS

Figura 4.5:
Diagrama
de Caso de
Uso de
Requerimiento: Gestionar Producto



3.2.3. MATRIZ DE PRIORIZACIN DE CASO DE USOS

N Caso de Uso Rendimiento Frecuencia Importancia Urgencia Prioridad
1 Gestionar Producto 45 Segundos 15 veces/ das Vital Inmediata
2 Gestionar Cliente 40 Segundos 4 veces /da Vital Inmediata
3 Gestionar Catlogo 45 Segundos 20 veces/ da Vital Inmediata
4 Gestionar Pedido 20 Segundos 25 veces/ da Vital Inmediata

Figura 4.6: Tabla de Matriz de Priorizacin



3.2.4. ESPECIFICACION DE CASO DE USOS DE
REQUERIMIENTOS

3.2.4.1. ESPECIFICACION DEL CASO DE USO: GESTIONAR PRODUCTOS
Caso de Uso : Ingresar Nuevo producto
Actores : Administrador
Propsito : Almacenar los datos de nuevos productos
Resumen : El sistema muestra al administrador todas las
caractersticas correspondientes a cada producto.
Luego el Administrador ingresa los datos del
producto que se desea incorporar. Al concluir, el
sistema lo almacena.
Descripcin :

Alternativas:
3a. Si los datos del producto que se desea ingresar no pertenecen al
formato correspondiente se vuelve al paso 2.
5a. Si los datos no han sido ingresados el sistema indicara el error al
administrador por medio de un mensaje

Accin del Actor
1. Este caso de uso comienza cuando el
administrador ingresa al sistema e
indica que desea registrar un nuevo
producto

2. El administrador ingresa los datos del
producto
4. El administrador elige guarda la
informacin ingresada

Respuesta del sistema
3. El sistema valida que los datos del
producto cumplan con el objetivo del
producto al que corresponden
5. El sistema valido que los datos se
hayan ingresado
6. Guardar la informacin


Caso de Uso : Eliminar producto
Actores : Administrador
Propsito : Eliminar los productos que se deseen del sistema
Resumen : El administrador elige el producto que desea
eliminar. Finalmente el sistema elimina los datos
del producto.
Descripcin :

Alternativas:
2a. En el caso del que el producto no exista se realiza el paso 1.

Accin del Actor
1. Este caso de uso comienza cuando
el administrador ingresa al sistema
e indica que quiere eliminar un
producto.

2. El administrador selecciona desde
una lista el producto que desea
eliminar.
3. El sistema verifica que el producto
que se desea eliminar existe.

4. El sistema elimina el producto
seleccionado


Caso de Uso : Modificar datos del producto
Actores : Administrador.
Propsito : Permitir al administrador corregir los datos de un
producto o actualizarlos.
Resumen : El sistema muestra las caractersticas que se
deseen modificar al administrador, este decide que
datos desea cambiar y el sistema guarda los
cambios.

Descripcin :

Alternativas.

3a. Si los datos que se desean ingresar no corresponden al producto
se vuelve al paso1.

5a. Si los datos que se desean ingresar no corresponden al formato
establecido o no han sido efectivamente todos ingresados se vuelve al
paso 4.

Accin del Actor
administrador ingresa al sistema e
indica que quiere modificar un
producto.

2. El administrador elige el producto a
modificar.

4. El administrador elige las
caractersticas del producto que desea
cambiar. Caractersticas tales como:
nombre, marca, descripcin, precio de
venta, estado e imagen del producto.
3. El sistema valida que los datos se
hallan ingresado correspondan al del
producto.

5. El sistema valida que los datos que
se desean modificar correspondan al
formato establecido y que hayan sido
efectivamente ingresados.

6. El sistema guarda los cambios
hechos.


3.2.4.2. ESPECIFICACION DEL CASO DE USO: GESTIONAR CLIENTE
Caso de Uso : Identificar usuario.
Actores : Cliente.
Propsito : Permitir al cliente o administrador identificarse en
el sistema.
Resumen : El usuario para identificarse debe ingresar su mail y
contrasea. El sistema valida los datos ingresados
y, si los datos son correctos el sistema muestra las
opciones que le corresponden de acuerdo a su rol.
Descripcin :

Alternativas.

3a Los datos ingresados: mail y contrasea no estn ingresados
correctamente. Se ejecuta paso 2.

5a: Los datos ingresados, mail y contrasea, no son vlidos. El
sistema enva un mensaje indicando que los datos ingresados no son
correctos. Se ejecuta paso 2.

6a: Pueden ocurrir 2 situaciones: La contrasea ingresada no
corresponde a la persona indicada o el cliente no est registrado en el
sistema. Se notifica lo ocurrido al cliente. Se ejecuta paso 2.

Accin del Actor
1. Este caso de uso se inicia cuando el
usuario decide identificarse en el
sistema.

2. El usuario ingresa su mail,
posteriormente el usuario ingresa la
contrasea.

4. El usuario indica que desea
identificarse.
3. El sistema valida que los datos
ingresados estn correctamente
ingresados.

5. El sistema verifica que la clave
corresponda al mail del usuario.

6. El sistema indica al usuario que est
autenticado y muestra las opciones que
le corresponden, ya sea como cliente o
administrador.


Caso de Uso : Registrar nuevo cliente
Actores : Cliente.
Propsito : Obtener datos del cliente.
Resumen : El sistema muestra un formulario al cliente que
este debe llenar con sus datos personales si lo
desea, posteriormente el cliente ingresa los datos
que se piden y el sistema almacena los datos.
Descripcin :

Alternativas.

3a. Si los datos ingresados no son vlidos se vuelve al paso 2.

4a. Si el cliente no acepta el envo de sus datos se vuelve al paso 1.

Accin del Actor
el cliente ingresa al sistema y desea
ingresar sus datos en un formulario.

2. El cliente ingresa los siguientes
datos al sistema: sexo, nombre,
apellido direccin, e-mail, fecha
nacimiento, cdigo postal, poblacin,
pas y telfono.

4. El cliente acepta el envo de sus
datos.
3. El sistema valida que todos los datos
hayan sido ingresados y que cumplan
con el formato que acepta el sistema.

5. El sistema almacena los datos del
cliente.


Caso de Uso : Modificar datos del cliente.

Actores : Cliente.

Propsito : Modificar los datos que el cliente desee.

Resumen : El sistema muestra al cliente un formulario con
sus datos, el cliente cambia los datos que desee
de ese formulario. Finalmente los datos
modificados se almacenan.

Descripcin :

Alternativas.

3a. Si los datos no son del formato correcto entonces se ejecuta el
paso 2.

4a. Si el cliente no ingresa todos los datos requeridos se muestra un
mensaje y se ejecuta el paso 2.

Accin del Actor
cliente ingresa al sistema y desea
modificar sus datos.

2. El cliente ingresa los datos que desea
modificar estos pueden ser: sexo,
nombre, apellido direccin, e-mail,
fecha nacimiento, cdigo postal,
poblacin, pas o telfono.

5. El cliente acepta la modificacin de
los datos.
3. El sistema valida que los datos
tengan el formato correcto de
caracteres.

4. El sistema valida que se ingresen
todos los datos que son obligatorios:
datos personales, datos postales,
contrasea.

6. El sistema almacena los datos
modificados.


Caso de Uso : Cambiar contrasea.

Actores : Cliente.

Propsito : Permitir al cliente que cambie su contrasea.

Resumen : El sistema entrega la posibilidad al cliente de
cambiar su contrasea actual por una nueva,
luego que el cliente cambie su contrasea esta
quedar almacenada.

Descripcin :

Alternativas.

3a. Si el cliente no confirma el cambio de contrasea se vuelve al
paso 1.

4a. Si la contrasea actual no es correcta o la contrasea nueva es la
misma que la contrasea actual se mostrar un mensaje de error y se
ejecutara el paso 3.

Accin del Actor
el cliente ingresa al sistema y requiere
cambiar su contrasea.

2. El cliente indica que desea cambiar
su actual contrasea.

3. El cliente ingresa la contrasea
actual luego ingresa la contrasea
nueva, y la confirmacin.
4. El sistema valida que la contrasea
actual sea la correcta. Adems valida
que la contrasea nueva no sea la
misma que la actual y que cumpla con
el tamao mnimo de caracteres.

5. El sistema almacena la nueva
contrasea.


Caso de Uso : Recuperar clave olvidada.

Actores : Cliente.

Propsito : Permitir al cliente recuperar su clave.

Resumen : El sistema entrega la posibilidad al cliente de
recuperar la clave por medio de un mail que el
sistema le har llegar al cliente. Para esto el
cliente colocar su mail y la clave llegar
automticamente.

Descripcin :

Alternativas.

4a. El mail ingresada no es correcto por lo que se ejecuta el paso 3.

Accin del Actor
el cliente ha olvidado su contrasea y
desea recuperarla.

2. El cliente indica que desea
recuperar su contrasea.

3. El cliente ingresa su mail.
4. El sistema valida que el mail sea
correcto.

5. El sistema enva la clave al mail
del cliente.


Caso de Uso : Mostrar datos de un cliente.


Propsito : Permitir al administrador obtener los datos del
cliente que se desee.

Resumen : El sistema entrega al administrador la opcin
de ver todos los datos de un cliente
determinado, el administrador elige al cliente y
el sistema muestra los datos del cliente
respectivo.

Descripcin :

Alternativas.

3a. El id ingresado es incorrecto o no existe por lo que se enva un
mensaje y se ejecuta el paso 2.

Accin del Actor
el administrador ingresa al sistema y
desea conocer los datos de un cliente.

2. El administrador ingresa la id del
cliente.
3. El sistema valida la existencia del
cliente.

4. El sistema muestra los datos
correspondientes al cliente.


3.2.4.3. ESPECIFICACION DEL CASO DE USO: GESTIONAR CATLOGO

Caso de Uso : Mostrar Productos.

Actores : Cliente.

Propsito : Mostrar los productos y sus caractersticas a los
clientes que accedan al sistema.

Resumen : El sistema muestra a los clientes todos los
productos y las categoras a las que pertenecen
estos productos, adems de dar una
informacin detallada de cada producto

Descripcin :

Alternativas.

3a. La marca seleccionada no se encuentra en el sistema. Se ejecuta
paso 4.

Accin del Actor
el cliente desea ver los productos que
posee una marca determinada.

2. El Cliente indica que quiere ver los
productos segn la marca.

4. El Cliente selecciona el nombre de
la marca.
3. El sistema busca la marca
seleccionada.

5. El sistema muestra todos los
productos de la marca seleccionada.


Caso de Uso : Buscar producto

Actores : Cliente.

Propsito : Mostrar todos los productos.

Resumen : El sistema muestra al cliente, el producto de
acuerdo a la bsqueda.

Descripcin:

Accin del Actor
1. Este caso de uso comienza
cuando el cliente desea ver los
productos

2. El Cliente indica que quiere ver
los productos.

4. El Cliente escribe el nombre del
producto
3. El sistema busca el producto.

5. El sistema muestra el producto
segn la bsqueda realizada.


Caso de Uso : Agregar producto al carro de pedido

Actores : Cliente.

Propsito : Permitir al cliente incorporar productos a un
carro de pedido y enviar los productos
incorporados al vendedor.

Resumen : El sistema entrega al cliente la posibilidad de ir
ingresando los productos que vaya cotizando
en un carro de pedido.

Descripcin :

Alternativas.

2a. El cliente decide no incorporar productos al carro de pedido por
lo que vuelve al catlogo.

Accin del Actor
el cliente desea incorporar productos
a un carro de pedido.

2. El Cliente elige incorporar un
producto al carro de pedido.
3. El sistema muestra el carro con el
producto incorporado junto con su
precio y la cantidad.


Caso de Uso : Eliminar productos del carro de pedido

Actores : Cliente.

Propsito : Permitir al cliente eliminar productos del carro
de pedido.

Resumen : El sistema entrega al cliente la posibilidad de
eliminar los productos del carro de pedido que
ya no desee cotizar.

Descripcin :

Alternativas.

3a. Si no hay productos que eliminar en el carro de compras, se enva
un mensaje y se vuelve al paso 1.

Accin del Actor
el cliente desea un producto del carro
de pedido.

2. El Cliente elige eliminar un
producto al carro de pedido.
3. El sistema elimina el producto del
carro de pedido y muestra al cliente el
carro de pedido sin el producto que
elimin.


3.2.4.4. ESPECIFICACION DEL CASO DE USO: GESTIONAR PEDIDO

Caso de Uso : Mostrar pedidos.


Propsito : Permitir al administrador ver los pedidos que
estn almacenados en el sistema

Resumen : El administrador busca los pedidos por el
estado que stos tengan, es decir No Vendido
y Vendido.

Descripcin :

Accin del Actor
1. Este caso de uso se inicia cuando
el administrador ingresa al sistema e
indica que desea ver pedidos.

2. El administrador ingresa el estado
por el cual desea buscar los pedidos.
3. El sistema busca los pedidos que
tengan el estado especificado por el
administrador.



Caso de uso : Cambiar estado a un pedido.


Propsito : Cambiar el estado del pedido a Vendido o
No Vendido dependiendo del estado actual
que tenga cada uno.

Resumen : Si el estado del pedido es No vendido, el
administrador podr cambiar el estado a
Vendido.El administrador cambia el estado
del pedido y el sistema guarda los cambios
realizados.

Descripcin :

Accin del Actor
administrador desea cambiar el estado de
un pedido.

Incluye caso de uso Mostrar Pedidos.

2. El administrador indica que desea
cambiar el estado al pedido.
3. El sistema cambia el estado del pedido
y lo almacena.


Caso de uso : Eliminar pedido.


Propsito : Permite al administrador eliminar aquellos
pedidos que estn entregados .

Resumen : El administrador ingresa al sistema a eliminar
los pedidos que fueron entregados o que por
alguna razn el administrador desee eliminar.
El sistema busca y muestra todos los pedidos.
Finalmente el administrador selecciona los
pedidos que desea eliminar y el sistema los
borra.

Descripcin :

Accin del Actor
el administrador desea eliminar los
pedidos que fueron retirados.

2. El administrador selecciona un
pedido e indica que desea
eliminarlo.
3. El sistema elimina el pedido
indicado.


Caso de Uso : Mostrar detalle de un pedido.


Propsito : El sistema permite al administrador conocer los
detalles de un pedido.

Resumen : El administrador selecciona un pedido. Luego
el sistema muestra un informe con datos del
cliente, direccin de envo, informacin de los
productos que estn en el pedido.

Descripcin :

Accin del Actor
el administrador ingresa al sistema y
desea conocer los detalles de un
pedido.

pedido.
Incluye caso de uso Mostrar
Pedidos.
Responsabilidad del sistema
3. El sistema busca el detalle de ese
pedido.

4. El sistema muestra el detalle del
pedido.


Caso de Uso : Revisar pedidos.

Actores : Cliente.

Propsito : Permitir al cliente revisar en qu estado estn
los pedidos que ha realizado.

Resumen : El cliente ingresa al sistema para ver los
pedidos que ha realizado, y el sistema muestra
todos los pedidos que ste ha efectuado,
indicando la fecha en la que fue realizado el
pedido.

Descripcin :

Alternativas

3a. No existen pedidos. El sistema informa al cliente que no tiene
pedidos pendientes a travs de un mensaje.

Accin del Actor
cliente ingresa al sistema e indica que
desea ver los pedidos que ha
realizado.

pedido para ver el detalle de ste.
Responsabilidad del sistema
2. El sistema busca todos los pedidos
que ha realizado el cliente.

3. El sistema muestra el estado y la
fecha en la que fue realizado cada
uno de los pedidos.

5. El sistema busca y muestra el
detalle del pedido indicado.


3.3. ANALISIS
3.3.1. DIAGRAMA DE CLASES ENTIDAD



3.3.2. DIAGRAMA DE PAQUETE DE ANALISIS

3.4. DISEO
3.4.1. INTERFACE DE USUARIO







3.4.2. DIAGRAMA DE SECUENCIA DE DISEO
3.4.2.1. DIAGRAMA DE SECUENCIA DE DISEO:
GESTIONAR PRODUCTO

Figura 5.1: Diagrama de secuencia
Ingresar nuevo producto.

Figura 5.2: Diagrama de secuencia Eliminar producto.


Figura 5.3: Diagrama de secuencia Modificar datos del producto.
GESTIONAR CLIENTE

Figura 5.4: Diagrama de secuencia Registrar nuevo cliente.



Figura 5.5: Diagrama de secuencia Modificar datos cliente.

Figura 5.6: Diagrama de secuencia Identificar usuario.



Figura 5.7: Diagrama de secuencia Cambiar contrasea.

Figura 5.8: Diagrama de secuencia Mostrar datos del cliente.

Figura 5.9: Diagrama de secuencia Recuperar clave olvidada.



GESTIONAR CATLOGO

Figura 5.10: Diagrama de secuencia Mostrar productos.

Figura 5.11: Diagrama de secuencia Agregar productos al carro de pedido.



Figura 5.12: Diagrama de secuencia Eliminar productos del carro de pedido.

GESTIONAR PEDIDO

Figura 5.13: Diagrama de secuencia Mostrar pedidos.



Figura 5.14: Diagrama de secuencia Cambiar estado a un pedido.

Figura 5.15: Diagrama de secuencia Eliminar pedido.

Figura 5.16: Diagrama de secuencia Mostrar detalle de un pedido.



Figura 5.17: Diagrama de secuencia Revisar pedidos.



3.4.3. DIAGRAMA DE CLASES DE DISEO



3.4.4. DIAGRAMA DE ESTADO - GESTIONAR PEDIDO

3.4.5. DIAGRAMA DE PAQUETE DE DISEO



3.4.6. MODELO FISICO DE LA BASE DE DATOS
RELACIONAL (MySql)



3.4.7. MODELO FISICO DE LA BASE DE DATOS
RELACIONAL (Normalizado)

3.5. PRUEBA
3.5.1. PRUEBA DE LA CAJA NEGRA

Caso de uso: Registrar Nuevo Cliente
Registrar Nuevo Cliente: Ingreso de Datos Validos


ITEM DATOS TIPO DE DATOS
RESPUESTA
1 Ingresar E-mail Jhonsy_72@hotmail.com
Los datos fueron
ingresados
correctamente
2 Ingresar Password .
Los datos fueron
ingresados
correctamente
3
Confirmar
Password
.
Los datos fueron
ingresados
correctamente
4 Ingresar Nombres Jhon Erick
Los datos fueron
ingresados
correctamente
5 Ingresar Apellidos Romero Sotelo
Los datos fueron
ingresados
correctamente
6
Seleccionar
departamento
Lima
Los datos fueron
ingresados
correctamente
7
Seleccionar
provincia
Lima
Los datos fueron
ingresados
correctamente
8
Seleccionar
distrito
Jess Mara
Los datos fueron
ingresados
correctamente
9 Ingresar direccin Jr. Crdova N 526
Los datos fueron
ingresados
correctamente
10 Ingresar telfono 2658357
Los datos fueron
ingresados
correctamente



Registrar Nuevo Cliente: Ingreso de Datos No Validos
RESPUESTA
1 Ingresar E-mail Ks12213n2o Error
4
Ingresar Nombres null Error
5
Ingresar Apellidos null Error
9
Ingresar direccin null Error
10
Ingresar telfono mnjsdbs Error

Caso de uso: Ingresar nuevo producto
Ingresar Nuevo producto: Ingreso de Datos Validos
RESPUESTA
1 Seleccione
categora
Clic Los datos fueron
ingresados
correctamente
2
Ingresar Nombre Apolo Los datos fueron
ingresados
correctamente
3
Ingresar
Descripcin
APOLO 25 EW es un fungicida
que acta en forma sistmica
y preventiva sobre hongos que
causan enfermedades en Vias
y Parronales, Frutales,
Hortalizas, Rosas, Eucaliptos y
viveros de Pinos.
Los datos fueron
ingresados
correctamente
4
Ingresar
Compatibilidad
Este producto es
compatible con
fungicidas semejantes
Los datos fueron
ingresados
correctamente
5
Ingresar
Precauciones
Este producto es
Fungicida
Los datos fueron
ingresados
correctamente
6
Ingresar Precio 34 Los datos fueron
ingresados
correctamente



Ingresar Nuevo producto: Ingreso de Datos No Validos
RESPUESTA
1 Seleccione
categora
Clic Correcto
2
Ingresar Nombre null Error
3
Ingresar
Descripcin
null
Error
4
Ingresar
Compatibilidad
null Error
5
Ingresar
Precauciones
null Error
6
Ingresar Precio %jasjsa Error



4. CONCLUSIONES

El uso de tiendas virtuales para el comercio electrnico presenta grandes
ventajas por sobre las empresas que no utilizan este tipo de tecnologas.
Algunas de estas ventajas son: hacer sencilla la forma de realizar negocios con
los clientes, reduce los costos y precios y garantiza una disponibilidad las 24
horas del da.

Con la construccin de este proyecto, podemos concluir que es tanto una
solucin de comercio electrnico, dado que es un producto terminado listo
para usar; tanto como una plataforma para comercio electrnico, por cuanto
es posible utilizarla como base para la construccin de un proyecto
informtico. Para empresa Agrcola Chaves S.A.C representa una gran
oportunidad, puesto que mejorar los tiempos de espera de sus clientes. Los
clientes visitaran la pgina para consultar precios y descripciones de
productos, por lo que las molestas esperas en la tienda disminuiran
considerablemente. Adems Tendr una presencia en la Web mucho ms
interactiva que una simple pgina informativa.



5. RECOMENDACIONES

Se recomienda utilizar la metodologa orientada a objetos RUP
con su notacin UML, para futuros desarrollos de software por su
flexibilidad y utilidad en la representacin de sistemas de
informacin tanto de nivel medio como alto de complejidad.



6. REFERENCIAS BLIOGRAFICAS Y/O ENLACES WEB
CODEIGNITER
www.codejobs.biz

RUP
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

AGROTERRA
http://www.agroterra.com



7. BILIOGRAFIAS
http://es.wikipedia.org/wiki/Comercio_electr%C3%B3nico

http://www.monografias.com/trabajos12/monogrr/monogrr.shtml

http://www.smedia.com/ecommerce.aspx

http://es.wikipedia.org/wiki/B2C

http://www.panamacom.com/que_es_ec.html

http://www.maestrosdelweb.com

http://mireyalex.tripod.com/id6.html

http://www.itlp.edu.mx/publica/tutoriales/desproyectos/tema%203_1.ht
m

http://www.itlp.edu.mx/publica/tutoriales/desproyectos/tema%203_2.ht
m

http://es.wikipedia.org/wiki/AJAX

http://ajaxpatterns.org/wiki/index.php?title=Whats_Ajax



8. APENDICE
FORMATO DE ESPECIFICACION DE LOS CASOS DE USO DE REQUERIMIENTOS

Caso de Uso :
Actores :
Propsito :
Resumen :

Descripcin :

Alternativas:
-------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------
____________________________________________________________

Accin del Actor

Estructura Proyecto1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estructura Proyecto1

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD SAN PEDRO

También podría gustarte