PROFESOR:

Tacubeo
EQUIPO:
Hernndez Amaro Jos Adalberto
Ramrez Tllez Gerardo
Muoz Eduardo
MATERIA:
Ingeniera de Software
GRUPO:
4601
CARRERA:
Ing. En Sistemas Computacionales
SEMESTRE:
6

Tabla de contenido
Objetivos........................................................................................................ 3
Marco terico.................................................................................................. 4
UML............................................................................................................. 4
RESUMEN....................................................................................................... 5
UML................................................................................................................ 6
DIAGRAMA DE CASOS DE USO....................................................................6
SISTEMA......................................................................................................... 7
Casos de uso............................................................................................... 7
ACTORES..................................................................................................... 8
RELACIONES................................................................................................ 8
DIAGRAMAS DE SECUENCIAS.........................................................................9
ROL DE LA CLASE........................................................................................ 9
ACTIVACION................................................................................................. 9
MENSAJES.................................................................................................. 10
LINEAS DE VIDA......................................................................................... 11
DESTRUCCION DE OBJETOS......................................................................11
LOOPS....................................................................................................... 12
DIAGRAMAS DE CLASE................................................................................. 12
CLASE ABSTRACTA.................................................................................... 13
CLASE AVIONES......................................................................................... 13
ASOCIACIONES.......................................................................................... 14
MULTIPLICIDAD.......................................................................................... 14
ASOCIACION TRIPARTITA........................................................................... 15
COMPOSICION Y AGREGACION..................................................................15
Pres Servi Game........................................................................................ 16
1er DIAGRAMA DE CASO DE USO...................................................................18
DIAGRAMA DE SECUENCIA........................................................................20
2do DIAGRAMA DE CASO DE USO..................................................................21
DIAGRAMA DE SECUENCIA........................................................................23
3er DIAGRAMA DE CASO DE USO...................................................................24
DIAGRAMA DE SECUENCIA........................................................................25
Diagrama de estado....................................................................................... 26
Diagrama de paquetes................................................................................... 26
Punto de venta.............................................................................................. 27
Bibliografa................................................................................................... 28

Objetivos
Objetivo General:
Realizar un sistema que permita tener un mayor control sobre los
productos.

Contar con la presencia de personal altamente capacitado para

poder aclarar las dudas del cliente
Aumentar el porcentaje de exportaciones
Incrementar la productividad
Alcanzar un mayor alcance a nivel nacional e internacional
Aumentar las ventas
Mantenerse actualizado al tanto de nuevos productos

Objetivo especfico:

El cliente evitara esperar largo tiempo en poder finalizar con su

compra

El cliente quedara satisfecho y tonalmente seguro de la compra a

realizar

Tener suficiente publicidad acerca de nuestro producto

Reducir los costos de nuestros paquetes

Expandir nuestros puntos de venta, abriendo ms sucursales

Aumentar las ventas anuales un 50%

El cliente podr disfrutar de los nuevos beneficios recin

actualizados

Duplicar la produccin para que no haya agotamiento de

productos.

Marco terico
UML
La creacin de algn sistema requiere de anlisis minucioso, pues de ello
depender el funcionamiento del mismo. Una mala planeacin en el anlisis
podra traer consecuencias desagradables.
Para efectuar el modelado de un sistema existen muchas herramientas, sin
embargo, grandes desarrolladores han unidos esfuerzos para unificar
criterios, estos criterios se hicieron convergentes desde la creacin de UML;
inicialmente, se puede pensar que UML es un lenguaje de programacin,
pero no es as, simplemente es una herramienta indispensable que permite
el modelado de un sistema en una descripcin muy general o muy
particular, segn el inters o la necesidad de detallarlo.
En este proyecto se realiz tanto el modelamiento como la implantacin del
sistema, pero, considerando que para que la implantacin se aproxime al
modelamiento inicial, es necesario que quien desarrolle el sistema en algn
lenguaje en particular, entienda los conceptos de UML, sus diagramas,
relaciones y elementos, ya que sin ese conocimiento previo es poco
probable una relacin intrnseca del modelo y sistema.
En UML a su vez, se puede detallar la estructura esttica y el
comportamiento dinmico de un sistema permitiendo tener vistas que
anteriormente no haba forma de especificarlas, ahora es posible con estos
diagramas, definir desde aspectos de interaccin de software y procesos
hasta la relacin existente entre el equipo perifrico. Es importante
mencionar que, un sistema se modela como una coleccin de objetos
discretos que interactan para realizar un trabajo que finalmente beneficie
al usuario final.
Los diagramas UML varan, as no es necesario que se utilicen todos los
diagramas para modelar un sistema, aun as entre los diagramas
recomendados para cualquier sistema fueron utilizados en este trabajo, son
los diagramas de clase y diagramas de caso de uso con sus respectivas
interacciones y adems para un sistema cliente-servidor, como es este el
caso, dependiendo de la complejidad del mismo.
El tiempo dedicado a la realizacin de los diagramas es proporcional al
tamao del producto a realizar, as en la realizacin del modelado es comn,
realizar diagramas y corregir, replantear sobre el sistema que es necesario,
aunque conforme se avanza en el modelado, las correcciones van siendo
mnimas, hasta llegar a lo representativo del sistema.

RESUMEN
En este manual se explica cmo poder resolver un diagrama de caso de uso
as como la importancia a lo que se basa cada uno de los siguientes
diagramas:
Diagrama de caso de uso
Diagrama de secuencia
Cada uno explicando la importancia para poder ponerlo en prctica dentro
de nuestra empresa, siguiendo paso a paso podemos llegar a la conclusin
de poder formar cada uno de nuestros diagramas con sus respectivos
actores.

UML
UML est compuesto por diversos elementos grficos que se combinan para
conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas
para combinar estos elementos. La finalidad de los diagramas es presentar
diversas perspectivas de un sistema, a las cuales se les conoce como modelo.
(Longman, 1998 )
El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos significan. Mientras
que ha habido muchas notaciones y mtodos usados para el diseo orientado
a objetos, ahora los modeladores slo tienen que aprender una nica notacin.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real. (BOOCH,
2000)

DIAGRAMA DE CASOS DE USO

Los casos de uso son una tcnica para especificar el comportamiento de un
sistema:
Un caso de uso es una secuencia de interacciones entre un sistema y alguien
o algo que usa alguno de sus servicios.
Todo sistema de software ofrece a su entorno aquellos que lo usan una serie
de servicios. Un caso de uso es una forma de expresar cmo alguien o algo
externo a un sistema lo usa. Cuando decimos alguien o algo hacemos
referencia a que los sistemas son usados no slo por personas, sino tambin
por otros sistemas de hardware y software.
Por ejemplo, un sistema de ventas, si pretende tener xito, debe ofrecer un
servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario
accede a este servicio, podemos decir que est ejecutando el caso de uso
ingresando pedido. (Gutierrez, Abril 2011)

SISTEMA

El rectngulo representa los lmites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los lmites del sistema.

Casos de uso

Se representan con valos. La etiqueta

sistema.

en el valo indica la funcin del

ACTORES

Los actores son los usuarios de un sistema.

Un actor puede ser cualquier cosa que se comunica (interacciona) con el
sistema y que es externo a l.
Los actores no necesariamente coinciden con los usuarios. Un usuario
puede interpretar distintos roles, correspondientes a distintos actores.
Los actores representan papeles (ROLES) que interpretan personas,
perifricos u otros sistemas cuando el sistema est en uso.
Un actor puede desempear distintos papeles dependiendo del caso de
uso en que participe.
Un actor representan un conjunto coherente de papeles que los usuarios
de una entidad (sistema, subsistema, clase) pueden desempear al
interaccionar con la misma.

RELACIONES

Las relaciones entre un actor y un caso de uso, se dibujan con una lnea
simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas
"incluir" o "extender." Una relacin "incluir" indica que un caso de uso es

necesitado por otro para poder cumplir una tarea. Una relacin "extender"
indica opciones alternativas para un cierto caso de uso. (Press, 1984)

DIAGRAMAS DE SECUENCIAS
Los diagramas de clases y los de objetos representan informacin esttica. En
un sistema funcional, los objetos interactan entre s, y estas interacciones
suceden con el tiempo. El diagrama de secuencias UML muestra la mecnica
de la interaccin con base en tiempos.
Los diagramas de secuencia es un elemento muy importante para el diagrama
de caso de uso se enfoca a los diferentes estados de un objeto esto es solo
una pequea parte del cuadro, establece el siguiente paso y le muestra la
forma en que los objetos se comunican entre s al transcurrir el tiempo.

ROL DE LA CLASE

El rol de la clase describe la manera en que un objeto se va a comportar en el

contexto. No se listan los atributos del objeto. (Soto, Octubre 2008)

ACTIVACION

Los cuadros de activacin representan el tiempo que un objeto necesita para

completar una tarea. (Soto, Octubre 2008)

MENSAJES
Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto al
de otro. Un objeto puede enviarse un objeto a si mismo es decir de su lnea de
vida as propia lnea de vida.
Un mensaje puede ser simple, sncrono y asncrono

Mensaje simple: es la transferencia del control de un objeto a otro.

Mensaje sncrono: es cuando el objeto espera la respuesta a ese

mensaje antes de continuar con su trabajo.

Mensaje asncrono: es cuando el objeto no espera la respuesta a ese

mensaje antes de continuar.

Los mensajes son flechas que representan comunicaciones entre objetos. Las
medias flechas representan mensajes asincrnicos. Los mensajes asincrnicos
son enviados desde un objeto que no va a esperar una respuesta del receptor
para continuar con sus tareas. (Soto, Octubre 2008)

LINEAS DE VIDA
Las lneas de vida son verticales y en lnea de puntos, ellas indican la
presencia del objeto durante el tiempo.
Una lnea de vida representa un participante individual en un diagrama de
secuencia. Una lnea de vida usualmente tiene un rectngulo que contiene el
nombre del objeto. Si el nombre es self entonces eso indica que la lnea de vida
representa el clasificador que posee el diagrama de secuencia. (Gutierrez, Abril
2011)

DESTRUCCION DE OBJETOS
Los objetos pueden ser eliminados tempranamente usando una flecha
etiquetada "<<destruir>>" que apunta a una X.

LOOPS
Una repeticin o loop en un diagrama de secuencias, es representado como un
rectngulo. La condicin para abandonar el loop se coloca en la parte inferior
entre corchetes. (Pealvo, 1998)

DIAGRAMAS DE CLASE
Los diagramas de clases describen la estructura esttica de un sistema.
Las cosas que existen y que nos rodean se agrupan en categoras. Una clase
es una categora o grupo de cosas que tienen atributos (propiedades) y
acciones similares. Un ejemplo puede ser la clase Aviones que tiene atributos
como el modelo de avin, la cantidad de motores, la velocidad de crucero y
la capacidad de carga til. Entre las acciones de las cosas de esta clase se
encuentran: acelerar, elevarse, girar, descender, desacelerar.
Un rectngulo es el smbolo que representa a la clase, y se divide en tres
reas. Un diagrama de clases est formado por varios rectngulos de este tipo
conectados por lneas que representan las asociaciones o maneras en que las
clases se relacionan entre s. (Pealvo, 1998)

CLASE ABSTRACTA

Las clases se representan con rectngulos divididos en tres reas: la superior

contiene el nombre de la clase, la central contiene los atributos y la inferior las
acciones.

CLASE AVIONES

En el rea superior figura el nombre de la clase que utilizamos como

ejemplo, en la central estn sus atributos y en la inferior las acciones que
ella realiza. Las acciones llevan parntesis al final del nombre porque las
mismas son funciones y por lo tanto devuelven un valor.

ASOCIACIONES

Las asociaciones son las que representan a las relaciones estticas entre las
clases. El nombre de la asociacin va por sobre o por debajo de la lnea que la
representa. Una flecha rellena indica la direccin de la relacin. Los roles se
ubican cerca del final de una asociacin. Los roles representan la manera en
que dos clases se ven entre ellas. No es comn colocar los dos nombres, el de
la asociacin y el de los roles a la vez. Cuando una asociacin es calificada, el
smbolo correspondiente se coloca al final de la asociacin, contra la clase que
hace de calificador. (Longman, 1998 )

MULTIPLICIDAD

Las notaciones utilizadas para sealar la multiplicidad se colocan cerca del final
de una asociacin. Estos smbolos indican el nmero de instancias de una
clase vinculadas a una de las instancias de la otra clase. Por ejemplo, una
empresa puede tener uno o ms empleados, pero cada empleado trabaja para
una sola empresa solamente.

ASOCIACION TRIPARTITA

COMPOSICION Y AGREGACION

Composicin es un tipo especial de agregacin que denota una fuerte posesin

de la Clase Todo, a la Clase Parte. Se grafica con un rombo diamante
relleno contra la clase que representa el todo.
La agregacin es una relacin en la que la Clase Todo juega un rol ms
importante que la Clase "Parte", pero las dos clases no son dependientes una
de otra. Se grafica con un rombo diamante vaco contra la Clase Todo.
GENERALIZACION

Generalizacin es otro nombre para herencia. Se refiere a

una relacin entre dos clases en donde una Clase
Especfica es una versin especializada de la otra, o Clase
General. Por ejemplo, Honda es un tipo de auto, por lo que
la Clase Honda va a tener una relacin de generalizacin
con la Clase Auto.
(BOOCH, 2000)Solucin
DESARROLLO

Pres Servi Game

Nuestra empresa se encarga de la rentar de videojuegos que solo puede ser

usado teniendo internet, se puede usar en cualquier video juego que se pueda
conectar a internet y tambin se necesita de un disco para poder seleccionar
todos los juegos que ofrecemos.
Terminos y condiciones:

Se realiza un contrato de conformidad y acuerdo con el cliente.

El cliente al hacer el contrato con Pres Servi Game se le entrega un
aparato el cual contiene integrados juegos.
Ofrecemos diversos paquetes cada uno de ellos con distintos juegos.
Cada paquete contiene 40 juegos, si se desea otro juego que no se
encuentre en el paquete y quiere adquirirlo tiene que informarlo al
proveedor y por cada juego que se adquiera se debe pagar por
separado.
Los juegos pueden variar dependiendo del paquete que se contrate.
Cada corto tiempo los paquetes pueden actualizarse, esto depende de
los proveedores de los juegos.
La forma de pago depende del tipo de paquete que el cliente desee, esto
puede variar.
El pago es mensualmente, si esto no se hace conforme al contrato el
aparato es recogido al cliente, hasta que la deuda este liquidada el
cliente no podr obtener el servicio de Pres Servi Game.
Los pagos son el primer lunes de cada mes.
El primer mes de contrato es gratis solo se cobrara el trmite del
contrato.
Si se desea cancelar el servicio de Pres Servi Game solo tiene que
acudir a nosotros o llamar a nuestros telfonos y un ingeniero acudir a
su casa a cancelar el contrato y retirar el aparato que Pres Servi Game
le ofrece por nuestros servicios.

Tambien por medio de nuestro receptor que se les da al contratar uno de los
paquetes que ofrecemos, el receptor contiene controles, al igual que tambin
con sistema de prepago donde puedes pagar por adelantado cuando se acabe
tu crdito se saldr de nuestra pagina y podr volver a jugar si paga para otro
cierto tiempo, contamos con los mejores juegos de las marcas de Xbox y
playstation.

SERVI GAME
Nombre comercial: Pres Serv Game
460

Versin:

Especificacin del caso de uso: Centro de venta

Diciembre-2015

Fecha: 25-

Actor principal: Cliente

Producciones: Renta de videojuegos y Venta de codificador
Garantas de xito: Existencia de Videojuegos y codificador

1er DIAGRAMA DE CASO DE USO

VENTA DEL PRODUCTO

1.
2.
3.
4.
5.
6.
7.
8.

El cliente llega con su producto al punto de venta

El cajero inicia una nueva venta
Introducir el nmero y modelo del producto
Muestra la descripcin del producto y el precio
Calcula el monto del producto, importe, IVA, cantidad
Se registrar el monto total de los productos
Indicarle al cliente el monto a pagar
Se cobra la venta

Excepciones:
1. EL SISTEMA FALLA
a. El sistema intenta auto recuperarse
b. Reiniciar el equipo completo
c. Comunicarse con soporte tcnico
d. Esperar a que la falla sea completamente resuelta
2. REGISTRO DEL PRODUCTO
a) Comunicarse con soporte tcnico para poder activar el producto
b) No coincida el clave de producto con la descripcin
c) Comunicarse con soporte tcnico para solicitar otro cdigo con el
mismo precio incluido
d) Se llamara a un gerente en caso de que no se pueda activar el
producto

DIAGRAMA DE SECUENCIA

SERVI GAME
Nombre comercial: Pres Serv Game
460

Versin:

Especificacin del caso de uso: Centro de venta

Diciembre-2015

Fecha: 25-

Actor principal: Cliente

Producciones: Renta de videojuegos y Venta de codificador

Garantas de xito: Existencia de Videojuegos y codificador

2do DIAGRAMA DE CASO DE USO

VENTA DEL PRODUCTO

1.
2.
3.
4.
5.
6.
7.
8.
9.

El cliente ingresa a la pgina web de PressServiGame

El sistema despliega los productos con su precio
El cliente seleccionara su producto
Se agregara la compra al carrito
El sistema mostrar el monto del pedido, importe, IVA, cantidad
Mostrar la descripcin del pedido y precio total
Ya confirmado su pedido seleccionara la forma de pago
El sistema Indicara al cliente el monto total a pagar
El Cliente aceptara los trminos y condiciones para poder realizar
la compra

10. Si el cliente cuenta con tarjeta de crdito se realizara

satisfactoriamente la compra.
11. Se registra la compra

Excepciones:
3. EL SISTEMA FALLA
a.
b.
c.
d.
e.
f.
g.

El sistema intenta auto recuperarse.

Deber esperar el usuario a su total recuperacin.
En caso de seguir con la falla, llamar a soporte tcnico.
Se brindar asesora en caso de que la falla contine.
Se mandara un tcnico a revisar la falla ocasionada
Si la compra falla se revisaran inventarios de compra
Si dentro de la garanta falla el decodificador este ser repuesto o
reparado

4. El producto no tiene precio.

a. Llamar al centro de atencin a clientes para verificar el precio
9. El cliente no acepta las condiciones para poder realizar la compra
a) El cliente podr cancelar su producto o no lo registra
REGISTRO DEL PRODUCTO
e) Comunicarse con soporte tcnico para poder activar el producto
f) No coincida el clave de producto con la descripcin
g) Comunicarse con soporte tcnico para solicitar otro cdigo con el
mismo precio incluido
h) Se llamara a un gerente en caso de que no se pueda activar el
producto

10. El sistema no acepta la tarjeta para la compra.

a)
b)
c)
d)
e)

El nmero de cuenta no coincide con el nombre del titular

La tarjeta ha vencido
No cuenta con dinero disponible para la compra
Los datos de la tarjeta no son los correctos
El banco o la entidad emisora de la tarjeta ha rechazado el uso de
la misma
f) El pago ha sido denegado por el sistema de seguridad interno
g) Cada del sistema de la pgina web

DIAGRAMA DE SECUENCIA

SERVI GAME
Nombre comercial: Pres Serv Game

Versin: 460

Especificacin del caso de uso: Centro de venta

Diciembre-2015
Caso de uso: Paquetes

Fecha: 25Tcnico: Burgos

Actor principal: Cliente

Producciones: Renta de videojuegos y Venta de codificador
Garantas de xito: Existencia de Videojuegos y codificador

3er DIAGRAMA DE CASO DE USO

12345678-

El cliente llama al gerente para escoger su paquete.

El gerente describe cada paquete.
El cliente selecciona el paquete que desea adquirir.
El gerente confirma la seleccin del paquete obtenido por
el cliente.
El gerente le da el nip para ingresar en el codificador.
El cliente ingresa el nip en el codificador para
complementar el uso del paquete.
El cliente indica al gerente( el codificador acepto el nip)
Se termina la configuracin del paquete.

4.- El sistema se cae.

a) Cambios repentinos en el paquete seleccionado.
6.- El codificador no acepta el nip.
a) Reiniciar el equipo.
b) Comunicarle al gerente para proporcionar nuevo nip.

DIAGRAMA DE SECUENCIA

Punto de venta

Diagrama de

estado

Inicia

Analizand
Procesan

Procesan

Realizando

Introduccin

Procesan

Autorizan

Diagrama de paquetes

Servigame

html

php
Ventas

css

Punto de venta

Metodologas clsicas, cascadas, incrementales, evolutivas y

espirales

Una metodologa es un conjunto integrado de tcnicas y mtodos que

permite abordar de forma homognea y abierta cada una de las
actividades del ciclo de vida de un proyecto de desarrollo. Es un
proceso de software detallado y completo.
Las metodologas se basan en una combinacin de los modelos de
proceso genricos (cascada, incremental). Definen artefactos, roles
y actividades, junto con prcticas y tcnicas recomendadas.

Cascada

Modelo en cascada es el enfoque metodolgico que ordena

rigurosamente las etapas del proceso para el desarrollo de software,
de tal forma que el inicio de cada etapa debe esperar a la finalizacin
de la etapa anterior.
Las fases son:

Incremental

El modelo incremental combina elementos del modelo en cascada con la

filosofia interactiva de construccion de prototipos. Se basa en la filosofia de
construir incrementando las funcionalidades del programa. Este modelo
aplica secuencias lineales de forma escalonada mientras progresa el tiempo
en el calendario. Cada secuencia lineal produce un incremento del softwar.

Evolutivo
Este enfoque entrelaza las actividades de especificacin, desarrollo y
validacin.
Un sistema inicial se desarrolla rpidamente a partir de especificaciones
abstractas.
Este se refiere basndose en las peticiones del cliente para producir un
sistema que satisfaga sus necesidades.
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con
el cliente para explotar sus requerimientos y entregar un sistema
final. El desarrollo empieza con las partes del sistema que se
comprenden mejor. El sistema evoluciona agregando nuevos atributos
propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo
evolutivo es comprender los requerimientos del cliente y entonces
desarrollar una definicin mejorada de los requerimientos para el
sistema. El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprende del todo.

Espiral
Es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985,
utilizado de forma generalizada en la ingeniera del software.
Las actividades de este modelo se conforman en una espiral, cada bucle
representa un conjunto de actividades.
Las actividades no estn fijadas a priori, sino que las siguientes se eligen en
funcin del anlisis de riesgos, comenzando por el bucle anterior.
Este modelo de desarrollo combina las caractersticas del modelo de
prototipos y el modelo en cascada. El modelo en espiral est pensado para
proyectos largos, caros y complicados.
Este modelo no fue el primero en tratar el desarrollo iterativo, pero fue el
primer modelo en explicar las iteraciones.

Bibliografa
Beluche, O. (2003). UML y patrones. Prentice Hall.
Bondaruk, C. (1996). Modelado y diseo orientado a objetos con aplicacion.
adison wesle.
BOOCH, G. (2000). MANUAL DE UML. Mexico: Rama.
Fonticelli, A. (1993). Ingenieria del sofware un enfoque practico. Pressman:
Manantial.
Gutierrez, D. (Abril 2011). Conocimientos de ingenieria de sofware. Brasil:
Hausse.

Longman, A. W. (1998 ).
Pealvo, G. (1998). Abya yala.
Press, Y. (1984). Importancia de la ingenieria. washinton: edebe.
Sipino, S. B. (2002). ingenieria de sofware, teoria y practica. Prentice Hall.
Soto, A. M. (Octubre 2008).