PROFESOR:Tacubeo

EQUIPO:Hernndez Amaro Jos AdalbertoRamrez Tllez GerardoMuoz Eduardo

MATERIA:Ingeniera de Software

GRUPO:4601

CARRERA:Ing. En Sistemas Computacionales

SEMESTRE:6

Tabla de contenidoObjetivos3Marco terico4UML4RESUMEN5UML6DIAGRAMA DE CASOS DE USO6SISTEMA7Casos de uso7ACTORES8RELACIONES8DIAGRAMAS DE SECUENCIAS9ROL DE LA CLASE9ACTIVACION9MENSAJES10LINEAS DE VIDA11DESTRUCCION DE OBJETOS11LOOPS12DIAGRAMAS DE CLASE12CLASE ABSTRACTA13CLASE AVIONES13ASOCIACIONES14MULTIPLICIDAD14ASOCIACION TRIPARTITA15COMPOSICION Y AGREGACION15Pres Servi Game161er DIAGRAMA DE CASO DE USO18DIAGRAMA DE SECUENCIA202do DIAGRAMA DE CASO DE USO21DIAGRAMA DE SECUENCIA233er DIAGRAMA DE CASO DE USO24DIAGRAMA DE SECUENCIA25Diagrama de estado26Diagrama de paquetes26Punto de venta27Bibliografa28

ObjetivosObjetivo 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 tericoUMLLa 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 en el valo indica la funcin del sistema.

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 "" 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)SolucinDESARROLLO

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 GAMENombre comercial: Pres Serv GameVersin: 460Especificacin del caso de uso: Centro de ventaFecha: 25-Diciembre-2015Caso de uso: Punto de ventaTcnico: Burgos

Actor principal: Cliente Producciones: Renta de videojuegos y Venta de codificadorGarantas de xito: Existencia de Videojuegos y codificador

1er DIAGRAMA DE CASO DE USO

VENTA DEL PRODUCTO1. El cliente llega con su producto al punto de venta2. El cajero inicia una nueva venta3. Introducir el nmero y modelo del producto4. Muestra la descripcin del producto y el precio5. Calcula el monto del producto, importe, IVA, cantidad6. Se registrar el monto total de los productos7. Indicarle al cliente el monto a pagar8. Se cobra la ventaExcepciones:1. EL SISTEMA FALLAa. El sistema intenta auto recuperarseb. Reiniciar el equipo completo c. Comunicarse con soporte tcnicod. Esperar a que la falla sea completamente resuelta

2. REGISTRO DEL PRODUCTOa) Comunicarse con soporte tcnico para poder activar el productob) No coincida el clave de producto con la descripcinc) Comunicarse con soporte tcnico para solicitar otro cdigo con el mismo precio incluidod) Se llamara a un gerente en caso de que no se pueda activar el producto

DIAGRAMA DE SECUENCIA

SERVI GAMENombre comercial: Pres Serv GameVersin: 460Especificacin del caso de uso: Centro de ventaFecha: 25-Diciembre-2015Caso de uso: Venta internetTcnico: Burgos

Actor principal: Cliente Producciones: Renta de videojuegos y Venta de codificadorGarantas de xito: Existencia de Videojuegos y codificador

2do DIAGRAMA DE CASO DE USO

VENTA DEL PRODUCTO1. El cliente ingresa a la pgina web de PressServiGame2. El sistema despliega los productos con su precio3. El cliente seleccionara su producto4. Se agregara la compra al carrito 5. El sistema mostrar el monto del pedido, importe, IVA, cantidad6. Mostrar la descripcin del pedido y precio total7. Ya confirmado su pedido seleccionara la forma de pago8. El sistema Indicara al cliente el monto total a pagar9. El Cliente aceptara los trminos y condiciones para poder realizar la compra10. Si el cliente cuenta con tarjeta de crdito se realizara satisfactoriamente la compra.11. Se registra la compra

Excepciones:3. EL SISTEMA FALLA

a. El sistema intenta auto recuperarse.b. Deber esperar el usuario a su total recuperacin.c. En caso de seguir con la falla, llamar a soporte tcnico.d. Se brindar asesora en caso de que la falla contine.e. Se mandara un tcnico a revisar la falla ocasionadaf. Si la compra falla se revisaran inventarios de comprag. 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 compraa) El cliente podr cancelar su producto o no lo registra

REGISTRO DEL PRODUCTOe) Comunicarse con soporte tcnico para poder activar el productof) No coincida el clave de producto con la descripcing) Comunicarse con soporte tcnico para solicitar otro cdigo con el mismo precio incluidoh) 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) El nmero de cuenta no coincide con el nombre del titularb) La tarjeta ha vencido c) No cuenta con dinero disponible para la comprad) Los datos de la tarjeta no son los correctose) El banco o la entidad emisora de la tarjeta ha rechazado el uso de la mismaf) El pago ha sido denegado por el sistema de seguridad internog) Cada del sistema de la pgina web

DIAGRAMA DE SECUENCIA

SERVI GAMENombre comercial: Pres Serv GameVersin: 460Especificacin del caso de uso: Centro de ventaFecha: 25-Diciembre-2015Caso de uso: PaquetesTcnico: Burgos

Actor principal: Cliente Producciones: Renta de videojuegos y Venta de codificadorGarantas de xito: Existencia de Videojuegos y codificador

3er DIAGRAMA DE CASO DE USO

1- El cliente llama al gerente para escoger su paquete.2- El gerente describe cada paquete.3- El cliente selecciona el paquete que desea adquirir.4- El gerente confirma la seleccin del paquete obtenido por el cliente.5- El gerente le da el nip para ingresar en el codificador.6- El cliente ingresa el nip en el codificador para complementar el uso del paquete.7- El cliente indica al gerente( el codificador acepto el nip)8- 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 estadoProcesandoProcesandoAutorizandoIntroduccin datosRealizando procesoProcesandoAnalizandoInicia venta

Diagrama de paquetes

Servigame

csshtmlphpVentas

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.

CascadaModelo 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.

EvolutivoEste 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.

EspiralEs 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.

BibliografaBeluche, 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).