1

UNIVERSIDAD NACIONAL PEDRO RUIZ GALLO

CURSO:

Metodologa de la investigacin cientfica

TEMA:

Uso de la metodologa UML para desarrollar
un sistema informtico para la empresa Plsticos
Delgado ERIL.: Chiclayo J unio - Septiembre 2008.

ALUMNOS:

Farroan Beltrn Brenher
Clemente Salazar Reyes
Delgado Herrera, Wilder





Lambayeque, Septiembre Del 2008
FACULTAD DE CIENCIAS FSICAS Y
MATEMTICA
ESCUELA PROFESIONAL
ING. EN COMPUTACIN E INFORMTICA
C
O
M
P
U
T
A
C
I

N

2



I. ASPECTO INFORMATIVO:

1. TITULO:
Uso de la metodologa UML para desarrollar un sistema
informtico para la empresa Plsticos Delgado ERIL.: Chiclayo
Junio - Septiembre 2008.

2. AUTORES
o Farroan Beltrn, Brenher
Direccin : La Florida Mz L Lt 9-Chiclayo
E-mail : edherb@hotmail.com
o Salazar Reyes, Clemente
Direccin : Independencia #766-Chiclayo
E-mail : clemente_864@hotmail.com
o Delgado Herrera, Wilder
Direccin : Miguel Grau #199-Reque
E-mail : wilder_dh@hotmail.com

3. ASESOR
o Correa Cabanillas Max

5. LUGAR DE EJECUCION:

Empresa de plsticos Delgado EIRL.

6. TIEMPO DE DURACION:

3 meses aproximadamente

8. FECHA DE INICIO:
15 de Junio del 2008

9. FECHA DE FINALIZACION:
15 de Septiembre del 2008
3
II. ASPECTO DE LA INVESTIGACIN:

1. MARCO TEORICO

1.1. SITUACIN PROBLEMATICA:

Esta empresa cuenta con un sistema de control manual en las tres reas como son
ventas, compra, almacn, lo cual acarreaba muchos problemas y conflictos dentro de
la empresa y con el trato al cliente; debido a que exista cierta demora para
atenderlos, adems de no tener a su alcance la informacin adecuada de sus
productos y esto conlleva a que el cliente opte por retirarse.
Por estas causas el nivel de ingresos de la empresa Plsticos Delgado ha ido
disminuyendo da con da, lo cul podra conllevar a una total crisis.
Dicha empresa necesita una pronta integracin de sus procesos para el rpido
intercambio de informacin, promover o favorecer el buen manejo de sus recursos,
adems de facilitar el desempeo de labores de los empleados teniendo una
informacin actualizada la cual les permita tomar decisiones correctas.
Logrando as, convertirse en una empresa modelo slida y confiable, fortaleciendo el
respeto y la confianza de sus proveedores y clientes.

1.2 ANTECEDENTES:
Santacruz C. (2000) en su estudio de investigacin sobre SISTEMAS
INFORMATICOS COMO ALTERNATIVA DE MEJORAR LA CALIDAD DE
SERVICIO DE LA EMPRESA INVERNORTE, se encuentran las siguientes
conclusiones: los datos y la informacin adecuada para el desarrollo del proyecto
pueden usarse de una forma correcta y eficiente, gracias a la herramienta Lenguaje
de Modelado Unificado (UML), que permite el manejo adecuado y metodolgico
de la informacin, logrando as obtener un sistema acorde con lo que desea el
cliente. [1]
1.3 BASE TEORICA:

LENGUAJ E DE MODELADO UNI FI CADO (UML):

Es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la
actualidad; an cuando todava no es un estndar oficial, est respaldado por el
OMG (Object Management Group).
Es un lenguaje grfico para visualizar, especificar, construir y documentar un
sistema de software. UML ofrece un estndar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos de negocios y
funciones del sistema, y aspectos concretos como expresiones de lenguajes de
programacin, esquemas de bases de datos y componentes de software
reutilizables.
Es importante resaltar que UML es un "lenguaje" para especificar y no para
describir mtodos o procesos. Se utiliza para definir un sistema de software, para
detallar los artefactos en el sistema y para documentar y construir.
4
En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar
en una gran variedad de formas para dar soporte a una metodologa de desarrollo
de software (tal como el Proceso Unificado Racional), pero no especifica en s
mismo qu metodologa o proceso usar.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos
de las entidades representadas. [2]
DI AGRAMAS:
En UML hay 13 tipos diferentes de diagramas. Para comprenderlos de manera
concreta, a veces es til categorizar los jerrquicamente, como se muestra en la
figura de la derecha.

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

a) Diagrama 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 contenimiento.
Un diagrama de clases esta compuesto por los siguientes 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:


Relaciones entre Clases: Una clase puede interrelacionarse, ya sea entre dos
o ms clases (cada uno con caractersticas y objetivos diferentes).
Las relaciones entre clases pueden darse por herencia, composicin,
agregacin, asociacin y uso.

Herencia (Especializacin/Generalizacin): Se representa de esta
forma:
Indica que una subclase hereda los mtodos y atributos especificados
por una Sper Clase, por ende la Subclase adems de poseer sus
propios mtodos y atributos, poseer las caractersticas y atributos
visibles de la Sper Clase (public y protected), ejemplo:

5


Agregacin: Se representa de esta forma:
Para modelar objetos complejos, 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:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de
vida del objeto incluido esta condicionado por el tiempo de vida del
que lo incluye.
Por Referencia: Es un tipo de relacin dinmica, en donde el
tiempo de vida del objeto incluido es independiente del que lo
incluye. Un Ejemplo es el siguiente:


Asociacin: Se representa de esta forma:
La relacin entre clases conocida como Asociacin, permite asociar
objetos que colaboran entre si. Cabe destacar que no es una relacin
fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Ejemplo:

6
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio
una orden de compra solo puede tener asociado un cliente. [3]
Dependencia (uso): Se representa de esta forma:
Representa un tipo de relacin muy particular, en la que una clase es
instanciada (su instanciacin es dependiente de otro objeto/clase). Se
denota por una flecha punteada.
El uso ms particular de este tipo de relacin es para denotar la
dependencia que tiene una clase de otra, como por ejemplo una aplicacin
grafica que instancia una ventana (la creacin del Objeto Ventana esta
condicionado a la instanciacin proveniente desde el objeto Aplicacin):



b) Diagrama de componentes
Un diagrama de componentes representa la separacin de un sistema de
software en componentes fsicos (por ejemplo archivos, cabeceras, mdulos,
paquetes, etc.) y muestra las dependencias entre estos componentes.

Debido a que estos son ms parecidos a los diagramas de casos de usos estos
son utilizados para modelar la vista esttica 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.
En l situaremos libreras, tablas archivos, ejecutables y documentos que
formen parte del sistema.
Uno de los usos principales es que puede servir para ver qu componentes
pueden compartirse entre sistemas o entre diferentes partes de un sistema.
c) Diagrama de objetos
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. Una
diferencia con los diagramas de clase es que el compartimiento de arriba va en
la forma, Nombre de objeto: Nombre de clase. Por ejemplo, Miguel: Persona.

d) Diagrama de despliegue
El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de
Modelado que se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus componentes.
7

Los elementos usados por este tipo de diagrama son nodos (representados como
un prisma), componentes (representados como una caja rectangular con dos
protuberancias del lado izquierdo) y asociaciones.

En el UML los componentes ya no estn dentro de nodos. En cambio, puede
haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o
una base de datos construida o modificada en un proyecto. Estos artefactos
implementan colecciones de componentes.

La mayora de las veces el modelado de la vista de despliegue implica modelar
la topologa del hardware sobre el que se ejecuta el sistema. Aunque UML no
es un lenguaje de especificacin hardware de propsito general, se ha diseado
para modelar muchos de los aspectos hardware de un sistema a un nivel
suficiente para que un ingeniero software pueda especificar la plataforma sobre
la que se ejecuta el software del sistema.

e) Diagrama de paquetes
Un diagrama de paquetes muestra como un sistema est dividido en
agrupaciones lgicas mostrando las dependencias entre esas agrupaciones.

Dado que normalmente un paquete est pensado como un directorio, los
diagramas de paquetes suministran una descomposicin de la jerarqua lgica
de un sistema.

Los Paquetes estn normalmente organizados para maximizar la coherencia
interna dentro de cada paquete y minimizar el acoplamiento externo entre los
paquetes. Con estas lneas maestras sobre la mesa, los paquetes son buenos
elementos de gestin. Cada paquete puede asignarse a un individuo o a un
equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo
requerido. [4]

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

a) Diagrama de actividades
Un diagrama de actividades representa los flujos de trabajo paso a paso de
negocio y operacionales de los componentes en un sistema. Un Diagrama
de Actividades muestra el flujo de control general.

En UML 1.x, un diagrama de Actividades es una variacin del Diagrama de
estados UML donde los "estados" representan operaciones, y las
transiciones representan las actividades que ocurren cuando la operacin es
completa.

El diagrama de Actividades UML 2.0, mientras que es similar en aspecto al
diagrama de Actividades UML 1.x, ahora tiene semnticas basadas en redes
8
de Petri. En UML 2.0, el diagrama general de Interaccin est basado en el
diagrama de Actividades.

b) Diagrama de casos de uso
Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de
vista de un observador externo, debido a esto, un diagrama de este tipo
generalmente es de los ms sencillos de interpretar en UML, ya que su
razn de ser se concentra en un Que hace el sistema, a diferencia de otros
diagramas UML que intentan dar respuesta a un Como logra su
comportamiento el sistema.

Ejemplo:




c) Diagrama de estados
Un Diagrama de Estados muestra la secuencia de estados por los que pasa
bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el
sistema. En l se indican qu eventos hacen que se pase de un estado a otro
y cules son las respuestas y acciones que genera.

En cuanto a la representacin, un diagrama de estados es un grafo cuyos
nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con
los nombres de los eventos.

Un estado se representa como una caja redondeada con el nombre del
estado en su interior. Ejemplo:

9

Un diagrama de estados puede representar ciclos continuos o bien una vida
finita, en la que hay un estado inicial de creacin y un estado final de
destruccin (finalizacin del caso de uso o destruccin del objeto). [5]

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

a) Diagrama de secuencia
Un diagrama de Secuencia muestra una interaccin ordenada segn la
secuencia temporal de eventos. En particular, muestra los objetos
participantes en la interaccin y los mensajes que intercambian ordenados
segn su secuencia en el tiempo.

El eje vertical representa el tiempo, y en el eje horizontal se colocan los
objetos y actores participantes en la interaccin, sin un orden prefijado.
Cada objeto o actor tiene una lnea vertical, y los mensajes se representan
mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo.
Se pueden colocar etiquetas (como restricciones de tiempo, descripciones
de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones
o activaciones a las que se refieren.






10

b) Diagrama de colaboracin
Un Diagrama de Colaboracin muestra una interaccin organizada
basndose en los objetos que toman parte en la interaccin y los enlaces
entre los mismos (en cuanto a la interaccin se refiere).

A diferencia de los Diagramas de Secuencia, los Diagramas de
Colaboracin muestran las relaciones entre los roles de los objetos. La
secuencia de los mensajes y los flujos de ejecucin concurrentes deben
determinarse explcitamente mediante nmeros de secuencia.

Ejemplo:



En cuanto a la representacin, un Diagrama de Colaboracin muestra a una
serie de objetos con los enlaces entre los mismos, y con los mensajes que se
intercambian dichos objetos. Los mensajes son flechas que van junto al
enlace por el que circulan, y con el nombre del mensaje y los parmetros
entre parntesis.

Cada mensaje lleva un nmero de secuencia que denota cul es el mensaje
que le precede, excepto el mensaje que inicia el diagrama, que no lleva
nmero de secuencia. [6]



11
2. PROBLEMA:
Cul es la metodologa que permitir desarrollar un sistema informtico para las reas
de compra, venta y almacn de la empresa Plsticos Delgado EIRL?

3. HIPOTESIS:
La metodologa que permitir desarrollar un sistema informtico para las reas de
compra, venta y almacn de la empresa Plsticos Delgado EIRL ser el UML
(Lenguaje de Modelamiento Unificado).

4. OBJETIVOS:
4.1 OBJETIVO GENERAL:
Desarrollar el sistema informtico utilizando la metodologa UML, para la empresa
Plsticos Delgado.

4.2 OBJETIVOS ESPECIFICOS:
Identificar la informacin que la empresa genera.
Hacer un inventario de las necesidades que tiene la empresa en las reas de
compra, venta y almacn.
Determinar el nmero de clientes atendidos por un da.
Desarrollar el Sistema de Informacin.
Poner a prueba el sistema.




5. JUSTIFICACIN E IMPORTANCIA DEL ESTUDIO:

Este proyecto se desarrollara porque por que la empresa con el sistema manual
que posee para controlar sus reas de venta compra y almacn, hace que tenga
problemas, retrasos y conflictos entre los clientes y tambin dentro de la
empresa.
12
Al desarrollar el presente proyecto daremos un alcance para que el manejo de la
empresa sea ms ordenada y eficiente, proyectndonos a que la empresa mejore
su prestigio as como tambin el nivel de sus ingresos.

6. DEFINICION DE TERMINOS Y CONCEPTOS:

Sistema informtico: Sntesis de hardware y software que trabajan unidos para
desarrollar el programa eficientemente.

Lenguaje de programacin: Un lenguaje de programacin es una tcnica
estndar de comunicacin que permite expresar las instrucciones que han de ser
ejecutadas en una computadora. Consiste en un conjunto de reglas sintcticas y
semnticas que definen un lenguaje informtico.


III.- MARCO METODOLOGICO:

1. TIPO DE INVESTIGACIN:
Tecnolgico
2. TIPO DE VARIABLES:
Variable independiente: UML
Variable dependiente: Sistema informtico

3. ESQUEMA DE CONTENIDO:
I.- RESUMEN:

CAPITULO I
1. MARCO TEORICO

1.1 SITUACIN PROBLEMATICA
1.2 ANTECEDENTES
1.3 BASE TEORICA

2. PROBLEMA
3. HIPOTESIS
4. OBJETIVOS
5. JUSTIFICACIN E IMPORTANCIA DEL ESTUDIO
6. DEFINICION DE TERMINOS Y CONCEPTOS

CAPITULO II
1. TIPO DE INVESTIGACIN
2. TIPO DE VARIABLES
3. ESQUEMA DE CONTENIDO
13

CAPITULO III
1. RESULTADOS
CAPITULO IV
1. CONSLUSIONES Y RECOMENDACIONES

IV.- ASPECTO ADMINISTRATIVO:

1. CRONOGRAMA DE ACTIVIDADES DEL PROYECTO:




ACTIVIDADES

JUNIO JULIO AGOSTO SEPTIEMBRE
3 4 1 2 3 4 1 2 3 4 1 2 3 4
1.-Identificacin de bibliografa
2.-Elaboracin del proyecto
3.-Presentacin y aprobacin del proyecto
4.-Desarrollo del proyecto
5.-Presentacin del informe
6.-Aprobacin del informe
14
2. PRESUPUESTO:
BIENES:
2 CDS S/. 7.00
1 Libro S/. 75.00
de millar de papel bond S/. 10.00
SERVICIOS:
Internet S/. 15.00
Tipos S/. 15.00
Escaneo S/. 5.00
Pasajes S/. 10.00
Copias S/. 10.00
Otros S/. 15.00
Total S/.162.00

3. FINANCIAMIENTO:
El proyecto ser autofinanciado por los investigadores.

V. RESEA BIBLIOGRAFICA:

1. Santacruz C.: Sistemas informticos como alternativa de mejorar la calidad de
servicio de la empresa invernorte, Chiclayo 2000.

2. Raymond McLeod J.: Sistemas de informacin gerencial, Publicado en 2003.

3. http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado#Diagramas

4. Booch G., Rumbaugh J., Jacobson I.: El Lenguaje Unificado de Modelado,
Publicado en 1999.
5. Cheesman J., Hans D.:Componentes UML, Publicado en Massachusetts, 2001.

6. Terry Q.: Modelando con Rational Rose y UML, Publicado en 2002