Informe Del Sistema

UNIVERSIDAD SAN PEDRO
FACULTAD DE INGENIERA
ESCULA PROFESIONAL DE INGENIERA INFORMTICA Y DE
SISTEMAS
PRACTICAS PRE-PROFESIONALES II
Desarrollo de un aplicativo Web para administrar los procesos

de compra, venta y almacn de la empresa de Autopartes
Yeshua
ALUMNOS:
Oroya Alvarado Luis
Rivadeneyra Vega Jos
ASESOR:
Ing. Valle Pelez Miguel Arturo
CHIMBOTE - 2014
PALABRAS CLAVES
Tema
Aplicativo Web
Especialidad:
Ingeniera Web
Objetivo
Diseo de un aplicativo Web
Mtodo
Inductivo - Deductivo
KEYWORDS
Topic
Applicative Web
Specialty
Web Engineering
Objective
Design a Web application
Method
Inductive - Deductive
Practicas Pre Profesional II
TITULO
DESARROLLO DE UN APLICATIVO WEB PARA
ADMINISTRAR LOS PROCESOS DE COMPRA,
VENTA Y ALMACN DE LA EMPRESA DE
AUTOPARTES YESHUA
RESUMEN
El presente trabajo de investigacin est basado en un anlisis objetivo y minucioso

de la situacin problemtica de la Empresa Yeshua. Por lo que hemos tratado las gestiones
propias de ella como: Gestionar Ventas, Gestionar Compra, Gestionar Almacn.
La primera parte de este informe abarcar, basndonos en la informacin recopilada
obtenida gracias a las entrevistas con las personas involucradas, el Pictograma respectivo
en el que tratamos de plasmar la situacin actual que se viene dando el desarrollo de los
procesos principales de Autopartes Yeshua, donde identificamos a los personas o actores
que participan en el proceso, a partir del cual localizaremos los principales Procesos de
Negocio y a establecer nuestras Reglas de Negocio. Empezando as con los Diagramas
Respectivos y encontrando el Modelo de Dominio.
Pasando a una segunda parte que toca el punto de los Modelos de Requerimientos.
Se elaborar una Matriz de Priorizacin en la cual se descartar la prioridad de cada caso
de uso encontrado, indicndoles su importancia por una enumeracin establecida, pasando
as a otra etapa que se encargar de resolver la parte de Anlisis. Aqu, nos encargamos de
desarrollar los Diagramas de Colaboracin, aplicndolos a cada caso de uso que se encontr
en el Diagrama de Requerimientos, registros y reportes respectivos.
ABSTRACT
The present research is based on an objective and thorough of the problem situation
analysis of Yeshua Company. So we tried it their own efforts as: Manage Sales, Manage
Purchase, and Manage Warehouse.
The first part of this report will cover, based on the obtained information gathered through
interviews with the people involved, the respective pictogram in which we try to capture
the current situation that is ongoing development of key processes Autoparts Yeshua where
identify the persons or actors involved in the process, after which locate major Business
Processes and Business Rules set ours. Beginning with the well respective diagrams and
finding the Domain Model.
Turning to a second part that touches the point of Requirements Models. A Matrix of
prioritization in which the priority of each use case is found discarded be developed,
indicating its importance for an established list, thus moving to another stage that is
responsible for dealing Part Analysis. Here, we take care to develop Collaboration
Diagrams, applying to each use case was found in Diagram Requirements, records and tax
reports.
INDICE
1. Palabras Clave..2
2. Ttulo3
3. Resumen...4
4. Abstract5
5. ndice...6
6. Introduccin.7
7. Antecedentes y Fundamentacin Cientfica.8
8. Justificacin de la Investigacin..9
9. Problema.10
10. Marco Referencial..11
11. Objetivo General45
12. Objetivos Especficos.45
13. Materiales y Mtodos46
14. Conclusiones119
15. Recomendaciones120
16. Dedicatoria...121
17. Referencia Bibliogrfica..121
INTRODUCCIN
En el presente proyecto utilizamos todos los pasos necesarios para poder realizar un
sistema
para una organizacin siguiendo los pasos del RUP y el UML, usando los
artefactos de anlisis y Reglas de Oro, diseo de interfaces y procesos de construccin. El

proyecto empieza con la investigacin acerca de la empresa Yeshua, empresa dedicada a la
venta y mantenimiento de autos, de lo cual se extrae lo siguiente:
Modelado del Negocio: Pictograma, Modelo de casos de uso del Negocio, Diagrama de
actividad de cada uso de Negocio, Modelo de Objetos del Negocio y modelo de Dominio.
Donde se hace el dominio total de los procesos (sistema) de la institucin. Se conoce al
detalle cmo se desarrollan los procesos de negocio del sistema. Se descubre paso a paso
cmo funciona el caso de negocio.
Modelo de Requerimientos: Modelo de Casos de uso de Requerimientos Detallado,
Diagrama de Casos de uso de Requerimientos. Donde se hace la captura de requerimientos,
la coordinacin del equipo de desarrollo, la validacin de resultados, se valida los procesos.
En el Diagrama de Requerimientos, se indica las cosas que el sistema tiene que hacer e
implementar; y tambin quin usar cada caso de uso.
Anlisis: Diagrama de Colaboracin, Diagrama de Clases Entidad, Diagrama de Clases de
Anlisis, Diagrama de Paquetes de Anlisis.
5.1. ANTECEDENTES Y FUNDAMENTACIN CIENTFICA:

Trabajos previos y contemporneos relacionados con el tema de investigacin:
Mara Henao, Ana Quintero, en la Universidad Tecnolgica de Pereira en

Colombia, se desarroll un proyecto en el cual en el inicio se dio a conocer la
dinmica de cambio que se ha estado manifestando alrededor del mundo, hace
indiscutible la implementacin de herramientas que permitan a las organizaciones
adaptarse rpidamente a las necesidades del entorno, de tal manera que puedan
permanecer vigentes en sus actividades empresariales.
La administracin es una de las disciplinas que ayuda a las empresas alcanzar sus
metas y objetivos, logrando as una mayor competitividad dentro de su entorno.
Por lo tanto en el presente proyecto se desarroll la investigacin sobre los estilos
gerenciales en el rea metropolitana centro-occidente, con el fin de identificar
falencias y/o errores en el rea administrativa de las empresas pertenecientes al
sector comercial, del subsector de partes piezas y accesorios de lujo para vehculos
automotores, con el propsito de sugerir estrategias y alternativas que les permita
conservar su permanencia en el mercado.
Es as que en los primeros captulos se examinaron y analizaron algunos conceptos
y teoras administrativas , para incorporar los conocimientos necesarios a la
investigacin, de la misma manera se busc la informacin existente del subsector
en el rea metropolitana centro-occidente , permitiendo situarlo e identificarlo para
aplicar herramientas estadsticas y lograr visualizar de forma global el estado de las
organizaciones.
Donde finalmente se hizo un anlisis de la informacin obtenida, realizando as un
diagnstico de las situacin actual de los establecimientos, planteando una
propuesta viable para el mejoramiento del subsector, vinculando actores tales como
el sector financiero, gubernamental, universitario y las empresas del subsector , para
lograr una cooperacin estratgica que permitiera el crecimiento y desarrollo del
comercio en el rea metropolitana Centro Occidente y su fortalecimiento para ser
ms competitivos.
5.2. JUSTIFICACION DE LA INVESTIGACION

El sistema que se plantea como propuesta con todos los requerimientos y necesidades
de los usuarios finales, adems de contar con los aspectos tcnicos necesarios.
La idea de contar con un software que agilice los procesos y los automatice de tal
manera que beneficie a los empleados de YESHUA, realizando un mejor desempeo a sus
servicios que satisfaga las necesidades de los clientes, est fundamentada en las
necesidades de los clientes con la finalidad de obtener su preferencia.
Justificacin Operativa:
Mejor desempeo del personal en el proceso de atencin al cliente, el

sistema permitir un acceso completo a la informacin especfica y exclusiva
de cada cliente.
Eficacia en el control de las ventas. El sistema permitir llevar a cabo el

registro de todas las ventas hechas.
Agilizar la contabilizacin de los procesos de la empresa.
Permitir a la empresa tener un control ms exacto de ingresos y egresos

para poder contabilizar las ganancias de la empresa.
Justificacin Econmica:
Permitir reducir los costos en tiles de oficina y de personal, reduciendo el

tiempo de atencin al cliente
Justificacin Tcnica:
Tratamiento de la informacin con respecto al control de gestin de los procesos de la
empresa en forma adecuada y confiable, utilizando la tecnologa Cliente Servidor.
5.3. PROBLEMA
Autopartes Yeshua actualmente cuenta con reas como: ventas, almacn y compras,
todas estas reas no cuentan con un sistema capaz de llevar un control y una administracin
debida de los recursos existentes y/o realizar procesos en el menor tiempo posible.
Entre los problemas identificados y con ms importancia, se ha considerado lo
siguiente:
Inexistencia de un sistema que sea capaz de llevar el registro, control y manejo de la
informacin de cada cliente, ya sea en ventas y/o mantenimiento.
Demora y prdida de tiempo al llevar a cabo los procesos de registro de cada
cliente.
Ineficacia del manejo de registros de cada pedido para renovar el stock de
productos.
Falta de desarrollo de una interfaz que facilite el trabajo del usuario.
En base a estos problemas se propone:
Realizar un sistema capaz de controlar en primera instancia las necesidades bsicas

de un registro de datos.
Optimizar servicios en base a sistemas que ayuden la distribucin de los clientes.
Disear una interfaz entendible capaz de facilitar el trabajo a los usuarios.
10
5.4. MARCO REFERENCIAL

UML
El Lenguaje de Modelado Unificado UML, es
un lenguaje visual para especificar, construir y
documentar los artefactos de sistemas intensivos
en software.
Diseos de software complejas difciles para que
usted pueda describir con el texto solo pueden
ser
fcilmente
diagramas
transportados
utilizando
UML.
travs
de
Modeling
proporciona tres beneficios clave:
Visualizacin
Validacin
Una comunicacin clara
Usted puede utilizar UML en todos los procesos en todo el ciclo de vida de desarrollo y en
diferentes tecnologas de implementacin.
UML fue aprobado por el Grupo de gestin de objetos (OMG ) como estndar en
1997. En los ltimos aos, ha habido modificaciones menores realizados en el idioma.
UML 2 fue la primera revisin importante de la lengua.
(SysML ) Sistemas Modeling Language
En 2001, el Consejo Internacional de Ingeniera de Sistemas (INCOSE), junto con el OMG,
inici un esfuerzo para desarrollar un propsito, el lenguaje de modelado grfico general
para la ingeniera de sistemas. En pocos aos, naci el Lenguaje de Modelado de Sistemas
(SysML). Construido como una extensin del Lenguaje Unificado de Modelado (UML),
SysML ha convertido en el lenguaje estndar de facto para los sistemas de modelado y
sistemas - de -sistemas.
La norma SysML proporciona a los ingenieros y arquitectos de sistemas de una manera
muy necesaria para colaborar con un lenguaje comn que se ha diseado especficamente
11
para apoyar Ingeniera de Sistemas. Como un lenguaje de modelado estndar, SysML

permite la comunicacin a travs de la mejora de los equipos de ingeniera, al tiempo que
mejora en gran medida su capacidad de gestionar cada vez mayor complejidad del sistema
y reaccionar a los cambios. Adems, al permitir una representacin electrnica del diseo
del producto, SysML abre la puerta al anlisis de forma ms rpida y eficaz de toma de
decisiones en los sistemas de todo el desarrollo del ciclo de vida
a. Los diagramas expresan grficamente partes de un modelo
b. Diagramas
i. Diagramas de Caso de Uso
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera
con el sistema en desarrollo, adems de la forma, tipo y orden en como los
elementos interactan (operaciones o casos de uso).
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicacin.
12
Elementos
Actor:
Una definicin previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente representa a una persona
en particular, sino ms bien la labor que realiza frente al sistema.
Caso de Uso:
Es una operacin/tarea especfica que se realiza tras una orden de algn
agente externo, sea desde una peticin de un actor o bien desde la invocacin
desde otro caso de uso.
Relaciones:
Asociacin
Es el tipo de relacin ms bsica que indica la invocacin desde un actor
o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con
una flecha simple.
Dependencia o Instanciacin
13
Es una forma muy particular de relacin entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relacin se denota
con una flecha punteada.
Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble
funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>)
o de Herencia (<<extends>>).
Este tipo de relacin est orientado exclusivamente para casos de uso (y
no para actores).
Extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(caractersticas).
Uses: Se recomienda utilizar cuando se tiene un conjunto de
caractersticas que son similares en ms de un caso de uso y no se desea
mantener copiada la descripcin de la caracterstica.
14
ii. Diagramas de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
acontecimiento.
Clase: atributos, mtodos y visibilidad.
Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.
Elementos
Clase
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto
es una instancia de una clase). A travs de ella podemos modelar el entorno en
estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres
divisiones:
Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser private, protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma
como interacta el objeto con su entorno (dependiendo de la visibilidad:
private, protected o public).
Atributos y Mtodos:
15
Los atributos o mtodos de una Clase pueden ser de tres tipos, los que
definen el grado de comunicacin y visibilidad de ellos con el entorno, estos
son:
Public (+,
): Indica que el atributo o el mtodo ser visible tanto
dentro como fuera de la clase, es decir, es accesible desde todos lados.
Private (-,
): Indica que el atributo o el mtodo slo ser
accesible desde dentro de la clase (slo sus mtodos pueden acceder).
Protected (#,
): Indica que el atributo o el mtodo no ser
accesible desde fuera de la clase, pero si podr ser accedido por

mtodos de la clase adems de las subclases que se deriven (ver
herencia).
Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario explicar cmo se
pueden interrelacionar dos o ms clases (cada uno con caractersticas y
objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En
UML, la cardinalidad de las relaciones indica el grado y nivel de
dependencia, se anotan en cada extremo de la relacin y stas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
nmero fijo: m (m denota el nmero).
a.
Herencia (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por
una sper Clase, por ende la Subclase adems de poseer sus propios
16
mtodos y atributos, poseer las caractersticas y atributos visibles de la

sper Clase (public y protected), ejemplo:
En la figura se especifica que Auto y Camin heredan de Vehculo, es

decir, Auto posee las Caractersticas de Vehculo (Precio, VelMax, etc)
adems posee algo particular que es Descapotable, en cambio Camin
tambin hereda las caractersticas de Vehiculo (Precio, VelMax, etc) pero
posee como particularidad propia Acoplado, Tara y Carga.
b.
Agregacin:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que
proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando
se requiere componer objetos que son instancias de clases definidas por el
desarrollador de la aplicacin, tenemos dos posibilidades:
17
c.
Asociacin:
La relacin entre clases conocida como Asociacin, permite asociar
objetos que colaboran entre s.
d.
Dependencia o Instanciacin (uso):

Representa un tipo de relacin muy particular, en la que una clase es
instanciada (su instanciacin es dependiente de otro objeto/clase). Se
iii. Diagrama de Objetos

Los diagramas de objetos son utilizados durante el proceso de Anlisis y Diseo de
los sistemas informticos en la metodologa UML.
Se puede considerar un caso especial de un diagrama de clases en el que se
muestran instancias especficas de clases (objetos) en un momento particular del
sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un
diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los
roles, aunque su notacin es similar a los diagramas de clase.
18
iv. Diagrama de Secuencia

El diagrama de secuencia de uml muestra la forma en que los objetos se
comunican entre s al transcurrir el tiempo.
Los diagramas de secuencia, formalmente diagramas de traza de eventos o de
interaccin de objetos, se utilizan con frecuencia para validar los casos de uso.
19
FORM
A
ELEMENTO
DESCRIPCIN
Una lnea vertical que representa la secuencia de eventos que se

1
Lnea de vida
producen en un participante durante una interaccin, mientras el

tiempo avanza.
Un participante que es externo al sistema que est desarrollando.
Actor
Puede hacer que aparezca un smbolo de actor en la parte

superior de una lnea de vida estableciendo su propiedad Actor.
El remitente espera una respuesta a un mensaje sincrnico antes
Mensaje
de continuar. El diagrama muestra la llamada y el retorno. Los
sincrnico
mensajes sincrnicos se utilizan para representar llamadas de

funcin ordinarias dentro de un programa.
Mensaje
asincrnico
Incidencia de
ejecucin
Mensaje de
6
devolucin
de llamada
Automensaje
Un mensaje que no requiere una respuesta antes de que el

remitente contine. Un mensaje asincrnico muestra slo una
llamada del remitente.
Un rectngulo sombreado vertical que aparece en la lnea de la
vida de un participante y representa el perodo durante el que el
participante est ejecutando una operacin.
Un mensaje que vuelve a un participante que est esperando la

devolucin de una llamada anterior.
Un mensaje de un participante a s mismo. La aparicin de

20
ejecucin resultante aparece encima de la ejecucin de envo.
10
11
12
Crear
mensajes
Mensaje
encontrado
Un mensaje que crea un participante. Si un participante recibe

un mensaje de creacin, este debe ser el primer mensaje que
recibe.
Un mensaje asincrnico de un participante desconocido o no
especificado.
Mensaje
Un mensaje asincrnico a un participante desconocido o no
perdido
especificado.
Comentario
Uso de
interaccin
Un comentario se puede adjuntar a cualquier punto de una lnea

de vida.
Agrega una secuencia de mensajes que se definen en otro
diagrama. Para crear un Uso de interaccin, haga clic en la
herramienta y arrastre por las lneas de vida que desee incluir.
Una coleccin de fragmentos. Cada fragmento puede agregar
13
Fragmento
uno o ms mensajes. Para crear un fragmento, haga clic con el
combinado
botn secundario en un mensaje, elija Rodear con y, a

continuacin, haga clic en un tipo de fragmento.
Se puede utilizar para enunciar una condicin relativa a si el
14
Proteccin de
fragmentos
fragmento se producir. Para establecer la proteccin,

seleccione un fragmento, seleccione despus la proteccin y
escriba un valor.
21
v.
Diagrama de Colaboracin
Un diagrama de colaboracin puede especificar un contrato entre objetos, parte

esencial para la descripcin de un patrn de diseo. Este diagrama contiene todos
los elementos citados de un diagrama de colaboracin, dejando libres
posiblemente los tipos exactos de algunos objetos o con nombres genricos para
los mensajes.
vi. Diagrama de Estado

Los diagramas de estados son una tcnica conocida para describir el
comportamiento de un sistema. Describen todos los estados posibles en los que
puede entrar un objeto particular y la manera en que cambia el estado del objeto,
como resultado de los eventos que llegan a l. En la mayor parte de las tcnicas
OO, los diagramas de estados se dibujan para una sola clase, mostrando el
comportamiento de un solo objeto durante todo su ciclo de vida.
Existen muchas formas de diagramas de estados, cada una con semntica
ligeramente diferente. La ms popular que se emplea en las tcnicas de OO se basa
en la tabla de estados de David Harel (Vol. 8). OMT fue quien la us por primera
vez para los mtodos de OO y fue adoptada por Grady Booch en su segunda
edicin (1994).
22
vii. Diagrama de Actividad

En UML un diagrama de actividades se usa para mostrar la secuencia de
actividades. Los diagramas de actividades muestran el flujo de trabajo desde el
punto de inicio hasta el punto final detallando muchas de las rutas de decisiones
que existen en el progreso de eventos contenidos en la actividad. Estos tambin
pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en
la ejecucin de algunas actividades.
Las siguientes secciones describen los elementos que constituyen un diagrama de

actividades.
23
Actividades
Acciones
Restricciones de acciones
Flujo de control
Nodo inicial
Nodo final
Flojos de objetos y objeto
Nodos de decisin y combinacin
Nodos de Bifurcacin y Unin
Regin de Expansin
Gestores de Excepcin
Regin de Actividad Interrumpible
Particin
viii. Diagramas de Componentes
Un diagrama de componentes representa cmo un sistema de software es dividido
en componentes y muestra las dependencias entre estos componentes. Los
componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas,
mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el
campo de la arquitectura de software pero pueden ser usados para modelar y
documentar cualquier arquitectura de sistema.
24
Debido a que los diagramas de componentes son ms parecidos a los diagramas de

casos de usos, stos son utilizados para modelar la vista esttica y dinmica de un
sistema. Muestra la organizacin y las dependencias entre un conjunto de
componentes. No es necesario que un diagrama incluya todos los componentes del
sistema, normalmente se realizan por partes. Cada diagrama describe un apartado
del sistema.
ix. Diagrama de Despliegue
Los diagramas de despliegue son los complementos de los diagramas de
componentes que, unidos, proveen la vista de implementacin del sistema.
Describen la topologa del sistema la estructura de los elementos de hardware y el
software que ejecuta cada uno de ellos. Los diagramas de despliegue representan a
los nodos y sus relaciones. Los nodos son conectados por asociaciones de
comunicacin tales como enlaces de red, conexiones TCP/IP.
25
CLIENTE / SERVIDOR
La arquitectura cliente-servidor es un modelo de

aplicacin distribuida en el que las tareas se
reparten entre los proveedores de recursos o
servicios, llamados servidores, y los demandantes,
llamados clientes. Un cliente realiza peticiones a
otro programa, el servidor, quien le da respuesta.
Esta idea tambin se puede aplicar a programas que se ejecutan sobre una sola
computadora, aunque es ms ventajosa en un sistema operativo multiusuario distribuido a
travs de una red de computadoras.
Evolucin del modelo Cliente Servidor
Mono-capa
Data Base Server Computacin centralizada
Two-Tier Proceso de transacciones
Multi-tier Client/Server
Three-tier
Multi-tier
N-tier
En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus

caractersticas son:
Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la

comunicacin (dispositivo maestro o amo).
26
Espera y recibe las respuestas del servidor.
Por lo general, puede conectarse a varios servidores a la vez.
Normalmente interacta directamente con los usuarios finales mediante

una interfaz grfica de usuario.
Al contratar un servicio de redes, se debe tener en cuenta la velocidad de

conexin que le otorga al cliente y el tipo de cable que utiliza, por ejemplo: cable
de cobre ronda entre 1 ms y 50 ms.
Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus

caractersticas son:
Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean

entonces un papel pasivo en la comunicacin (dispositivo esclavo).
Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al

cliente.
Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos
casos el nmero mximo de peticiones puede estar limitado).
No es frecuente que interacten directamente con los usuarios finales.
Caractersticas Funcionales de la Arquitectura Cliente / servidor

27
Esta arquitectura se puede clasificar en cinco niveles, segn las funciones que asumen
el cliente y el servidor, tal y como se puede ver en el siguiente diagrama:
En el primer nivel el cliente asume parte de las funciones de presentacin de la
aplicacin, ya que siguen existiendo programas en el servidor, dedicados a esta tarea.
Dicha distribucin se realiza mediante el uso de productos para el "maquillaje" de las
pantallas del mainframe. Esta tcnica no exige el cambio en las aplicaciones orientadas
a terminales, pero dificulta su mantenimiento.
Adems, el servidor ejecuta todos los procesos y almacena la totalidad de los datos. En
este caso se dice que hay una presentacin distribuida o embellecimiento.
En el segundo nivel, la aplicacin est soportada directamente por el servidor, excepto
la presentacin que es totalmente remota y reside en el cliente. Los terminales del
cliente soportan la captura de datos, incluyendo una validacin
Parcial de los mismos y una presentacin de las consultas. En este caso se dice que hay
una presentacin remota.
En el tercer nivel, la lgica de los procesos se divide entre los distintos componentes
del cliente y del servidor. El diseador de la aplicacin debe definir los servicios y las
interfaces del sistema de informacin, de forma que los papeles de cliente y servidor
sean intercambiables, excepto en el control de los datos, que es responsabilidad
exclusiva del servidor. En este tipo de situaciones se dice que hay un proceso
distribuido o cooperativo.
En el cuarto nivel el cliente realiza tanto las funciones de presentacin como los
procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en
una base de datos centralizada. En esta situacin se dice que hay una gestin de datos
remota. En el quinto y ltimo nivel, el reparto de tareas es como en el anterior y
adems el gestor de base de datos divide sus componentes entre el cliente y el servidor.
Caractersticas Fsicas de la Arquitectura Cliente / servidor
28
Las unidades de almacenamiento masivo en esta arquitectura, se caracterizan por

incorporar elementos de proteccin que evitan la prdida de datos y permiten multitud
de accesos simultneos (alta velocidad, niveles RAID, etc.).
Para la comunicacin de todos estos elementos se emplea un sistema de red que se
encarga de transmitir la informacin entre clientes y servidores. Fsicamente consiste
en un cableado (coaxial, par trenzado, fibra ptica, etc.) o en conexiones mediante
seales de radio o infrarrojas, dependiendo de que la red sea local (LAN o RAL),
metropolitana (MAN) o de rea extensa (WAN).
Qu ventajas puede aportar el esquema cliente/servidor a las empresas
Como una primera ventaja podemos mencionar que con el uso de este esquema se
reducen los costos de produccin de software y se disminuyen los tiempos requeridos.
Esto es as, pues para la construccin de una nueva aplicacin pueden usarse los
servidores que hay disponibles, reducindose el desarrollo a la elaboracin de los
procesos del cliente, segn los requerimientos deseados. Lo anterior disminuye los
costos internos del rea de sistemas. Adems, se pueden obtener ventajas importantes
al reducir el costo del hardware requerido, llevando las aplicaciones a plataformas ms
baratas, aprovechando el poder de cmputo de los diferentes elementos de la red, y
facilitando la interaccin entre las distintas aplicaciones de la empresa. El esquema
Cliente / Servidor tambin contribuye a una disminucin de los costos de
entrenamiento de personal, pues favorecen la construccin de interfaces grficas
interactivas, las cuales son ms intuitivas y fciles de usar por el usuario final.
Fases de Implementacin
Una arquitectura cliente / servidor debe mostrar los sistemas de informacin no
como un cliente que accede a un servidor corporativo, sino como un entorno que
ofrece acceso a una coleccin de servicios. Para llegar a este estado pueden
distinguirse las siguientes fases de evolucin del sistema:
Fase de Iniciacin
29
Esta etapa se centra sobre todo en la distribucin fsica de los componentes entre
plataformas. Los dos tipos de plataforma son:
Una plataforma cliente para la presentacin (generalmente un ordenador personal de
sobremesa).
Una plataforma servidora (como por ejemplo el servidor de una base de datos
relacional) para la ejecucin de procesos y la gestin de los datos.
Fase de Proliferacin
La segunda etapa de una arquitectura cliente / servidor se caracteriza por la
proliferacin de plataformas clientes y servidoras. Ahora, el entorno para la
interaccin entre clientes y servidores se hace mucho ms complejo. Puede hacerse
una distincin entre:
Datos a los que se accede a travs de una red de rea local (conocida como LAN).
Los mecanismos de conexin son muy variados y suelen ser incompatibles.
En esta fase los problemas que se pueden plantear son:
La gestin de accesos se convierte en crtica y compleja, debido a la estructura del
organismo donde se est implantando la arquitectura. El mercado ofrece algunas
soluciones que mejoran la interoperabilidad y que se basan en conexiones
modulares que utilizan, entre otros:
Drivers en la parte cliente.
Pasarelas (Gateway) a bases de datos.
Especificaciones de protocolos cliente / servidor, etc.
Fase de Control
En esta fase se consolidan los caminos de acceso desde una plataforma cliente
particular, a una plataforma servidora particular.
Fase de Integracin
Esta etapa se caracteriza por el papel conjunto que juegan la gestin de accesos, la
gestin de copias y la gestin de recursos. La gestin de la informacin se debe
realizar de forma que se pueda entregar la informacin controlada por los servidores
30
que contienen los datos a las plataformas clientes que los requieran. El concepto en
que se basa este tipo de gestin es la distincin entre dos tipos de datos: datos de
operacin y datos de informacin.
Fase de Madurez
Esta es la etapa final de una arquitectura cliente / servidor. Se caracteriza por una
visin ms flexible de las plataformas fsicas del sistema que se contemplan como
una nica unidad lgica. Este estado tambin se caracteriza porque la tecnologa
cliente / servidor se ha generalizado en la empresa. Ya no es un problema saber qu
componentes se distribuyen en qu plataformas, porque los recursos se pueden
redistribuir para equilibrar la carga de trabajo y para compartir los recursos de
informacin. Lo fundamental aqu, es saber quin ofrece qu servicios.
La utilizacin de este tipo de arquitectura permite pensar en nuevos retos de diseo:
Desarrollo de componentes reutilizables entre distintas aplicaciones y

distintos grupos de trabajo
Desarrollo de aplicaciones distribuidas
Gestin del desarrollo de aplicaciones entre distintos equipos, etc.
MYSQL
MySQL es un sistema de administracin de bases de datos
(Database Management System, DBMS) para bases de datos
relacionales. As, MySQL no es ms que una aplicacin que
permite gestionar archivos llamados de bases de datos.
Existen muchos tipos de bases de datos, desde un simple archivo
hasta sistemas relacionales orientados a objetos. MySQL, como base de datos relacional,
utiliza mltiples tablas para almacenar y organizar la informacin. MySQL fue escrito en C
y C++ y destaca por su gran adaptacin a diferentes entornos de desarrollo, permitiendo su
31
interactuacin con los lenguajes de programacin ms utilizados como PHP, Perl y Java y
su integracin en distintos sistemas operativos.
Tambin es muy destacable, la condicin de open source de MySQL, que hace que su
utilizacin sea gratuita e incluso se pueda modificar con total libertad, pudiendo descargar
su cdigo fuente. Esto ha favorecido muy positivamente en su desarrollo y continuas
actualizaciones, para hacer de MySQL una de las herramientas ms utilizadas por los
programadores orientados a Internet.
VISUAL STUDIO ASP.NET

ASP.NET es una plataforma web que proporciona todos los
servicios necesarios para compilar aplicaciones web
empresariales basadas en servidor. ASP.NET est compilado
en .NET Framework, por lo que todas las caractersticas
de .NET Framework estn disponibles en las aplicaciones
ASP.NET. Las aplicaciones se pueden escribir en cualquier
lenguaje que sea compatible con Common Language Runtime (CLR), incluido Visual Basic
y C#.
Para crear aplicaciones web ASP.NET, puede usar Visual Studio. Adems, hay disponible
un producto gratuito independiente, Visual Studio Express para web, que incluye el
conjunto bsico de caractersticas de diseo web de Visual Studio.
En los temas siguientes se proporciona ms informacin sobre ASP.NET y desarrollo web
con Visual Studio.
ASP.NET 4.5.1 y Visual Studio 2013
32
Proporciona informacin sobre las caractersticas de ASP.NET de .NET

Framework 4.5.1 y Visual Studio 2013.
ASP.NET 4.5 y Visual Studio 2012

Proporciona informacin sobre las caractersticas de ASP.NET de .NET Framework
4.5, Visual Studio 2012 y Visual Studio Express 2012 para Web.
ASP.NET 4 y Visual Studio 2010

Proporciona informacin sobre las caractersticas de ASP.NET de .NET
Framework 4, Visual Studio 2010 y Visual Web Developer 2010 Express.
ASP.NET 3.5 y Visual Studio 2008

Proporciona un vnculo a temas que describen las caractersticas de ASP.NET de
.NET Framework 3.5, Visual Studio 2008 y Visual Web Developer 2008 Express.
Mapa de contenido de ASP.NET MVC 4 (en el sitio de ASP.NET)

Proporciona informacin sobre el marco que puede usar en ASP.NET para crear
aplicaciones diseadas segn el patrn modelo-vista-controlador (MVC).
ASP.NET Web Pages 2 (en el sitio de ASP.NET)

Proporciona informacin sobre el sitio de ASP.NET Web Pages (Razor), que es una
manera rpida, cercana y ligera de combinar cdigo de servidor con HTML para
crear contenido de web dinmico.
33
METODOLOGA DE DESARROLLO DE SOFTWARE

El proceso Unificado de Modelado (RUP).
El Proceso Unificado Racional, Rational Unified Process en ingls, y sus siglas RUP, es un
proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML,
constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos
firmemente establecidos, sino que trata de un conjunto de metodologas adaptables al
contexto y necesidades de cada organizacin, donde el software es organizado como una
coleccin de unidades atmicas llamados objetos, constituidos por datos y funciones, que
interactan entre s.
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente
quien, cmo, cundo y qu debe hacerse en el proyecto
RUP como proceso de desarrollo
RUP es explcito en la definicin de software y su trazabilidad, es decir, contempla

en relacin causal de los programas creados desde los requerimientos hasta la
implementacin y pruebas.
RUP identifica claramente a los profesionales (actores) involucrados en el

desarrollo del software y sus responsabilidades en cada una de las actividades.
Fases de desarrollo del software
Inicio
Elaboracin
Construccin
Transicin
Fase de inicio
Se hace un plan de fases, donde se identifican los principales casos de uso y se
identifican los riesgos. Se concreta la idea, la visin del producto, como se enmarca en el
34
negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visin del
proyecto.
Modelado del negocio
En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre
conocer sus procesos.
Entender la estructura y la dinmica de la organizacin para la cual el sistema va

ser desarrollado.
Entender el problema actual en la organizacin objetivo e identificar potenciales

mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento

comn de la organizacin objetivo.
Requisitos
En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los
usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.
Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el
sistema podra hacer.

Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
Definir el mbito del sistema.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas
del usuario.
Fase de elaboracin
Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los
riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las
caractersticas y el diseo de la arquitectura. En esta etapa el objetivo es determinar la
arquitectura ptima.
Anlisis y Diseo
35
En esta actividad se especifican los requerimientos y se describen sobre cmo se van a

implementar en el sistema.
Transformar los requisitos al diseo del sistema.
Desarrollar una arquitectura para el sistema.

Adaptar el diseo para que sea consistente con el entorno de implementacin.
Fase de construccin
Se basa en la elaboracin de un producto totalmente operativo y en la elaboracin del
manual de usuario. Construir el producto, la arquitectura y los planes, hasta que el
producto est listo para ser enviado a la comunidad de usuarios. En esta etapa el objetivo
es llevar a obtener la capacidad operacional inicial.
Implementacin
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El
resultado final es un sistema ejecutable.
Planificar qu subsistemas deben ser implementados y en qu orden deben ser

integrados, formando el Plan de Integracin.
Cada implementador decide en qu orden implementa los elementos del

subsistema.
Si encuentra errores de diseo, los notifica.
Se integra el sistema siguiendo el plan.
Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de
desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y especificacin de

requisitos por medio de demostraciones concretas.
Verificar las funciones del producto de software segn lo diseado.
36
Verificar que los requisitos tengan su apropiada implementacin.
Etapa de transicin
El objetivo es llegar a obtener el relase del proyecto. Se realiza la instalacin del
producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la
transicin del producto a los usuarios, lo cual incluye: manufactura, envo,
entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede
satisfecho, por tanto en esta fase suelen ocurrir cambios.
Despliegue
Esta actividad tiene como objetivo producir con xito distribuciones del producto y
distribuirlo a los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecucin final.
Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.
37
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste
en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteracin
se establecen en funcin de la evaluacin de las iteraciones precedentes.
A medida que se avanza en el proyecto, es decir, cuando se va pasando de una fase a
otra, la importancia relativa de cada uno de los Flujos de Trabajo va cambiando.
Como filosofa RUP maneja 6 principios clave
Adaptacin del proceso
El proceso deber adaptarse a las caractersticas propias de la organizacin. El tamao
del mismo, as como las regulaciones que lo condicionen, influirn en su diseo
especfico. Tambin se deber tener en cuenta el alcance del proyecto.
Balancear prioridades
Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de
todos.
Colaboracin entre equipos
El desarrollo de software no hace una nica persona sino mltiples equipos. Debe haber
una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones,
planes, resultados, etc.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de modo interno, en etapas iteradas. En cada
iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y
se refina la direccin del proyecto as como tambin los riesgos involucrados.
Elevar el nivel de abstraccin
Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del
software, lenguajes 4GL o esquemas (Frameworks) por nombrar algunos. Estos se
38
pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con
UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los
aspectos de la produccin.
Roles que se cumplen en el RUP
Analistas:
Analista de procesos de negocio.
Diseador del negocio.
Analista de sistema.
Especificador de requisitos.
Desarrolladores:
Arquitecto de software.
Diseador.
Diseador de interfaz de usuario
Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.
Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de configuracin.
Jefe de pruebas
Jefe de despliegue
Ingeniero de procesos
39
Revisor de gestin del proyecto
Gestor de pruebas.
Apoyo:
Documentador tcnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista grfico
Especialista en pruebas:
Especialista en Pruebas
Analista de pruebas
Diseador de pruebas
Otros roles:
Stakeholder
Revisor
Coordinacin de revisiones
Revisor tcnico
Gestin del proyecto

Se vigila el cumplimiento de los objetivos, gestin de riesgos y restricciones para
desarrollar un producto que sea acorde a los requisitos de los clientes y los usuarios.
Proveer un marco de trabajo para la gestin de proyectos de software intensivos.
Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y

monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
40
Configuracin y control de cambios

El control de cambios permite mantener la integridad de todos los mdulos que se crean
en el proceso, as como de mantener informacin del proceso evolutivo que han seguido.
Entorno
La finalidad de esta actividad es dar soporte al proyecto con las adecuadas herramientas,
procesos y mtodos. Brinda una especificacin de las herramientas que se van a
necesitar en cada momento, as como definir la instancia concreta del proceso que se va
a seguir.
En concreto las responsabilidades de este flujo de trabajo incluyen:
Seleccin y adquisicin de herramientas.
Establecer y configurar las herramientas para que se ajusten a la organizacin.
Configuracin del proceso.
Mejora del proceso.
Servicios tcnicos.
Niveles de documentacin de la metodologa RUP

Primer nivel de documentacin
Especifica en trminos generales qu actividades debern integrar el Sistema de
Aseguramiento de Calidad, que ser implantado en la organizacin. Este nivel contiene
los siguientes elementos:
Declaracin de Visin: Proyecciones de la administracin sobre el lugar que

ocupar la organizacin en el futuro.
Declaracin de Misin: Compromiso de la administracin para alcanzar la Visin.
Poltica de Calidad: Posicin de la organizacin, en cuanto a la manera en que la

calidad afectar la manera de cumplir con la Misin.
41
Requerimientos de Calidad: Conjunto de actividades que la organizacin debe

llevar a cabo, para asegurar la calidad tanto del proceso como el producto que
desarrolla
La Visin, Misin y Polticas de Calidad fueron desarrolladas a partir de los

lineamientos estratgicos del Departamento de Sistemas de Informacin.
El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.
Segundo nivel de documentacin
Este nivel incluye especificaciones detalladas, orientadas a la administracin, para
explicar cmo se llevarn a cabo las actividades que integran el Sistema de
Aseguramiento de Calidad. Este nivel est compuesto bsicamente por procedimientos
Administrativos, que son declaraciones de direcciones sistemticas, sobre cmo la
organizacin debe llevar a cabo cada uno de los Requerimientos de Calidad, definidos en
el Primer Nivel de Documentacin.
Tercer nivel de documentacin
Este nivel incluye especificaciones punto a punto, explcito y conciso para llevar a cabo
cualquier tarea en la organizacin. Est compuesto bsicamente por Procedimientos de
Operativos que describen cada paso que se debe realizar para concretar una tarea o
actividad; y Estndares que se utilizan con el fin de registrar datos o informacin de algo
especfico. Estos procedimientos y estndares han sido divididos en tres grupos:
1. Los relacionados con el desarrollo del curso Proyecto de Ttulo.
2. Los relacionados con el desarrollo de producto de software.
3. Los que guan la implantacin y mejoramiento del Sistema de Aseguramiento de
Calidad.
Esta divisin facilita el uso y mantencin del sistema. Por ejemplo, si hay cambios en las
normas administrativas que afecten el desarrollo de los cursos en general, entonces slo
se vern afectados los procedimientos y estndares relacionados con el desarrollo del
proyecto.
42
Ciclo de iteraciones de la metodologa RUP

Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo
dos disciplinas:
Disciplina de Desarrollo
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema

automatizado.
Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de

software.
Implementacin: Creando software que se ajuste a la arquitectura y que tenga el

comportamiento deseado.
Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo

lo solicitado est presente.
Disciplina de Soporte
Configuracin y administracin del cambio: Guardando todas las versiones del

proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Los elementos del RUP son:

Actividades, Son los procesos que se llegan a determinar en cada iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace
exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms
importantes para alcanzar un grado de certificacin en el desarrollo del software.
Mtodo pesado
Costo del cambio
43
Un cambio en las etapas de vida del sistema incrementara notablemente el costo.
Requiere un grupo grande de programadores para trabajar con esta metodologa.
Cada fase en RUP puede descomponerse en iteraciones. Una iteracin es un ciclo de

desarrollo completo dando como resultado una entrega de producto ejecutable (interna o
externa).
El proceso define una serie de roles:
Los roles se distribuyen entre los miembros del proyecto y que definen las tareas de cada
uno y el resultado (artefactos) que se espera de ellos.
FIG. N 19: DEFINICION DE ROLES DE LA METODOLOGIA RUP
Dimensiones del RUP

El RUP tiene dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del
proceso.
El eje vertical representa las disciplinas, que agrupan actividades definidas

lgicamente por la naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en

trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda
dimensin representa el aspecto esttico del proceso: cmo se describe en trminos
de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo,
los artefactos, y los roles.
44
Caractersticas esenciales que definen al RUP

Proceso Dirigido por los Casos de Uso:
Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y

desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos
de Uso son la base para la implementacin de las fases y disciplinas del RUP. Un Caso
de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se
relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de
pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por
el Cliente.
Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el

desarrollo de un proyecto de software. Este modelo plantea la implementacin
del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por
cumplir en cada iteracin y as poder ir completando todo el proyecto iteracin
por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede
mencionar la de tener pequeos avances del proyectos que son entregables al
cliente el cual puede probar mientras se est desarrollando otra iteracin del
proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad.
Proceso Centrado en la Arquitectura:

Define la Arquitectura de un sistema, y una arquitectura ejecutable construida
como un prototipo evolutivo. Arquitectura de un sistema es la organizacin o
estructura de sus partes ms relevantes. Una arquitectura ejecutable es una
implementacin parcial del sistema, construida para demostrar algunas funciones
y propiedades. RUP establece refinamientos sucesivos de una arquitectura
ejecutable, construida como un prototipo evolutivo.
45
Alcance de la metodologa RUP

La metodologa RUP es ms apropiada para proyectos grandes, tambin pequeos, dado
que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias
etapas. En proyectos pequeos, es posible que no se puedan cubrir los costos de
dedicacin del equipo de profesionales necesarios.
Antecedentes del RUP
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la
investigacin. En 1995 Rational Software compr una compaa sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de
uso a los mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el
resultado de una convergencia de Rational Approach y Objectory. El primer resultado de
esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en
el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. Desde all hasta la
actualidad es la metodologa ms empleada en el mundo.
Un FRAMEWORK de mtodos y mdulos reutilizables
Antes de que se puede aplicar a proyectos especficos dentro de una organizacin. Del
mismo modo, necesita terminar el esqueleto RUP y sus bibliotecas para adaptarlos a la
organizacin.
El marco RUP es definido por una familia de mtodo plug-ins que se basan en las
necesidades nicas del negocio, as como el contexto (complejidad tcnica y de gestin),
las organizaciones son capaces de crear sus propias configuraciones de mtodo y a la
medida de procesos. RUP proporciona un Fundacin arquitectnica y gran cantidad de
material que puede construirse en una definicin de proceso, por lo tanto, lo que permite
la organizacin adoptando configurar y ampliar esa fundacin como desee.
Flujos de trabajo de fase RUP
Cada fase en RUP tiene un flujo de trabajo, en el que se describe la secuencia en que las
actividades de todas las diversas disciplinas se pueden realizar para alcanzar los
objetivos del hito fase respectivos.
46
Fases RUP frente a las fases de la cascada

Las Fases RUP difieren de las fases SDLC de cascada tradicional. Para ayudar a las
organizaciones a adoptar el RUP. El hecho es que las fases en el RUP no equivalen a las
fases en el ciclo de vida de cascada. Para lograr esto se realiza a travs de mltiples
disciplinas.
5.5. OBJETIVOS
Objetivo General:
Desarrollar un Sistema Web para el control de ventas de autopartes de vehculos

para la Empresa Yeshua.
- Objetivos Especficos:
Recopilar informacin.
Realizar el modelado de negocios aplicando el Proceso Unificado de Rational

(RUP).
Elaborar el modelado de requerimientos aplicando el Proceso Unificado de Rational

(RUP).
Realizar anlisis y diseo aplicando el Proceso Unificado de Rational (RUP).
Implementar el sistema utilizando como lenguaje de programacin VISUAL

STUDIO ASP.NET y como manejador de base de datos Mysql.
Realizar el despliegue del sistema a la organizacin.
47
MATEIALES Y METODOS
6.1
MATERIALES
Microsoft Office 2010 (Word, Excel, Power Point)
Visual studio ASP.NET
MySQL
6.2
APLICACIN DE LA METODOLOGA
Modelamiento del Negocio:

Pictograma:
48
Procesos del Negocio:
Gestionar Venta: Una vez registrado se procede al registro de la venta, al asistente

de ventas con el cliente confirman la venta, dependiendo de la venta y si el cliente
lo desea una garanta por posibles fallas, luego el cliente pagar el monto especfico,
y recibir la entrega de sus productos, donde finalizar la venta.
Administrar Almacn: El asistente de almacn verifica si hay productos

suficientes para realizar las ventas respectivas, en caso de que no haya realiza un
pedido para que compre los productos faltantes, y realiza un pedido que debe ser
aprobado por el gerente general para confirmar la adquisicin de nuevos productos.
Gestionar Compra: Una vez hecho el informe de los productos faltantes, el gerente
da el visto bueno e inicia los pedidos a los proveedores correspondientes.
Reglas del Negocio:
Gestionar Venta:
Para registrar una venta, se verifica en la Base De Datos, si el cliente est registrado,
caso contrario, se procede a registrarlo.
El asistente de ventas verifica si se encuentran en almacn los productos solicitados

por el cliente, caso contrario, busca productos parecidos o de la misma calidad, para
no perder una posible venta.
El pago de la venta se har al contado.
La entrega de productos se har efectiva, una vez hecho el pago.
Administrar Almacn:
El asistente de almacn verifica el stock de los productos, en caso de que faltase

por la demanda del producto, se genera una orden de compra.
49
Esta orden de compra permanecer inactiva, hasta que el gerente la apruebe.
Gestionar Compra:
El gerente recibe los informes de productos faltantes y los examina.
En el caso de que exista algn error en dichos informes, este los manda a verificar,
sino comienza con los pedidos a los diversos proveedores.
Visin del Negocio

Introduccin:
El presente documento muestra la visin del negocio en trminos del sistema a
desarrollarse para la empresa Yeshua.
Este documento provee la definicin del sistema desde una perspectiva de todos los
involucrados en el sistema.
Esta visin abarca las funciones de la planificacin y control de los procesos establecidos
para la gestin comercial de la empresa de autopartes Yeshua.
Este documento se basa en lo siguiente:
Documento de Regla de Negocio.
Documento de Especificacin de Reglas de Negocios.
Documento Glosario de Negocio.
Posicionamiento:
Oportunidades de Negocio:
Para que todas las gestiones de la empresa marchen correctamente, se cuenta con 2
asistentes de ventas y 2 asistentes de mantenimiento en la tienda, por turno (maana y
tarde). A quienes se les solicita su disponibilidad. Paralelo a esto se solicita tambin al
Almacn de la empresa Yeshua un reporte de productos disponibles; generalmente se
cuenta con la cantidad suficiente de productos para poder trabajar con normalidad. Se
50
cuenta con excelente equipo de trabajo. Con esta informacin se procede; es como trabaja
la empresa Yeshua.
Estado del Problema:

Tabla N 01: Estado del problema
PROBLEMA
Demora
AFECTADOS
en
determinacin
IMPACTO
SOLUCION
la Cliente
Atraso
en
de
elaboracin venta
productos disponibles
Inestabilidad
la Realizar una data de

los
productos
tienda.
e Tienda
Prdida de tiempo para Gestionar un control
inseguridad
de
determinar productos de ms
informacin
de
tienda.
rgido
Fuente: Elaboracin Propia.
Estado del Posicionamiento del Producto:

Tabla N 02: Estado del Posicionamiento del Producto
Para
Nombre
Producto
Objetivo
Oroya Alvarado Luis

Rivadeneyra Vega Jos
Empresa de Autopartes Yeshua
del
Que la Empresa cuente con un sistema para poder
manejar sus procesos de manera adecuada.
Fuente: Elaboracin Propia
de
productos de la tienda
productos de tienda.
Desarrollado por
en
51
Resumen Stakeholder
Tabla N 03: Resumen de Stakeholder
NOMBRE
Gerente
REPRESENTANTE
Sr. Manuel Robles Castro.
ROL
Es el encargado de ver lo
relacionado a la plantilla de
trabajo, juntamente verifica a
Asistente de Almacn
Sr. Kevin Reyes Tapia
los proveedores
Encargado de Entrada
Salida de Productos de la
Asistente de Ventas
Asistente
Sr. Kevin Reyes Tapia

de ------------------------
Mantenimiento
empresa.
Realizan
las
ventas
de
productos de la empresa
Realizan los mantenimientos
de
los
productos
que
ingresan
Alternativas y competencias
El presente sistema como productos alternativos una hoja en Excel, una aplicacin
en Access (plantilla), La competencia para este producto lo provee
Objetivos de la Ingeniera de Negocios
Mdulo de Recopilar Clientes
Modulo para Elaborar Pedido
Modulo para Reportar Pedido
Restricciones
El Sistema solo puede ser manipulado por el Asistente de Ventas, Asistente de
Mantenimiento, Asistente de Almacn, Asistente de Caja y Administrador.
52
Rangos de Calidad
El producto cumplir con los estndares mininos de calidad
Precedentes y Prioridades
El sistema deber implementarse en el siguiente orden: Registrar Clientes, Registrar
Pedido, Registrar Plan Produccin, Elaborar Etapas de Produccin.
MODELADO DE CASOS DE USO DEL NEGOCIO:
53
DIAGRAMA DE ACTIVIDAD POR CADA CASO DE USO DE NEGOCIO

GESTIONAR VENTA:
54
ADMINISTAR ALMACEN:
55
GESTIONAR COMPRA:
56
MODELO DE OBJETOS DE NEGOCIO GENERAL
MODELO OBJETO DE NEGOCIO POR CADA PROCESO

MON GESTIONAR ALMACN
Registrar/Buscar
Proveedor_
Registrar/Buscar/Actualizar
Producto
Asistente_Almacen
Registrar/Buscar
Proveedor
Orden_Compra
buscar
Gerente
57
MON GESTIONAR VENTA

Registrar/Buscar
Cliente_
Registrar/Buscar
Garantia
Buscar/Actualizar
Cliente__
AsistenteVenta
Producto
Registrar/Buscar
Venta
MODELO DOMINIO
58
Glosario del Negocio:

- Orden de Compra: Es la solicitud el cual es realizado por el asistente de Almacn para
as alcanzar al Proveedor.
- Venta: Es el proceso personal o impersonal por el que el vendedor comprueba, activa y
satisface las necesidades del comprador para el mutuo y continuo beneficio de ambos.
- Cliente: Es la persona que recibe un producto o un servicio de esta empresa.
- Asistente de Venta: Es el encargado de vender los productos de los programas.
- Asistente de Almacn: es el encargado de administrar la llegada de productos para su
posterior venta, tambin realiza un conteo general de los productos en la empresa
- Producto: es el tem que va ser vendido a un cliente o va ser registrado por el asistente de
almacn.
- Proveedor: Es la persona o compaa que vende productos a Yeshua y as esta tenga
productos para vender.
LISTA DE REQUERIMIENTOS
REQUERIMIENTOS FUNCIONALES
1. Registrar Cliente
7. Registrar Usuario
2. Registrar Empleado
8. Registrar Venta
3. Registrar OrdenCompra
9. Listar Cliente
4. Registrar Producto
10. Reportar OrdenCompra
5. Registrar TipoProducto
11. Listar Producto
6. Registrar TipoUsuario
12. Listar Proveedor
59
REQUERIMIENTOS NO FUNCIONALES
De apariencia o interfaz externa
El software debe ser amigable para los empleados de la empresa.
El software debe ser ordenado en cuanto a su presentacin para los empleados.
De usabilidad
El software debe ser fcil de usar por cualquier personal, teniendo en cuenta la
inexperiencia informtica de algunas personas.
Permite a los usuarios un fcil registro de informacin correspondiente a los

diferentes rubros considerados.
De rendimiento
El software debe ser eficiente en cuanto al tiempo de respuesta a los dems

mdulos.
El software debe responder rpidamente a las solicitudes de los usuarios.
De soporte
Facilidad, por parte del desarrollador, de realizar un mantenimiento al software.
Se debe realizar pruebas de esfuerzo al sistema.
De seguridad y privacidad
Se debe permitir acceso a la data bajo previa identificacin y autenticidad del

usuario, un mximo de tres intentos de ingreso.
Se debe restringir la informacin que ha de ser mostrada a los usuarios segn su rol.
Se debe restringir las operaciones segn el tipo de rol que posea el usuario que
ingrese al sistema.
De confiabilidad
Ante un caso extremo (como prdida de fluido elctrico o cada del servidor) el
software debe garantizar la integridad y confiabilidad de la data.
De Hardware
Se debe disponer de una red LAN.
Se contar de una impresora para la impresin de documentos.
De Software
Se debe disponer de sistema operativo Windows XP o superior.
De restricciones en el Diseo y la Implementacin
El software se regir a un estndar de diseo de interfaz y a un estndar de

codificacin.
El software se desarrollar en ASP.NET
El software tendr acceso a la BD elaborada en Mysql
El software contemplar el uso del Rational Suite Enterprise para su concepcin,

anlisis, elaboracin, parte de su construccin y transicin.
Registrar Cliente
<<include>>
_Asistente_Mantenimiento
Registrar Cliente
_Asistente_Venta
Buscar Cliente
Registrar Empleado
<<include>>
Registrar Empleado
_Gerente
Buscar Empleado
Registrar Marca
<<include>>
_Asistente_Almacen
Registrar Marca
Buscar Marca
Registrar OrdenCompra
<<include>>
Buscar OrdenCompra
<<include>>
_Asistente_Almace
n
Registrar Pedido
Buscar Producto
<<include>>
Buscar Pedido
<<include>>
_Asistente_Almacen
Registrar Pedido
Buscar ProductoMantenimiento
Registrar Producto
<<include>>
Buscar Producto
<<include>>
_Asistente_Almacen
Registrar Producto
Buscar Proveedor
<<include>>
<<include>>
Buscar TipoProducto
Buscar Marca
Registrar Proveedor
<<include>>
_Gerente
Registrar Proveedor
Buscar Proveedor
Registrar TipoProducto
<<include>>
_Asistente_Almac
en
Buscar TipoProducto
Registrar Usuario
<<include>>
Buscar TipoUsuario
<<include>>
_Gerente
Registrar Usuario
Buscar Em pleado
<<include>>
Buscar Usuario
Registrar Venta
<<include>>
Buscar Venta
<<include>>
Buscar Cliente
<<include>>
_Asistente_Venta
Registrar Venta
<<include>>
Buscar Producto
Buscar Empleado
Listar cliente:
_Asistente_Venta
<<include>>
Listar Cliente
_Asistente_Mantenimiento
Listar Producto
Buscar Cliente
<<include>>
Bus car Producto

<<include>>
Bus car Proveedor
<<include>>
_As is tente_Alm acen
Lis tar Producto
Bus car TipoProducto

<<include>>
Bus car Marca
Listar Proveedor
<<include>>
_Gerente
Listar Proveedor
Buscar Proveedor
Reportar OrdenCompra
<<include>>
_Asistente_Almace
n
Reportar Boleta Venta
Buscar OrdenCompra
<<include>>
_Asistente_Venta
Reportar BoletaVenta
Diagrama de Requerimientos No Detallado:
Buscar Venta
Matriz de Priorizacin de Casos de Usos:
Rendimie
N
Caso de uso
nto
(SEG)
1
2
3
4
5
6
7
8
9
10
11
12
Registrar Cliente
Registrar Empleado.
Registrar Producto.
Registrar TipoUsuario
Registrar Usuario
Registrar Venta
Listar Cliente
Reportar Factura Venta
Listar Producto
15
20
30
20
15
15
25
20
25
20
15
25
Frecuen
cia
(DIA)
15
0.05
0.05
0.05
0.0005
0.005
20
0.015
0.015
0.01
0.03
0.015
Importancia
Urgencia
Vital
Importante
Vital
Vital
Importante
Importante
Vital
Vital
Vital
Vital
Vital
Vital
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Inmediato
Priori
dad
3
5
1
5
5
5
1
3
1
1
5
1
Especificacin de los Casos de Uso de Requerimientos

Registrar Cliente
RegCli
Descripcin
Precondicin
Secuencia Normal
Registrar Cliente
El asistente de ventas realiza el registro del
cliente en el sistema, en el caso de que sea un
cliente nuevo, ya que el sistema puede tener una
lista de tipos de cliente.
Buscar Tipo de cliente.
Paso
Accin
Post condicin
Excepciones
Rendimiento
Frecuencia
Importancia
Urgencia
Registrar Empleado
RegEmp
Descripcin
1
Buscar cliente.
2
Registrar cliente.
Cliente registrado.
Paso
Accin
Entrada Invlida. El usuario ha
E-1
ingresado un dato no valido.
Datos no vlidos, el sistema no puede
E-2
grabar el registro.
La Informacin no puede ser
E-3
recuperada.
15 seg.
15 al da.
Vital
Inmediatamente.
Registrar Empleado
El Sistema deber permitir al Administrador
registrar nuevos empleados que trabajaran en la
empresa.
Segn se describe en el siguiente caso de uso:
Precondicin
Secuencia Normal
Post condicin
Rendimiento
Frecuencia
Importancia
Urgencia
RegOrdComp
Descripcin
Precondicin
Secuencia Normal
Post condicin
Excepciones
Paso
Accin
1
Buscar Empleado
2
Registrar Empleado
Empleado registrado.
20 seg.
0.05
Importante
Inmediato
El Gerente verifica los pedidos pendientes y
realiza una orden de compra.
Registrar pedido.
Paso
Accin
1
Buscar pedido.
2
Buscar orden de compra.
3
Registrar orden de compra.
Orden de compra registrado.
Paso
Accin
E-1
E-2
E-3
Rendimiento
Frecuencia
Importancia
Urgencia
Registrar Producto
RegProd
Descripcin
Precondicin
Secuencia Normal
Post condicin

grabar el registro.
recuperada.
30 seg.
0.05 al da
Vital.
Inmediatamente.
RegistrarProducto
El asistente de almacn se encarga de registrar
los nuevos productos para su posterior venta
Registrar tipo producto.
Registrar proveedor.
Registrar marca
Paso
Accin
1.
Buscar proveedor
2.
Buscar tipo producto
3.
Buscar Marca
4.
Registrar producto.
Producto registrado.
Paso
E-1
Excepciones
E-2
E-3
Rendimiento
Frecuencia
Importancia
Urgencia
RegTipoProd
Descripcin
Precondicin
Secuencia Normal
Post condicin
Excepciones
Rendimiento
Frecuencia
Importancia
Urgencia
Registrar TipoUsuario
RegTipoUsu
Descripcin
Precondicin
Secuencia Normal
Post condicin
Excepciones
Accin
grabar el registro.
recuperada.
20 seg.
0.05 al da
Vital.
Inmediato.
El asistente de almacn procede a registrar el
tipo de mantenimiento
Buscar tipo de producto
Paso
Accin
1
Buscar tipo de producto.
2
Registrar tipo de producto.
Tipo de producto registrado.
Paso
Accin
E-1
E-2
grabar el registro.
E-3
recuperada.
45 seg.
0.0001
Importante.
Inmediatamente.
RegistrarTipoUsuario
El Gerente procede a registrar el tipo de usuario
Buscar tipo de usuario.
Paso
Accin
1
2
Registrar tipo de usuario.
Tipo de usuario registrado.
Paso
Accin
E-1
E-2
grabar el registro.
La informacin no puede ser
E-3
recuperada.
Rendimiento
Frecuencia
Importancia
Urgencia
Registrar Usuario
RegUsu
Descripcin
Precondicin
Secuencia Normal
Post condicin
Excepciones
Rendimiento
Frecuencia
Importancia
Urgencia
Registrar Venta
Regven
Descripcin
Precondicin
Secuencia Normal
Post condicin
Excepciones
15 seg.
0.0005
Importante.
Inmediatamente.
RegistrarTipoUsu
El administrador procede a registrar a los
usuarios que podrn manejar el sistema
Registrar empleado.
Paso
Accin
1
Buscar empleado.
2
3
Buscar usuario.
4
Registrar usuario.
Usuario registrado.
Paso
Accin
E-1
E-2
grabar el registro.
La informacin no puede ser
E-3
recuperada.
20 seg.
0.001
Importante.
Inmediatamente.
Registrar Venta
El asistente de venta procede a registrar la venta
Registrar empleado.
Registrar cliente.
Registrar producto.
Paso
Accin
1
Buscar empleado.
2
Buscar cliente.
3
Buscar producto.
4.
Registrar venta.
Venta registrada.
Paso
Accin
E-1
E-2
grabar el registro.
E-3
Rendimiento
Frecuencia
Importancia
Urgencia
Listado Cliente
LisCli
Descripcin
Precondicin
Secuencia Normal
Post condicin
Rendimiento
Frecuencia
Importancia
Urgencia
Reporte de Orden de Compra

RepOrdCom
Descripcin
Precondicin
Secuencia Normal
Post condicin
Rendimiento
Frecuencia
Importancia
Urgencia
La informacin
recuperada.
no
puede
ser
25 seg.
20
Vital.
Inmediatamente.
Listado Cliente
El Sistema deber permitir a la secretaria realizar un
listado de todos los clientes registrados en forma
detallada.
Registrar cliente.
Paso
Accin
2
Buscar cliente.
3
Listar clientes.
Listado de clientes realizado.
20 seg.
0.015.
Vital
Inmediatamente
Reporte de Orden de Compra

El Sistema deber permitir al Administrador
realizar un reporte de todas las compras en
forma detallada o especificando una condicin.
Orden de Compra registrado
Paso
Accin
1
Buscar pedido.
3
Buscar orden de compra.
2
Reporte de orden de compra
Reporte de Orden Compra realizado
25 seg.
0.015
Vital
Inmediatamente

RegBolVen
Descripcin
Precondicin
Reporte Boleta Venta

El Sistema deber permitir al asistente de venta
realizar un reporte de todas las ventas de los
clientes naturales.
Post condicin
Rendimiento
Frecuencia
Registrar Venta.
Paso
Accin
1
Buscar venta.
3
Reportar BoletaVenta.
Reporte de pedido realizado
20 seg.
0.01
Importancia
Urgencia
Vital
Inmediatamente
Secuencia Normal
Reporte de Factura Venta

RepFactVen
Descripcin
Precondicin
Secuencia Normal
Poscondicin
Rendimiento
Frecuencia
Importancia
Urgencia
DIAGRAMAS DE COLABORACIN
Reporte Factura Venta

El Sistema deber permitir al asistente de venta
realizar un reporte de todos las ventas de los
clientes jurdicos.
Venta Registrada
Paso
Accin
1
Buscar Venta.
2
Reportar Venta.
Reporte de factura ventas realizado
25 seg.
0.015
Importante
Inmediatamente
Registrar Cliente
3: leer()
2: Buscar Cliente()
4: Obj. Cliente()
: CBuscarCliente
1: Registrar Cliente
: _Asistente_Venta
: GUI:RegistrarCliente
: ECliente
5: Registrar liente
:
_Asistente_Ma...
Registrar Empleado
6: Crear()
7: Var. Cliente()
: CRegistrarCliente
3: Leer()
2: Buscar Empleado()
4: Obj. Empleado()
: CBuscarEmpleado
1: Registar Empleado
: _Gerente
: GUI:RegistrarEmpleado
: EEmpleado
6: Leer()
5: Registrar Empleado()
7: Var. Empleado
: CRegistrarEmpleado
2: Buscar OrdenCompra()
3: Leer()
4: Obj. OrdenCompra()
: CBuscarOrdenCompra
1: Registrar OrdenCompra
:
_Asistente_Al...
5: Buscar Producto()
6: Leer()
7: Obj. Producto()
: GUI:RegistrarOrdenCompra
: CBuscarProducto
8: Registrar Orden Compra()
10: Var. Orden Compra()

: CRegistrarOrdenCompra
Registrar Pedido
: EProducto
9: Leer()
: EOrdenCompra
3: Leer()
2: Buscar Pedido()
4: Obj. Pedido()
: CBuscarPedido
1: Registrar Pedido
6: Leer
7: Obj. Producto()
:
_Asistente_Almacen
: GUI:RegistrarPedido
: EProducto
: CBuscarProducto
: EPedido
9: Crear()
8: Registrar Pedido()
10: Var. Pedido()

: CRegistrarPedido
Registrar Producto
4: Obj. Producto()
3: Leer()
: CBuscarProducto
6: Leer()
5: Buscar proveedor()
1: Registrar Producto
7: Obj. Proveedor()
: EProveedor
: CBuscarProveedor
:
_Asistente_Almacen
: GUI:RegistrarProducto 8: Buscar tipo Producto()
9: Leer()
10: Obj. Tipo Producto()

: CBuscarTipoProducto
11: Buscar Marca()
: ETipoProducto
12: Leer()
13: obj. marca()

: CBuscarMarca
14: Registrar producto()
16: var. producto()

: CRegistrarProducto
Registrar Tipo Usuario
: EProducto
: EMarca
15: Crear()
2: Buscar TipoUsuario()
1: Registrar TipoUsuario
3: Leer()
4: Obj. TipoUsuario()
: CBuscarTipoUsuario
: GUI:RegistrarTipoUsuario
: _Gerente
: ETipoUsuario
6: Crear()
5: Registrar TipoUsuario()
7: Var. TipoUsuario()
: CRegistrarTipoUsuario
Registrar Usuario
3: Leer()
2: Buscar Usuario()
4: Obj. Usuario()
: CBuscarUsuario
6: Leer()
5: Buscar TipoUsuario()
1: Registrar Usuario
7: Obj. TipoUsuario()
: ETipoUsuario
: CBuscarTipoUsuario
: _Gerente
: GUI:RegistrarUsuario 8: Buscar Empleado()
10: Obj. Empleado()

: CBuscarEmpleado
11: Registrar usuario()
: EEmpleado
12: Crear()
13: Var. Empleado()

: CRegistrarUsuario
Registrar Venta
: EUsuario
9: leer()
3: leer()
2: Buscar Venta()
4: obj. Venta()
: CBuscarVenta
5: Buscar Empleado()
6: Leer()
7: obj. Empleado()
: EEmpleado
: CBuscarEmpleado
1: Registrar Venta
8: Buscar Cliente()
9: leer()
10: obj. cliente()

: _Asistente_Venta
: GUI:RegistrarVenta
: CBuscarCliente
11: Buscar DetalleVenta()
: CBuscarCliente
: EVenta
12: leer()
13: obj.DetalleVenta
: CBuscarDetalleVenta
: EDetalleVenta
14: registrar venta()
15: Crear()
16: var. venta()

: CRegistrarVenta
Listar Cliente
: _Asistente_Venta
2: Generar ReporteCliente()
1: Reportar Cliente
4: obj. ReporteCliente()
: GUI:ListarCliente
:
_Asistente_Ma...
Listar Producto
3: Leer()
:
CGenerarReporteCliente
: ECliente
1: Reportar Prdocuto
:
_Asistente_Al...
2: Generar ReporteProducto()
3: Leer()
4: obj. reporteproducto()
: EOrdenCompra : GUI:LisrtarProducto
: CGenerarListadoProducto
: EProducto
Reportar Orden de Compra

1: Reportar OrdenCompra
3: Leer()
2: Generar ReporteOrdenCompra()
4: obj. ReporteOrdenCompra()
: _Gerente
: GUI:ReportarOrdenCompra
:
CGenerarReporteOrdenCompra
: EOrdenCompra

1: Reportar BoletaVenta
: _Asistente_Venta
2: Generar Reporte Boletaventa()
3: Leer()
4: obj. BoletaVenta
: GUI:ReportarBoletaVenta
: CGenerarReporteBoletaVenta
: EVenta
Reportar FacturaVenta
1: Reportar FacturaVenta 2: Generar ReporteFacturaVenta()
: _Asistente_Venta
4: obj. reportefacturaventa()
: GUI:ReportarFacturaVenta : CGenerarReporteFacturaVenta
Diagrama de Clases de Entidad
3: Leer()
: EVenta
Diagrama de Paquetes de Anlisis
Presentacin
Paquete de Datos
Lgica
Datos
Paquete Lgico
Paquete Presentacin
DIAGRAMA DE ESTADO
Cliente
Estado Cliente( Cliente=1 )
Habilitado
Deshabilita
do
Estado Cliente( Cliente=0 )
Estado Producto( Producto=1 )
DetalleVenta
Producto
Habilitado
DetalleVenta
Registado
Estado Producto(Producto=0)
Producto
Deshabilitado
Empleado
Estado Empleado( Empleado=1 )
Habilitado
Deshabilita
do
Estado Empleado( Empleado=0 )
OrdenCompra
si estadopedido = 1
si estadopedido = 0
Estado Proveedor(Producto=1)
Pedido
Habilitado
OrdenCompra
Regitrado
Pedido
Deshabilitado
Proveedor
Habilitado
Producto
Estado TipoProducto( TipoProducto=1 TipoProducto
)
Habilitado
Estado Marca( Marca=1 )
Marca
Habiiltada
Producto
Registrado
Proveedor
Estado Proveedor( Proveedor = 1 )
Habilitado
Deshabilita
do
Estado Proveedor( Proveedor = 0 )
TipoProducto
Estado TipoProducto( TipoProducto = 1 )
Habilitado
Des habilita
do
Estado TipoProducto( TipoProducto = 0 )
TipoUsuario
Estado TipoUsuario( TipoUsuario = 1 )
Habilitado
Deshabilita
do
Estado TipoUsuario( TipoUsuario= 0 )
Usuario
estado tipousuario(tipousuario=1)
Tipo Usuario
Habilitado
Usuario
Registrado
estado empleado( empleado=1 )
Venta
Empleado
habilitado
estado Cliente( cliente=1 )
Cliente
Habilitado
estado empleado( empleado=1 )
Empleado
habilitado
estado detalleventa( detalleventa=1 )
DetalleVenta
Habilitado
DIAGRAMA DE PAQUETES DE DISEO:
Venta
Registrada
Registro
Paquete Registro
Paquete procesos
Procesos
Reportes
Paquete Reportes
DISEO
Pgina principal
Informacin de la empresa
Algunas fotos de la empresa
Interfaz una vez que se ha iniciado sesin
Registro del Cliente
Registrar marca del producto
Registrar Tipo Producto
Registrar Producto
Registrar al Proveedor
Registrar la venta de Productos
Registrar Orden Compra a Proveedor
RECIBO POR COMPRA REALIZADA
REPORTE
BASE DE DATOS
SCRIPT DE LA BD
USE [AUTOPARTES]
GO
/****** Object: StoredProcedure [dbo].[PA_Capturar_TipoUsuario] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
create procedure [dbo].[PA_Capturar_TipoUsuario]
@nom Nchar(20)
as
select TIPO_USUARIO .Nombre from USUARIO,TIPO_USUARIO WHERE USUARIO
.IdTipoUsuario = TIPO_USUARIO .IdTipoUsuario
AND USUARIO .Nombre_Usuario = @nom
GO
/****** Object: StoredProcedure [dbo].[PA_CapturarCodigoOrdenCompra] Script Date:
18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_CapturarCodigoOrdenCompra]
AS
SELECT MAX(IdOrdenCompra ) FROM ORDEN_COMPRA
GO
/****** Object: StoredProcedure [dbo].[PA_CapturarCodigoUsuario] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_CapturarCodigoUsuario]
@usu varchar(20)
as
select IdUsuario from USUARIO where Nombre_Usuario = @usu
GO
/****** Object: StoredProcedure [dbo].[PA_CapturarCodigoVenta] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_CapturarCodigoVenta]
AS
SELECT MAX(Id_Venta ) FROM VENTA
GO
/****** Object: StoredProcedure [dbo].[PA_CapturarNombreApellidoUsuario] Script Date:
18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_CapturarNombreApellidoUsuario]
@usu varchar(20)
as
select Nombre_Apellidos from USUARIO where Nombre_Usuario = @usu
GO
/****** Object: StoredProcedure [dbo].[PA_CapturarPrecioGarantia] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_CapturarPrecioGarantia]
@idGarantia int
as
select Precio from GARANTIA where Id_Garantia = @idGarantia
GO
/****** Object: StoredProcedure [dbo].[PA_CapturarStockProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_CapturarStockProducto]
@idproducto varchar(20)
as
select Stock from PRODUCTO where IdProducto = @idproducto
GO
/****** Object: StoredProcedure [dbo].[PA_EditarGarantia] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_EditarGarantia]
@ID int,
@nom varchar(20),
@precio decimal(8,2),
@des varchar(50),
@estado varchar(10)
as
begin
if exists ( select *from GARANTIA
where replace(replace(replace(replace(replace(ltrim(upper(Nombre )),
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom and Id_Garantia <> @ID)
raiserror('NO SE PUEDE EDITAR LA GARANTIA! YA EXISTE !',16,1)
else
UPDATE GARANTIA
SET Nombre = @nom ,Precio =@precio ,Descripcion =@des,Estado= @estado
WHERE Id_Garantia = @ID
END
GO
/****** Object: StoredProcedure [dbo].[PA_EditarMarcaProducto] Script Date: 18/12/2014

03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_EditarMarcaProducto]
@ID int,
@nom varchar(20),
@estado tinyint
as
begin
if exists ( select *from MARCA_PRODUCTO
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom and Id_Marca <> @ID)
raiserror('NO SE PUEDE EDITAR LA MARCA DEL PRODUCTO ! YA EXISTE !',16,1)
else
UPDATE MARCA_PRODUCTO
SET Nombre = @nom ,Estado= @estado
WHERE Id_Marca = @ID
END
GO
/****** Object: StoredProcedure [dbo].[PA_EditarProducto] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_EditarProducto]
@ID int,
@Nom varchar(40),
@des varchar(max),
@precio_compra decimal(8,2),
@precio_venta decimal(8,2),
@stock int,
@esta varchar(10),
@idtipo int,
@idmarca int
AS
BEGIN
if exists (select * from PRODUCTO where (Nombre = @Nom ) AND IdProducto <> @ID )
raiserror('EXISTE YA OTRO PRODUCTO CON ESOS DATOS',16,1)
else
UPDATE PRODUCTO
SET Nombre= @nom , Descripcion =@des ,Precio_Compra =@precio_compra ,Precio_Venta
=@precio_venta,STOCK =@stock,Estado =@esta,Id_TipoProducto =@idtipo ,Id_Marca =
@idmarca
WHERE IdProducto = @ID
END
GO
/****** Object: StoredProcedure [dbo].[PA_EditarProveedor] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_EditarProveedor]
@ID int,
@nomcompa VARCHAR(30),
@nomcontac varchar(30),
@ruc char(11),
@Bancario varchar(50),
@tele char(9),
@dire Varchar(50),
@email Varchar(50),
@esta varchar(10)
AS
BEGIN
if exists ( select *from PROVEEDOR
where (replace(replace(replace(replace(replace(ltrim(upper(NombreCompaia )),
'','A'),'','E'),'','I'),'','O'),'','U')
= @nomcompa OR Ruc = @RUC) and IdProveedor <> @ID)
raiserror('EXISTE YA OTRO PORVEEDOR CON ESOS DATOS',16,1)
else
UPDATE PROVEEDOR
SET NombreCompaia = @nomcompa , NombreContacto =@nomcontac ,Ruc
=@ruc,bancario=@Bancario,Telefono=@tele,Direccion=@dire,Email =@email ,Estado =@esta
WHERE IdProveedor= @ID
END
GO
/****** Object: StoredProcedure [dbo].[PA_EditarTipoProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_EditarTipoProducto]
@ID int,
@nom varchar(20),
@estado tinyint
as
begin
if exists ( select *from TIPO_PRODUCTO
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom and Id_TipoProducto <> @ID)
raiserror('NO SE PUEDE EDITAR EL TIPO DE PRODUCTO ! YA EXISTE !',16,1)
else
UPDATE TIPO_PRODUCTO
SET Nombre = @nom ,Estado= @estado
WHERE Id_TipoProducto = @ID
END
GO
/****** Object: StoredProcedure [dbo].[PA_EditarUsuario] Script Date: 18/12/2014 03:48:39

p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_EditarUsuario]
@ID int,
@nom varchar(20),
@pass varchar(20),
@idtipo int,
@NomApe varchar(50),
@dni char(8),
@telefono varchar(9),
@direccion varchar(50),
@estado VARCHAR(10)
as
begin
if exists ( select *from Usuario
where replace(replace(replace(replace(replace(ltrim(upper(Nombre_Usuario )),
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom and IdUsuario <> @ID )
raiserror('NO PUEDE EDITAR EL NOMBRE YA EXISTE ',16,1)
else
UPDATE Usuario
SET Nombre_Usuario = @nom , Contrasea_Usuario =@pass ,IdTipoUsuario
=@idtipo,Nombre_ApellidoS =@NomApe ,Dni =@dni,telefono=@telefono ,Direccion =
@direccion ,Estado =@estado
WHERE IdUsuario = @ID
END
GO
/****** Object: StoredProcedure [dbo].[PA_EditaStockProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_EditaStockProducto]
@id int,
@stocktotal varchar(20)
as
update Producto
set Stock = @stocktotal
where IdProducto =@id
GO
/****** Object: StoredProcedure [dbo].[PA_GenerarNumeroOrdenCompra] Script Date:
18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_GenerarNumeroOrdenCompra]
as
DECLARE @codigo VARCHAR(6)
SET @codigo= (SELECT MAX(IdOrdenCompra ) FROM ORDEN_COMPRA )
SET @codigo = 'C' + RIGHT('000'+LTRIM(RIGHT (ISNULL( @codigo,'000'),6)+1),4)
SELECT @codigo AS NUMERO
GO
/****** Object: StoredProcedure [dbo].[PA_GenerarNumeroVenta] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create procedure [dbo].[PA_GenerarNumeroVenta]
as
DECLARE @codigo VARCHAR(6)
SET @codigo= (SELECT MAX(Id_Venta ) FROM VENTA )
SET @codigo = 'V' + RIGHT('000'+LTRIM(RIGHT (ISNULL( @codigo,'000'),6)+1),4)
SELECT @codigo AS NUMERO
GO
/****** Object: StoredProcedure [dbo].[PA_ListarGarantia] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarGarantia]
AS
BEGIN
SET NOCOUNT ON;
SELECT Id_Garantia ,NOMBRE,PRECIO,DESCRIPCION,ESTADO from GARANTIA
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarGarantiaActivo] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarGarantiaActivo]
AS
BEGIN
SET NOCOUNT ON;
SELECT Nombre +' = '+ CONVERT(varchar(10), Precio) AS DATOS ,Id_Garantia from
GARANTIA where Estado = 'ACTIVO'
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarMarcaProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarMarcaProducto]
AS
BEGIN
SET NOCOUNT ON;
SELECT Id_marca AS ID,NOMBRE,ESTADO from MARCA_PRODUCTO
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarMarcaProductoActivo] Script Date:
18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarMarcaProductoActivo]
AS
BEGIN
SET NOCOUNT ON;
SELECT * from MARCA_PRODUCTO where Estado = 1
END
GO
/****** Object: StoredProcedure [dbo].[Pa_ListarOrdenCompra] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[Pa_ListarOrdenCompra]
as
SELECT o.IdOrdenCompra ,o.NumeroOrdenComra AS Num_ORDEN_COMPRA,o.FECHA
,o.MontoTotal as MONTO_TOTAL,p.IdProveedor ,p.NombreCompaia AS
NOMBRE_COMPAIA ,p.RUC ,o.ESTADO
from ORDEN_COMPRA as o , PROVEEDOR as p WHERE o.IdProveedor = p.IdProveedor
GO
/****** Object: StoredProcedure [dbo].[PA_ListarProducto] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_ListarProducto]
AS
BEGIN
SET NOCOUNT ON;
SELECT P.IdProducto AS ID ,P.NOMBRE ,P.Id_TipoProducto,T.Nombre AS TIPO,P.Id_Marca
,M.Nombre AS MARCA ,P.PRECIO_COMPRA
,P.PRECIO_VENTA,P.STOCK,P.DESCRIPCION,P.ESTADO from PRODUCTO AS P ,

TIPO_PRODUCTO AS T ,MARCA_PRODUCTO AS M
WHERE p.Id_TipoProducto = t.Id_TipoProducto and p.Id_Marca = m.Id_Marca
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarProductoEstado] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_ListarProductoEstado]
AS
BEGIN
SET NOCOUNT ON;
SELECT P.IdProducto AS ID ,P.NOMBRE ,P.Id_TipoProducto,T.Nombre AS TIPO,P.Id_Marca
,M.Nombre AS MARCA ,P.PRECIO_COMPRA
,P.PRECIO_VENTA,P.STOCK,P.DESCRIPCION,P.ESTADO from PRODUCTO AS P ,
TIPO_PRODUCTO AS T ,MARCA_PRODUCTO AS M
WHERE p.Id_TipoProducto = t.Id_TipoProducto and p.Id_Marca = m.Id_Marca and p.Estado =
'ACTIVO'
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarProveedor] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarProveedor]
AS
BEGIN
SET NOCOUNT ON;
SELECT IdProveedor AS ID,NombreCompaia AS NOMBRE_COMPAIA,NombreContacto AS
NOMBRE_CONTACTO ,RUC,BANCARIO,TELEFONO,DIRECCION,EMAIL,ESTADO from
PROVEEDOR
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarProveedorEstado] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create PROCEDURE [dbo].[PA_ListarProveedorEstado]
AS
BEGIN
SET NOCOUNT ON;
SELECT IdProveedor AS ID,NombreCompaia ,NombreContacto ,Ruc,Telefono FROM
PROVEEDOR
WHERE Estado = 'ACTIVO'

END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarTipoProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarTipoProducto]
AS
BEGIN
SET NOCOUNT ON;
SELECT Id_TipoProducto AS ID,NOMBRE,ESTADO from TIPO_PRODUCTO
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarTipoProductoActivo] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarTipoProductoActivo]
AS
BEGIN
SET NOCOUNT ON;
SELECT * from TIPO_PRODUCTO where Estado = 1
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarTipoUsuario] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarTipoUsuario]
AS
BEGIN
SET NOCOUNT ON;
SELECT distinct IdTipoUsuario , Nombre
from Tipo_Usuario
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarUsuario] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_ListarUsuario]
AS
BEGIN
SET NOCOUNT ON;
SELECT u.IdUsuario AS ID,u.Nombre_Usuario AS Usuario,u.Contrasea_Usuario as
Contrasea,u.IdTipoUsuario,t.Nombre ,u.Nombre_Apellidos ,u.dni as DNI
,u.Telefono ,u.Direccion,u.Estado from Usuario as u , TIPO_USUARIO as t where
u.IdTipoUsuario = t.IdTipoUsuario
END
GO
/****** Object: StoredProcedure [dbo].[PA_ListarVentas] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_ListarVentas]
as
SELECT v.Id_Venta ,v.NumeroVenta ,v.FECHA ,v.MontoTotal,t.Nombre as DOCUMENTO,
v.NOMBRES ,v.DniRuc FROM VENTA as v ,TIPO_DOCUMENTO as t
where v.IdTipoDocumento = t.IdTipoDocumento and v.Fecha = GETDATE ()
GO
/****** Object: StoredProcedure [dbo].[PA_LOGIN] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
CREATE PROCEDURE [dbo].[PA_LOGIN]
@nombre VARchar(20),
@clave VARchar(20),
@validar bit output
as
declare @contar int
select @contar=count(*) from USUARIO
where Nombre_Usuario =@nombre and Contrasea_Usuario = @clave and Estado = 'ACTIVO'
if @contar>0
set @validar=1
else
set @validar =0
GO
/****** Object: StoredProcedure [dbo].[PA_RegistraGarantia] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistraGarantia]
@nom varchar(20),
@precio decimal(8,2),
@des varchar(50),
@estado varchar(10)
as
begin
if exists ( select *from GARANTIA
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom )
raiserror('EL NOMNRE DE GARANTIA YA EXISTE ',16,1)
else
insert into GARANTIA (nombre,PRECIO,DESCRIPCION,estado)
values(@nom,@PRECIO,@DES,@estado )
declare @cantidad as bigint
select @cantidad=coalesce(max([id_Garantia]), 0) from [dbo].[GARANTIA] ;
DBCC CHECKIDENT ('[dbo].[GARANTIA]', RESEED, @cantidad)
END
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarDetalleOrdenCompra] Script Date:
18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistrarDetalleOrdenCompra]
@idOrden int,
@idpro int,
@cantidad int,
@monto decimal(8,2)
as
insert into DETALLE_ORDEN_COMPRA (IdOrdenCompra,Cantidad ,Monto ,IdProducto )
values(@idOrden ,@cantidad ,@monto ,@idpro )
declare @cantida as bigint
select @cantida=coalesce(max([IdDetalleOrdenCompra]), 0) from [dbo].
[DETALLE_ORDEN_COMPRA] ;
DBCC CHECKIDENT ('[dbo].[DETALLE_ORDEN_COMPRA]', RESEED, @cantida)
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarDetalleVenta] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create procedure [dbo].[PA_RegistrarDetalleVenta]
@idventa int,
@idpro int,
@idGara int,
@cantidad int,
@total decimal(8,2),
@monto decimal(8,2)
as
insert into DETALLE_VENTA (Id_Venta ,IdProducto ,IdGarantia ,Cantidad ,Total ,Monto )
values(@idventa ,@idpro ,@idGara ,@cantidad ,@total ,@monto )
declare @cantida as bigint

select @cantida=coalesce(max([IdDetalleVenta]), 0) from [dbo].[DETALLE_VENTA] ;
DBCC CHECKIDENT ('[dbo].[DETALLE_VENTA]', RESEED, @cantida)
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarMarcaProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create procedure [dbo].[PA_RegistrarMarcaProducto]
@nom varchar(20),
@estado tinyint
as
begin
if exists ( select *from MARCA_PRODUCTO
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom )
raiserror('EL NOMNRE DE MARCA DEL PRODUCTO YA EXISTE ',16,1)
else
insert into MARCA_PRODUCTO (nombre,estado)
values(@nom,@estado )
select @cantidad=coalesce(max([id_Marca]), 0) from [dbo].[MARCA_PRODUCTO] ;
DBCC CHECKIDENT ('[dbo].[MARCA_PRODUCTO]', RESEED, @cantidad)
END
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarOrdenCompra] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistrarOrdenCompra]
@idprove int,
@idusuario int,
@numero varchar(10),
@MontoTotal decimal(8,2),
@estado char(10),
@des varchar(max)
as
insert into ORDEN_COMPRA (idproveedor,IdUsuario ,NumeroOrdenComra
,MontoTotal,Fecha ,Estado ,descripcion)
values(@idprove ,@idusuario ,@numero ,@MontoTotal,GETDATE(),@estado ,@des)
select @cantidad=coalesce(max([idOrdenCompra]), 0) from [dbo].[ORDEN_COMPRA] ;
DBCC CHECKIDENT ('[dbo].[ORDEN_COMPRA]', RESEED, @cantidad)
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarProducto] Script Date: 18/12/2014

03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
create procedure [dbo].[PA_RegistrarProducto]
@Nom varchar(40),
@des varchar(max),
@precio_compra decimal(8,2),
@precio_venta decimal(8,2),
@stock int,
@esta varchar(10),
@idtipo int,
@idmarca int
as
begin
if exists ( select *from PRODUCTO
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom )
raiserror('EL NOMNRE DEL PRODUCTO YA EXISTE ',16,1)
else
insert into PRODUCTO (Nombre,Descripcion ,Precio_Compra ,Precio_Venta ,Stock
,Estado,Id_TipoProducto,Id_Marca )
values(@Nom,@des ,@precio_compra ,@precio_venta,@stock,@esta,@idtipo,@idmarca )
select @cantidad=coalesce(max([idPRODUCTO]), 0) from [dbo].[PRODUCTO] ;
DBCC CHECKIDENT ('[dbo].[PRODUCTO]', RESEED, @cantidad)
END
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarProveedor] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistrarProveedor]
@NomCompa varchar(30),
@nomComtac varchar(30),
@RUC char(11),
@Bancario varchar(50),
@tele char(9),
@dire Varchar(50),
@email Varchar(50),
@esta varchar(10)
as
begin
if exists ( select *from PROVEEDOR
where replace(replace(replace(replace(replace(ltrim(upper(NombreCompaia )),
'','A'),'','E'),'','I'),'','O'),'','U')
= @NomCompa or Ruc = @RUC )
raiserror('EL DATO YA EXISTE EN LA BASE DE DATOS',16,1)

else
insert into PROVEEDOR
(NombreCompaia,NombreContacto,Ruc,Bancario,Telefono,Direccion,Email ,Estado )
values(@NomCompa ,@nomComtac,@RUC,@Bancario ,@tele,@dire,@email ,@esta )
select @cantidad=coalesce(max([idProveedor]), 0) from [dbo].[PROVEEDOR] ;
DBCC CHECKIDENT ('[dbo].[PROVEEDOR]', RESEED, @cantidad)
END
GO
/****** Object: StoredProcedure [dbo].[PA_RegistrarVenta] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistrarVenta]
@idusuario int,
@idtipo int,
@nombres varchar(30),
@dniruc varchar(10),
@NumeroVenta varchar(10),
@MontoTotal decimal(8,2)
as
insert into VENTA(IdUsuario ,IdTipoDocumento ,Nombres ,DniRuc,NumeroVenta
,MontoTotal,Fecha)
values(@idusuario ,@idtipo ,@nombres ,@dniruc ,@NumeroVenta ,@MontoTotal,GETDATE())
select @cantidad=coalesce(max([id_Venta]), 0) from [dbo].[VENTA]
DBCC CHECKIDENT ('[dbo].[VENTA]', RESEED, @cantidad)
GO
/****** Object: StoredProcedure [dbo].[PA_RegistraTipoProducto] Script Date: 18/12/2014
03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistraTipoProducto]
@nom varchar(20),
@estado tinyint
as
begin
if exists ( select *from TIPO_PRODUCTO
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom )
raiserror('EL NOMNRE DE TIPO DE PRODUCTO YA EXISTE ',16,1)
else
insert into TIPO_PRODUCTO (nombre,estado)
values(@nom,@estado )

select @cantidad=coalesce(max([id_TipoProducto]), 0) from [dbo].[TIPO_PRODUCTO] ;
DBCC CHECKIDENT ('[dbo].[TIPO_PRODUCTO]', RESEED, @cantidad)
END
GO
/****** Object: StoredProcedure [dbo].[PA_RegistraUsuario] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE procedure [dbo].[PA_RegistraUsuario]
@nom varchar(20),
@pass varchar(20),
@idtipo int,
@NomApe varchar(50),
@dni char(8),
@telefono varchar(9),
@direccion varchar(50),
@estado VARCHAR(10)
as
begin
if exists ( select *from Usuario
where replace(replace(replace(replace(replace(ltrim(upper(Nombre_Usuario )),
'','A'),'','E'),'','I'),'','O'),'','U')
= @nom )
raiserror('EL USUARIO YA EXISTE EN LA BASE DE DATOS',16,1)
else
insert into usuario ( Nombre_Usuario ,Contrasea_Usuario ,IdTipoUsuario,Nombre_ApellidoS
,Dni,Telefono,Direccion,Estado )
values(@nom,@pass ,@idtipo,@NomApe ,@dni ,@telefono,@direccion,@estado )
select @cantidad=coalesce(max([IdUsuario]), 0) from [dbo].[Usuario] ;
DBCC CHECKIDENT ('[dbo].[usuario]', RESEED, @cantidad)
END
GO
/****** Object: Table [dbo].[DETALLE_ORDEN_COMPRA] Script Date: 18/12/2014 03:48:39
p.m. ******/
SET ANSI_NULLS ON
GO
GO
CREATE TABLE [dbo].[DETALLE_ORDEN_COMPRA](
[IdDetalleOrdenCompra] [int] IDENTITY(1,1) NOT NULL,
[IdOrdenCompra] [int] NOT NULL,
[IdProducto] [int] NOT NULL,
[Cantidad] [int] NOT NULL,
[Monto] [decimal](8, 2) NOT NULL,
CONSTRAINT [PK_DETALLE_ORDEN_COMPRA] PRIMARY KEY CLUSTERED
(
[IdDetalleOrdenCompra] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY =

OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
/****** Object: Table [dbo].[DETALLE_VENTA] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
CREATE TABLE [dbo].[DETALLE_VENTA](
[IdDetalleVenta] [int] IDENTITY(1,1) NOT NULL,
[Id_Venta] [int] NOT NULL,
[IdProducto] [int] NOT NULL,
[IdGarantia] [int] NOT NULL,
[Cantidad] [int] NOT NULL,
[Total] [decimal](8, 2) NOT NULL,
[Monto] [decimal](8, 2) NOT NULL,
CONSTRAINT [PK_DETALLE_VENTA] PRIMARY KEY CLUSTERED
(
[IdDetalleVenta] ASC
) ON [PRIMARY]
GO
/****** Object: Table [dbo].[GARANTIA] Script Date: 18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[GARANTIA](
[Id_Garantia] [int] IDENTITY(1,1) NOT NULL,
[Nombre] [varchar](30) NOT NULL,
[Descripcion] [varchar](50) NULL,
[Precio] [decimal](8, 2) NULL,
[Estado] [varchar](10) NOT NULL,
CONSTRAINT [PK_GARANTIA] PRIMARY KEY CLUSTERED
(
[Id_Garantia] ASC
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
/****** Object: Table [dbo].[MARCA_PRODUCTO] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[MARCA_PRODUCTO](
[Id_Marca] [int] IDENTITY(1,1) NOT NULL,
[Estado] [tinyint] NOT NULL,
CONSTRAINT [PK_MARCA_PRODUCTO] PRIMARY KEY CLUSTERED
(
[Id_Marca] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[ORDEN_COMPRA] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[ORDEN_COMPRA](
[IdOrdenCompra] [int] IDENTITY(1,1) NOT NULL,
[IdProveedor] [int] NOT NULL,
[IdUsuario] [int] NOT NULL,
[NumeroOrdenComra] [varchar](10) NOT NULL,
[MontoTotal] [decimal](8, 2) NOT NULL,
[Fecha] [date] NOT NULL,
CONSTRAINT [PK_ORDEN_COMPRA] PRIMARY KEY CLUSTERED
(
[IdOrdenCompra] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[PRODUCTO] Script Date: 18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[PRODUCTO](

[IdProducto] [int] IDENTITY(1,1) NOT NULL,
[Id_TipoProducto] [int] NOT NULL,
[Id_Marca] [int] NOT NULL,
[Precio_Compra] [decimal](8, 2) NOT NULL,
[Precio_Venta] [decimal](8, 2) NOT NULL,
[Stock] [int] NOT NULL,
CONSTRAINT [PK_PRODUCTO] PRIMARY KEY CLUSTERED
(
[IdProducto] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[PROVEEDOR] Script Date: 18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[PROVEEDOR](
[IdProveedor] [int] IDENTITY(1,1) NOT NULL,
[NombreCompaia] [varchar](30) NOT NULL,
[NombreContacto] [varchar](30) NOT NULL,
[Ruc] [char](11) NOT NULL,
[Bancario] [varchar](50) NULL,
[Telefono] [char](9) NULL,
[Direccion] [varchar](50) NULL,
[Email] [varchar](50) NULL,
CONSTRAINT [PK_PROVEEDOR] PRIMARY KEY CLUSTERED
(
[IdProveedor] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[TIPO_DOCUMENTO] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[TIPO_DOCUMENTO](
[IdTipoDocumento] [int] IDENTITY(1,1) NOT NULL,
CONSTRAINT [PK_TIPO_DOCUMENTO] PRIMARY KEY CLUSTERED
(
[IdTipoDocumento] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[TIPO_PRODUCTO] Script Date: 18/12/2014 03:48:39 p.m.
******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[TIPO_PRODUCTO](
[Id_TipoProducto] [int] IDENTITY(1,1) NOT NULL,
[Nombre] [varchar](30) NULL,
[Estado] [tinyint] NULL,
CONSTRAINT [PK_TIPO_PRODUCTO] PRIMARY KEY CLUSTERED
(
[Id_TipoProducto] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[TIPO_USUARIO] Script Date: 18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[TIPO_USUARIO](
[IdTipoUsuario] [int] IDENTITY(1,1) NOT NULL,
[Nombre] [char](15) NOT NULL,
CONSTRAINT [PK_TIPO_USUARIO] PRIMARY KEY CLUSTERED
(
[IdTipoUsuario] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[USUARIO] Script Date: 18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[USUARIO](
[IdUsuario] [int] IDENTITY(1,1) NOT NULL,
[Nombre_Usuario] [varchar](20) NOT NULL,
[Contrasea_Usuario] [varchar](20) NOT NULL,
[IdTipoUsuario] [int] NOT NULL,
[Nombre_Apellidos] [varchar](50) NOT NULL,
[Dni] [char](8) NOT NULL,
[Telefono] [char](9) NULL,
[Direccion] [varchar](50) NULL,
CONSTRAINT [PK_USUARIO] PRIMARY KEY CLUSTERED
(
[IdUsuario] ASC
) ON [PRIMARY]
GO
GO
/****** Object: Table [dbo].[VENTA] Script Date: 18/12/2014 03:48:39 p.m. ******/
SET ANSI_NULLS ON
GO
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[VENTA](
[Id_Venta] [int] IDENTITY(1,1) NOT NULL,
[IdUsuario] [int] NOT NULL,
[IdTipoDocumento] [int] NOT NULL,
[Nombres] [varchar](50) NOT NULL,
[DniRuc] [varchar](20) NOT NULL,
[NumeroVenta] [varchar](10) NOT NULL,
[MontoTotal] [decimal](8, 2) NOT NULL,
[Fecha] [date] NOT NULL,
CONSTRAINT [PK_VENTA] PRIMARY KEY CLUSTERED
(
[Id_Venta] ASC
) ON [PRIMARY]
GO
GO
USE [master]
GO
ALTER DATABASE [AUTOPARTES] SET READ_WRITE
GO
CONCLUSIONES
En la planificacin de sistemas web se requiere el pleno conocimiento de los actores
(qu hacen y cmo hacen sus tareas) para disear, desarrollar e implantar
herramientas informticas.
Para aprovechar mejor los recursos humanos e informticas necesario contar con el
apoyo de todos los trabajadores desde el nivel jerrquico ms alto hasta el nivel
inferior, lo que har que el apoyo sea efectivo en el control y la fiscalizacin de los
problemas de la Empresa de Autopartes Yeshua.
La propuesta modular surge como respuesta a las necesidades formuladas por

Empresa de Autopartes Yeshua, cuyos estn dispuestos a invertir de acuerdo con sus
necesidades y compartir experiencias para reducir costos y tiempos y capacitar al
capital humano.
El costo del proyecto est ms que justificado y sustentado por los beneficios
tangibles e intangibles que brinda a la sociedad en su conjunto.
RECOMENDACIONES
Es recomendable que la gerencia establezca Normas de Control Interno que
permitan realizar constataciones fsicas de las mercaderas en forma peridica, para
tener un mejor control de cada uno de los artculos tanto en el proceso de compra y
venta de los mismos.
Se recomienda capacitar al personal previamente en el manejo del software, con la
finalidad de que todos se desempeen y cumplan eficazmente con las labores que
ejecutan, con una acertada toma de decisiones.
Se recomienda a la empresa utilizar los formatos proporcionados para la realizacin
de las proyecciones de compra de insumos y ventas. Dichos formatos permiten
manejar ordenadamente los costos de materia prima, mano de obra y carga fabril
por producto.
Los softwares compra y venta deben tener la posibilidad de cambiar la forma de la
contabilidad o la dinmica contable, de la misma forma el modo de presentacin de
los estados financieros. Por lo cual, es importante que el software pueda manejar
diversos criterios cuando el contador as lo requiera.
Antes de empezar a usar el software, es recomendable que el gerente de la empresa
revise contenido y la configuracin del mismo para que pueda trabajar sin
contratiempos ms adelante.
AGRADECIMIENTO
Agradecemos
al buen asesoramiento de
nuestro profesor el Ing. Valle Pelez Miguel

Arturo,
que
colaboracin
gracias
hemos
su
podido
paciencia
realizar
este
informe.
Del mismo modo agradecemos la participacin conjunta

de quienes colaboraron con nosotros de igual manera a
la empresa de Autopartes Yeshua por brindarnos su
gentil apoyo para hacer nuestras Practicas Pre II,
facilitando la recopilacin de informacin para as poder
enmarcar el proyecto.
BIBLIOGRAFIA
http://mat21.etsii.upm.es/ayudainf/aprendainf/Visualbasic6/vbasic60.pdf
http://www.freelibros.org/manual/visual-basic-guia-definitiva-del-programador-users.html
http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/bases-dedatos/P06_M2109_02151.pdf
https://www.youtube.com/playlist?list=PLhb0HTfDMZxQhFm1AXB1ToASJxiDBt3Bm
https://books.google.com.pe/books?
id=iXxI7pB8ntkC&pg=PA5&lpg=PA5&dq=libro+para+programa+en+asp.net&source=bl
&ots=oTmKTKLVW&sig=7hIyoZLyKwslF6An8VqMza8zxwY&hl=es&sa=X&ei=gtadVIn9IcOogwTGi4T
gCw&ved=0CCIQ6AEwAQ#v=onepage&q=libro%20para%20programa%20en
%20asp.net&f=false

Informe Del Sistema

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Informe Del Sistema

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD SAN PEDRO

Desarrollo de un aplicativo Web para administrar los procesos

Diseo de un aplicativo Web

Design a Web application

Practicas Pre Profesional II

Practicas Pre Profesional II

El presente trabajo de investigacin est basado en un anlisis objetivo y minucioso

Practicas Pre Profesional II

Practicas Pre Profesional II

Practicas Pre Profesional II

artefactos de anlisis y Reglas de Oro, diseo de interfaces y procesos de construccin. El

Practicas Pre Profesional II

5.1. ANTECEDENTES Y FUNDAMENTACIN CIENTFICA:

Mara Henao, Ana Quintero, en la Universidad Tecnolgica de Pereira en

Practicas Pre Profesional II

5.2. JUSTIFICACION DE LA INVESTIGACION

Mejor desempeo del personal en el proceso de atencin al cliente, el

Eficacia en el control de las ventas. El sistema permitir llevar a cabo el

Agilizar la contabilizacin de los procesos de la empresa.

Permitir a la empresa tener un control ms exacto de ingresos y egresos

Permitir reducir los costos en tiles de oficina y de personal, reduciendo el

Realizar un sistema capaz de controlar en primera instancia las necesidades bsicas

Optimizar servicios en base a sistemas que ayuden la distribucin de los clientes.

Disear una interfaz entendible capaz de facilitar el trabajo a los usuarios.

Practicas Pre Profesional II

5.4. MARCO REFERENCIAL

proporciona tres beneficios clave:

Una comunicacin clara

para apoyar Ingeniera de Sistemas. Como un lenguaje de modelado estndar, SysML

Relaciones de Uso, Herencia y Comunicacin.

Practicas Pre Profesional II

Practicas Pre Profesional II

ii. Diagramas de Clases

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Superior: Contiene el nombre de la Clase

Practicas Pre Profesional II

): Indica que el atributo o el mtodo ser visible tanto

dentro como fuera de la clase, es decir, es accesible desde todos lados.

): Indica que el atributo o el mtodo slo ser

accesible desde dentro de la clase (slo sus mtodos pueden acceder).

): Indica que el atributo o el mtodo no ser

accesible desde fuera de la clase, pero si podr ser accedido por

Practicas Pre Profesional II

mtodos y atributos, poseer las caractersticas y atributos visibles de la

En la figura se especifica que Auto y Camin heredan de Vehculo, es

Practicas Pre Profesional II

Dependencia o Instanciacin (uso):

iii. Diagrama de Objetos

iv. Diagrama de Secuencia

Practicas Pre Profesional II

Una lnea vertical que representa la secuencia de eventos que se

producen en un participante durante una interaccin, mientras el

Puede hacer que aparezca un smbolo de actor en la parte

de continuar. El diagrama muestra la llamada y el retorno. Los

mensajes sincrnicos se utilizan para representar llamadas de

Practicas Pre Profesional II

Un mensaje que no requiere una respuesta antes de que el

Un mensaje que vuelve a un participante que est esperando la

Un mensaje de un participante a s mismo. La aparicin de

ejecucin resultante aparece encima de la ejecucin de envo.

Un mensaje que crea un participante. Si un participante recibe

Un mensaje asincrnico a un participante desconocido o no