UEA:

Anlisis y Diseo de Sistemas de Informacin

Profesora:
Irma Fernanda Ardn Pulido

TRABAJO FINAL
Equipo:
Editorial
Integrantes:
Montiel Saavedra Alejandra
Osornio Garca Paola Jazmn
Pichardo Cedillo Javier
Ramrez Robles Josu

TRIMESTRE:14-O

Fecha de Entrega: 20 de noviembre del 2014

Problema propuesto: Editorial

La empresa, elabora y distribuye tres tipos de publicaciones: revistas, gacetas y libros.
La elaboracin de cualquier tipo de publicacin incluye las siguientes
rdenes:
De produccin, con fecha de termino, descripcin y cantidad de
producto.
Al almacn para que abastezca los materiales requeridos.
De entrega con los datos de la bodega donde se deber
entregar el producto terminado.
rdenes que son emitidas por los departamentos de: logstica y de
planeacin y control de la produccin.
Un lder de proyecto se encarga de dar seguimiento a todo el proceso, desde la elaboracin hasta
la distribucin de un producto.
El proceso de distribucin consiste en:
-

Enviar a diferentes tiendas o puestos de peridicos las publicaciones en base a la

informacin arrojada por un estudio de mercado previo.
Organizar a los empleados del departamento de produccin y ventas para que den a
conocer el producto elaborado en diferentes zonas de la ciudad.

Buscando su permanencia en el mercado, dicha empresa editorial, desea analizar por separado
a sus diferentes clientes: libreras educativas, gobierno y puestos de peridico.

1. Anlisis de Requerimientos
1.1.

Dos requerimientos modelados.

a) Altas, bajas, consultas y cambios en el proceso de produccin considerando las

peticiones del cliente.
(Requerimiento modelado)
Entidades:
* Base de datos * Altas * Bajas * Consultas
* Cambios
Control de la Produccin
Parmetros:
* Nombre * Altas * Bajas * Cambios * Consultas * ID_Cliente
Validaciones:
* Registrado
Accin a tomar.
Alta en el sistema (Base de Datos)
Camino alterno.
Notificar problema

* Gerente de Produccin *

b) Actualizar datos de la bodega.

(Requerimiento modelado)
Entidades:
* El administrador * Gestor de Base de Datos * Recepcionista
Parmetros.
Descripcin del producto
* Nmero de Bodega * Producto * Cantidad * Nmero de Estante * Nmero de Pasillo
* Fecha de entrada * Fecha de salida Fecha de actualizacin * Da-Mes-Ao Hora
* Pm- Am
Validaciones
* Recibir reporte de estado del producto.
Accin a tomar.
* El gestor de base de datos realizar los cambios.
Camino alterno.
* Reportar la verificacin del producto
c) Contrato de distribucin de las tres publicaciones.
(Requerimiento modelado)
Entidades:
* El administrador * Gestor de Base de Datos * Recepcionista
Parmetros.
* Bodega
Fecha de actualizacin * Da-Mes-Ao
Hora
* Pm- Am
Validaciones
*
Accin a tomar.

* Generar contrato
Camino alterno.
* Ninguno
d)

Gestionar la elaboracin y distribucin de los tres tipos de publicaciones.

(Requerimiento modelado)
Entidades:
* Base de datos.
* Lder del Proyecto.
* Usuarios.
* Modificaciones.
* Gerente de Produccin.
* Gerente de Logstica y Planeacin.
Parmetros
* # de publicaciones del tipo (revistas, gacetas, libros) elaboradas, # de publicaciones del tipo i
entregadas en la bodega j.
* Fecha de trmino de elaboracin.
* Descripcin del producto.
* Materiales para solicitar al almacn.
* Datos de la bodega donde se entregaran.
Validaciones.
* Tipo de publicacin
* Stock solicitado completo
Accin a tomar.
Camino alterno.
Si no est completo el stock solicitado, validar porque, y solicitar los faltantes.
e) Agregar o crear peticin de pedido
(Requerimiento modelado)
Entidades:
* Gerente de mercadotecnia * Base de Datos * Oficina de Cobranza * Clientes
Parmetros
* Lugar y Fecha de creacin * Producto * Cantidad * Cliente (a quin se le va a surtir)
Fecha de entrega * Precio * Forma de pago
Validaciones.
* Solicitado completo
Accin a tomar.
* Alta en el sistema(BD)
Camino alterno. Notificar problema
1.2.

Dos requerimientos trazados.

a) Altas, bajas, consultas y cambios en el proceso de produccin considerando las

peticiones del cliente.
(Requerimiento trazado)
Quien:
* Es el responsable: Gestor de la Base de Datos, Administrador

* Lo define: La empresa.
* Lo verifica: Gerente de Produccin
* Lo valida: La empresa
* Lo modifica: Gerente de Produccin, Gestor de Base de Datos
De que es parte: Control de la Produccin
En que se divide: Altas, Bajas, Consultas y Cambios
b) Actualizar datos de la bodega.
(Requerimiento trazado)
Quien:
* Es el responsable: Recepcionista, Administrador, Gestor de Base de datos
* Lo define: El administrador
* Lo verifica: El administrador, Base de datos
* Lo valida: Departamento de Base de datos
Lo modifica: Gestor de base de datos, Recepcionista, Administrador
De qu es parte: venta y distribucin de producto
En que se divide: En nada.
c) Contrato de distribucin de las tres publicaciones.
(Requerimiento trazado)
Quien:
* Es el responsable: Administrador, Gestor de Base de datos, Ejecutivos de distribucin
* Lo define: La empresa.
* Lo verifica: El administrador
* Lo valida: La empresa
Lo modifica: Gestor de base de datos.
De que es parte: Logstica
En que se divide: En nada.
d) Gestionar la elaboracin y distribucin de los tres tipos de publicaciones.
(Requerimiento trazado)
Quien:
* Es el responsable: El analista o gestor de Base de Datos.
* Lo define: La empresa.
* Lo verifica: Gerente de produccin.
* Lo valida: Lder del Proyecto, usuarios.
* Lo modifica: Gerente de Produccin, Logstica y Planeacin.
De que es parte: Del rea de Produccin y Logstica y Planeacin.
En que se divide: En tipo de publicacin.
e) Agregar o crear peticin de pedido
(Requerimiento trazado)
Quin:
* Es el responsable: Gerente de mercadotecnia, Oficina de Cobranza.
* Lo define: Departamento de Base de Datos
* Lo verifica: Oficina de Cobranza

* Lo valida: La empresa.
* Lo modifica: Gestor de base de datos
De qu es parte: Del Gerente de Mercadotecnia
En qu se divide: en nada
Los requerimientos trazados y modelados en fueron de lo ms sencillos, ya que
bsicamente es satisfacer las necesidades del cliente, en este caso La Editorial, nos
atreveramos a decir que todo el anlisis se deriva de estos requerimientos iniciales.

2 . Modelo de Interfaz
2.1 Una interfaz con firmas de operacin
INTERFAZ 1:

FIRMAS DE OPERACIN:
o
o
o
o
o

Validacin de entrada al sistema de Editorial.

Captura de usuario permitido.
Captura de contrasea de usuario.
Botn de ingresar que valida o niega acceso al sistema.
Botn de ayuda, que muestra informacin sobre funcionalidad de la interfaz.

INTERFAZ 2:

FIRMAS DE OPERACIN
o Botn de Contrataciones, inicia el procedimiento para una nueva pliza.
o Botn de Consultas, abre el proceso para revisar el estado de alguna pliza.
o Botn de Peticiones, que informa sobre la funcionalidad de tres opciones (pedido,
producto y venta).
o Botn de Acerca de, que informa sobre detalles de la empresa Editorial.
o Botn de Salir, finaliza.
Las firmas de operacin no causaron conflicto ya que en el solo se trata de la descripcin
de la interfaz, estas se ocupan bsicamente para la capacitacin del personal que utilizara
el sistema.

2.2 Mapa de navegacin entre interfaces

El mapa de Navegacin lleva a cabo la navegabilidad existente entre las interfaces del
sistema, en este se debe de tener bien en claro hacia donde nos va a llevar cada interfaz.

3 . Modelo de Casos de uso

3.1 Dos diagramas de casos de uso con: relaciones uses y

extended

1)
Confirmacin de
cancelacin

Cancelar
pedido

Agente
de
ventas

de

Cliente

lu
Inc

Consulta
estado de
pedido

Solicita
Validacin
Base de
datos

Pre-registro de
cancelacin

Dpto. De
Validacin

------------------------------------------------------

2)

3.2 Descripciones de todos los CU de uno solo de los diagramas del punto 3.1 en
trminos de Actores, pre y pos condiciones, flujo de eventos y caminos alternativos.

Regla del negocio:

Consultas
CU1: Altas, bajas y cambios en el proceso de produccin considerando las peticiones del cliente.
Actores: Administrador, Departamento de base de datos
Precondiciones: Solicitado completo
Flujo de eventos:
- Base de datos da de alta al pedido o su producto.
- Genera cdigos de identificacin
- Base de datos modifica la fecha de entrega
Post-condiciones: El administrador listo para actualizar datos de la bodega.
Caminos alternos: Ninguno.
CU2: Actualizar datos de la bodega
Actores: Administrador, Distribuidor
Precondiciones: Contrato generado y dar de alta
Flujo de eventos:
- Base de datos verifica la fecha de actualizacin.
- El administrador actualiza datos de la bodega.
Post-condiciones: Gestionar la elaboracin y distribucin
Caminos alternos: Ninguno

CU3: Gestionar la elaboracin y distribucin de publicaciones

Actores: El analista, Almacn
Precondiciones: Actualizado completo
Flujo de eventos:
- El contador verifica el nmero de publicaciones elaboradas.
- El contador modifica el nmero de publicaciones entregadas en la bodega.
- El analista modifica la descripcin del producto.
Post-condiciones: Agregar o crear peticin de pedido
Caminos alternos: Ninguno
CU4: Agregar o crear peticin de pedido

Actores: Gerente de Mercadotecnia, Ventas o pedidos

Precondiciones: El encargado supervisa el nmero de publicaciones elaboradas
Flujo de eventos:
- Base de datos da de alta en el sistema
- Oficina de cobranza entrega comprobante
- Cliente cubre monto en la oficina de cobranza.
- El gerente analiza los pedidos creados y envan al administrador para que actualice los
datos.
Post-condiciones: Fin del caso de uso
Caminos alternos: Ninguno.

Los Modelos de Caso de Uso forman parte importante del Anlisis y Diseo de Sistemas
de Informacin, ya que es la llave a crear dems anlisis, en este se tuvieron conflictos ya
que haba casos de uso considerados que no tenan mucha participacin por lo que se
tuvieron que descartar algunos que se haban considerado.

4. Dominio del Problema

4.1

Identificacin de clases candidatas y depuracin

El sistema deber permitir el ingreso de datos de: altas, bajas, consultas, cambios (en el
proceso de produccin considerando las peticiones del cliente), nmero de bodega, producto,
cantidad, nmero de estante, nmero de pasillo, fecha de actualizacin, de entrada y de salida,
descripcin del producto, precio, forma de pago, lugar y fecha de creacin.
Verificar que el cliente est registrado en la base de datos, al igual que la distribucin de las tres
publicaciones (gacetas, libros, revistas); validar el status disponible de dicha bodega (o
distribucin).
Ingresar el pago correspondiente, el lugar y fecha de creacin.
Sin embargo, la interfaz ser comprensible, fcil de accionar, intuitiva y segura. Contar con un
nivel alto de seguridad sobre la informacin de las tres publicaciones y la forma de pagos, el
acceso al sistema ser controlado y realizar un historial con todas las transacciones realizadas.

Lista de las clases candidatas:

- sistema

- cliente

- seguridad

- Ingreso de datos

- status

- publicaciones

- altas

- interfaz

- historial

- bajas

- producto

- transaccin

- consultas

- descripcin del producto

- informacin

- cambios

- forma de pago

- bodega

Depurar clases, aadiendo de ser posible, otras clases, eliminando redundancias y clases
irrelevantes, difusas o de implementacin.
-

Aadir clases por nuestro conocimiento: Empleado

Eliminar:
-

CLASES REDUNDANTES, IRRELEVANTES O DIFUSAS:

Informacin, descripcin del producto, historial, transaccin, ingreso de datos, status,
producto, sistema y seguridad.

ATRIBUTOS Y MTODOS: Altas, bajas, consultas, cambios, producto, descripcin del

producto, publicaciones, status, ingreso de datos, forma de pago e historial.

OBJETOS DE DISEO: Interfaz

PERMANECEN EN EL MODELO:
Empleado
Cliente
Publicaciones
Bodega
Transaccin

4.2
Diagrama General de Clases con herencia, agregacin y composicin,
multiplicidad y navegabilidad

5. Anlisis de Robustez
5.1 Narracin MVC De todos los CU del Diagrama no descrito en el punto 3.1
Narracin MVC de DCU referente a la cancelacin de pedido
Nota: hay dos Usuarios.

Usuario (1): Agente de ventas

Usuario (2): Departamento de validacin.
Una vez solicitada la cancelacin por el cliente:
Usuario(1) ingresa a Consulta de estado de pedido

1. Controlador consulta de estado

Solicita a Modelo arreglo del estado de contrato deseado en Base de Datos.
Indica a Vista el estado solicitado.
2. Vista toma el arreglo y lo muestra en pantalla.
3. Usuario va a Validaciones.
Usuario (1) verifica estado e ingresa a Validaciones

1. Controlador Validaciones portal de agentes.

Enva pedido con instruccin de cancelacin.
Recibe respuesta de cancelacin de pedido.
Indica a Vista mostrar la respuesta.
2. Vista toma respuesta y la muestra en pantalla.
Usuario (2) entra a Validaciones

1. Controlador Validaciones portal de oficina.

Recibe peticin de cancelacin.
Genera pre-registro de la validacin.
Enva respuesta de peticin de validacin.
3. Vista muestra respuesta y envi de ella.
Usuario (2) antes de mandar respuesta entra a Registros

1. Controlador Registros pre-registros.

Enva pre-registro de cancelacin a la Base de Datos (registros).
Indica a vista la localizacin de pre-registro de Base de Datos(registros).
2. Vista toma pre-registro y la muestra en pantalla.
Usuario (1) entra a Registros

1. Controlador Registros_confirmacin.
Recibe registro de Cancelacin de pedido.
Busca pre-registro de cancelacin.
Coteja ambos registros.
Acepta cancelacin de pedido.
Indica a vista que muestre la cancelacin.
2. Vista toma la informacin de la cancelacin y la muestra en pantalla.

5.2 Diagrama de Robustez: de todo el SI

6.

Modelo de Esttico
6.1

Un diagrama de Secuencia

6.2

Un diagrama de Colaboracin

Validacion cliente()
APLICACION
(formulario de registros)

Crear Historial()

1.2
SISTEMA

2.2

Ingresa pago()

si(Datos poliza correcto)() 2.5

1.4

HISTORIAL PAGOS

Otorgar num
2.7
poliza ()

si(Imprimir
Poliza)
3.5

Ingresa pago 3.2c

Ingresa datos
poliza () 2.1

Ingresa
Validacion
1.1
Cliente
Validacion
correcto ()

3.3

Ingrasa pago correcto()

3.4

AGENTE DE VENTAS

Solicitar
proteccion 1

HISTORIAL

si(Crear Historial)
Correcto() 2.4

Validacion cliente correcta() 1.3

Datos poliza ()

2.3

CLIENTE

CAJERA
Otorgar ticket() 3.6

Tabla de Estados
Cliente
Cliente
Empleado
TipoDePublicacion
Bodega
Transaccin

Empleado

TipoDePublicacion

Bodega

Solicita
pedido
Levanta
pedido
Guarda
seleccin
Entrega
pedido
Recibe
pago

Transaccin
Paga pedido

Selecciona tipo

Confirma
existencias
Guarda
movimientos

Enva
solicitud

Realiza cobro

Actualiza
existencias

El diagrama de Secuencia en lo particular nos pareci ms sencillo que el de colaboracin,

aparentemente son muy similares pero es muchsimo ms laborioso el de colaboracin ya
que se tiene que crear una tabla de estados.

7.

Modelo Dinmico
7.1 Un diagrama, ya sea de Estado o de Actividad

8.

Arquitectura
8.1
Justificacin y diagrama de la arquitectura organizacional y de control
elegidas
La arquitectura organizacional elegida fue la de sistemas distribuidos, ya que es fcil de
escalar, es concurrente, lo que evita perdidas de datos, los proveedores de servicios se
pueden ejecutar en cualquier nodo.

8.2

Subsistemas

Caso: Editorial

Subsistemas propuestos
Elaboracin
Distribucin
Produccin
Entrega
Seguimiento

8.3

Identificar Concurrencia

Eventos simultneos sin interaccin.

a) Alta de pedido y contrato.

b) Agregar o crear peticin de pedido.

c) Actualizar datos de la bodega.

d) Gestionar la elaboracin y distribucin.

Concurrencia: La pantalla principal da acceso por eventos a cada uno de los nodos del
sistema. La ejecucin
del sistema se realiza mediante hilos para permitir un ptimo
rendimiento del sistema en todos los nodos.

8.4

Almacenamiento de Datos

Persistencia, almacenamiento y acceso.

Archivo

Periodicidad

Medio

Modo de acceso. Desde

cualquier nodo que este
conectado a la red.

LevantarPedido

Diario

Disco duro del servidor Id Bd

RecibirPago

Diario

Disco duro del servidor Id BD

ActualizarExistencia

Diario

Disco duro del servidor Id BD

EntregarPedido

Diario

Disco duro del servidor Id BD

8.5

Acceso a recursos globales (si los hay)

No se est manejando acceso a recursos globales, los archivos y/o directorios se

manejan de forma local esto con la finalidad de asegurar la integridad de la informacin.
Para esto se pretende dar nicamente permisos de lectura a los nodos conectados a la
red y que puedan visualizar dichos archivos.
LevantarPedido tiene permisos de lectura/escritura para los vendedores.

8.6

Implementacin de Controles internos y externos

Objeto (Externo)/Mtodo (Interno)

Forma de control

Vendedor

Cada vendedor cuenta con un password

para dar de alta nuevas ventas, ninguna
puede levantar pedidos con otro usuario.

Lder de proyecto/Gerente

El lder de proyecto/gerente tiene su nombre

de usuario y contrasea con todos los
permisos de usuario.

Cajero

Cada cajero cuenta con un password para

recibir Pagos estipulado por el vendedor.

En un proceso, La orden de pago requiere validacin de la orden de compra por parte del
cajero.
8.7

Manejo de condiciones de frontera. Inicio, trmino y falla

a) Inicio

El en sistema Editorial: Acceder a la ventana principal y autenticarse con su nombre de

usuario y contrasea.

b) Trmino

El proceso de venta finaliza cuando el cliente hace su pago y recibe su producto.

c) Cada nodo cuenta con un no-break que permita el respaldo de los pedidos o cobros en
proceso.

8.8
Arquitectura. Transformacin batch y continua, interfaz interactiva, simulacin
dinmica y manejo en tiempo real

CONCLUSIONES INDIVIDUALES
Montiel Saavedra Alejandra
a. Cul informacin inicial sobre el caso propuesto fue desechada por carecer de
relevancia?
Se desech informacin que el sistema se ampliar ms, porque el proyecto era demasiado
robusto para cubrirlo en su totalidad, e incluso tuvimos que concentrarnos solo en una parte
del sistema para crear un sistema ms coherente y entendible, as logramos concentrarnos
en hacer ms cuidadosamente cada paso del trabajo y que el exceso de informacin no nos
causara ms confusin.
b. El sistema propuesto result ser ms complicado de lo que se esperaba inicialmente?
Justificar su respuesta
Como lo menciono anteriormente mientras avanzbamos en el proyecto encontrbamos
nuevas ramas en donde se expanda el sistema y aun as tuvimos que concentrarnos en una
parte del nuevo sistema.
c. Qu problemas se tuvieron al trabajar en equipo?
-

Problemas para coincidir tiempos de trabajo.

Apreciaciones diferentes para algunos puntos y conceptos.

d. Cmo se solucionaron dichos problemas?

-

Buscamos nuevas formas de trabajar en especial a distancia.

Tratamos de hacer lo que mejor entendamos cada uno y tratbamos de dar argumentos
al resto.

e. Qu informacin proporciona cada uno de los siguientes diagramas UML: Clases,

Casos de Uso, Robustez, Secuencia, Colaboracin, Estado y Actividad? (Si copian y
pegan se anula)
Clases: Nos proporciona la relacin, actividades de elementos en el sistema, descripcin de un
conjunto de objetos que comparten una estructura, un comportamiento y semntica comunes.
Casos de uso: Nos muestra la relacin entre los actores y los casos de uso en un sistema y se
utilizan para formar los requerimientos del sistema al presentar cmo reacciona a eventos que se
producen en su mbito.
Robustez: Nos muestra diferencias entre tipos de elementos que constituirn el sistema y eso
ayuda a identificar principales bloques de la estructura.

Secuencia: Nos proporciona la interaccin entre objetos (por medio de mensajes), ubicar los
mtodos correspondientes a cada clase (responsabilidades).
Colaboracin: Similar al diagrama de secuencia: mostrar interaccin entre objetos; resalta la
organizacin estructural de los objetos que interactan, muestra objetos, enlaces y mensajes.
Estado: Nos proporciona la descripcin del ciclo de vida de un sistema o un objeto del sistema,
identifica estados posibles y qu causas provocan los cambios de un estado a otro.
Actividad: Nos proporciona el flujo de actividades de un sistema, parecido a diagramas de flujo,
admite semntica de concurrencia y sincronizacin, permite modelar decisiones y tambin se
puede utilizar para modelar negocios.

-------------------------------------------------------------------------------Osornio Garca Paola Jazmn

a. Cul informacin inicial sobre el caso propuesto fue desechada por carecer de
relevancia?
Se desech informacin que a simple vista hiciera que el sistema se ampliara ms, ya
que al agregar ms objetos al proyecto iba a hacer que el mismo fuera imposible de
terminarlo, uno de ellos fue el rea de logstica.
b. El sistema propuesto result ser ms complicado de lo que se esperaba inicialmente?
Justificar su respuesta
Claro, en lo personal me di cuenta que cada vez que avanzbamos con respecto al
temario en la clases y en base a esto realizbamos las tareas, salan nuevas cosas ,
por lo que tambin se tena que poner atencin a lo que realmente debamos
enfocarnos.
c. Qu problemas se tuvieron al trabajar en equipo?
El principal fue coincidir en tiempos, la verdad fueron contadas las veces que nos
veamos, tambin armbamos un tipo de debate para decidir que estaba bien y que no,
al final preferamos preguntarle a la profesora.
d. Cmo se solucionaron dichos problemas?
Pues se encontraron nuevas formas para trabajar, el principal y que nos ayudo
bastante fue WhatsApp, el otro fue el correo electrnico, este ltimo lo ocupbamos
esencialmente para enviar los documentos. Cada quien argumentaba porque estaba
bien o por qu no, pero al final decidamos que la profesora tena la ltima palabra.
e. Qu informacin proporciona cada uno de los siguientes diagramas UML: Clases,
Casos de Uso, Robustez, Secuencia, Colaboracin, Estado y Actividad? (Si copian y
pegan se anula)

 Clases: Estas nos proporcionan caractersticas de las actividades de los

elementos existentes en el sistema.
Casos de uso: Nos muestran el camino que tiene el usuario con el Sistema, es
decir, quien intervienen en el proceso, de tal manera que satisfaga los
requerimientos del cliente.
Robustez: Nos muestra mediante un diagrama el camino que hay en el flujo de
eventos de los CU y el modelo MVC, en el se observan las interfaces y el
seguimiento del cada proceso.
Secuencia: Nos muestra la existencia de los objetos mediante el envo de
mensajes en determinado tiempo.
Colaboracin: Nos muestra mediante grafos, enlaces y mensajes, el tipo de
comunicacin que se intercambia con los elementos existentes en el sistema.
Estado: Nos muestra los diferentes estados por los que pasan los objetos de
una clase (sus verbos para describirlo es el gerundio),desde su estado inicial
hasta el final.
Actividad: Nos muestran el flujo de trabajo, hilos y procesamiento paralelo de
los objetos, este es muy parecido al diagrama de estado(sus verbo tienen que
ser infinitivos), desde su estado inicial hasta el final.

-------------------------------------------------------------------------------Pichardo Cedillo Javier

a. Cul informacin inicial sobre el caso propuesto fue desechada por carecer de relevancia?

Cuando empezamos con el desarrollo del proyecto, pareca que todo estaba bien sin embargo, conforme
fuimos avanzando en el trabajo empezamos a desechar informacin ambigua y partes del trabajo que estaban de
ms. En la parte en donde quitamos mas cosas creo que fue cuando definimos el nombre de nuestras clases.

b. El sistema propuesto result ser ms complicado de lo que se esperaba inicialmente? Justificar su

respuesta
Si, al inicio pareca una propuesta fcil pero cuando empezamos a documentar el desarrollo del sistema nos dimos
cuenta que hay que tener mucho cuidado con los detalles.
Porque omitir algn punto por insignificante que parezca puede hacer de nuestro sistema inutilizable.

c. Qu problemas se tuvieron al trabajar en equipo?

En mi punto de vista, creo que fue la comunicacin porque los nicos das que nos podamos ver eran los
das de clase y ese era el nico momento que tenamos para platicar acerca de avance del proyecto.

d. Cmo se solucionaron dichos problemas?

Usamos correo electrnico, mvil, whatssapp y los das de clase para comunicarnos.

e. Qu informacin proporciona cada uno de los siguientes diagramas UML: Clases, Casos de Uso, Robustez,
Secuencia, Colaboracin, Estado y Actividad? (Si copian y pegan se anula)

Clases. 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: NombreClase, Atributos,
Operaciones o mtodos.

Casos de uso. Es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo algn
proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores

Robustez. Un diagrama de robustez es un hbrido entre un DIAGRAMA DE CLASES y un DIAGRAMA DE ACTIVIDADES

Secuencia. Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para
cada caso de uso

Colaboracin. Es una forma de representar interacciones entre objetos.

Actividad. Muestra un proceso de negocio o un proceso de software como un flujo de trabajo a ---

----------------------------------------------------------------------------Ramrez Robles Josu

a. Cul informacin inicial sobre el caso propuesto fue desechada por carecer de
relevancia?
En inicio no fue desechada ninguna informacin, ya que todo lo que nos plateaba el
problema nos pareci til, fue mas adelante cuando pudimos empezar a realizar la
depuracin de la informacin.
b. El sistema propuesto result ser ms complicado de lo que se esperaba inicialmente?
Justificar su respuesta
Pareciera que si pero fue porque no conocamos los mtodos, y fue lo que hizo verlo
de manera complicada pero finalmente, una vez que ya practicamos los mtodos
vemos que si es muy laborioso pero los mtodos aprendidos hacen que sea menos
complicado como se vea al principio, pero el prximo sistema que vayamos a
desarrollar nos ser un poco ms sencillo sin embargo no dejara de ser laborioso.
c. Qu problemas se tuvieron al trabajar en equipo?
Al principio tuvimos un poco de problema de comunicacin ya que pareca que
quedbamos bien de acuerdo y al entregar las tareas tenamos inconsistencias entre
lo que cada quien hara.
d. Cmo se solucionaron dichos problemas?
Decidimos asignar a un jefe de equipo, al principio ayudo un poco pero despus
tuvimos que realizar un cambio jefe, y esto nos ayud coordinramos mejor, tambin
hicimos uso de la tecnologa como el uso de WhatsApp para dialogar y ponernos de
acuerdo. Tambin tenamos breves reuniones despus de clase para discutir lo que no
haba quedado claro por mensajes.
e. Qu informacin proporciona cada uno de los siguientes diagramas UML: Clases,
Casos de Uso, Robustez, Secuencia, Colaboracin, Estado y Actividad? (Si copian y
pegan se anula)
Diagrama de clases:
Muestra de manera sencilla la relacin que existe entre los objetos a utilizar en el
sistema y permite realizar una depuracin de los mismos.
Diagrama de casos de uso:
Nos muestra claramente los caminos de accin que debemos seguir para cumplir con
el objetivo que es satisfacer las necesidades del cliente, tambin los caminos alternos
en caso de que un proceso falle.

Diagrama de robustez:
Nos ayuda a hacer una depuracin mas, para checar la lgica tanto de los caminos a
seguir como de los procesos a desarrollar.
Diagrama de secuencia:
Es un diagrama que nos permite ver la interaccin entre los objetos del sistema,
mediante el uso de mensajes que se mandan entre ellos.
Diagrama de colaboracin:
Al igual que el anterior se muestra que mensajes se mandan de un objeto a otro pero
se permite ver cmo van sucediendo los mensajes y las condiciones que deben de
cumplir.
Diagrama de estado:
Se muestran como su nombre lo indica los estadon por los que estn pasando los
objetos de una clase, se utilizan verbos en gerundio.
Diagrama de actividad:
Es el complementario del anterior ya que muestra las acciones que debe ejecutar un
objeto para llegar a un nuevo estado, aqu se utilizan los verbos en infinitivo.

FIN