PROYECTO FINAL UML

TUTOR:
NILSON ALBEIRO FERREIRA MANZANARES



PRESENTADO POR:
EDUARDO LUIS ENAMORADO
JUAN DAVID TABORDA AVILEZ
YAIR DIAZ GONZALEZ


GRUPO: 15


UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
"UNAD"
ESCUELA DE CIENCIAS BSICAS TEGNOLOGIA E INGENIERIA


JUNIO DEL 2014
INTRODUCCIN
En el presente trabajo se da a solucin mediante el anlisis de UML y el diseo de
interfaces de usuario completando la visualizacin, especificacin, construccin y
documentacin de los requerimientos de software para una tienda de
componentes electrnicos mediante la construccin de un sistema de informacin
y que desea mejorar su diseo y buscar una propuesta para su implementacin
mediante la asesora de un estudiante de la UNAD.
Se describe un conjunto de clases, los procesos, los casos de uso, las secuencias
lgicas bsicas para hacer una representacin del modelo de informacin del
sistema a implementar.
Para el desarrollo de esta actividad se tuvo en cuenta el material proporcionado
por la universidad en el mdulo del curso, informacin consultada en la bibliografa
y el material de apoyo recibido en las prcticas presenciales, con lo que se
construye una propuesta en modelo de una solucin para la tienda con la que se
pretende, al seguir un proceso de reconocimiento de informacin ms profundo y
de especificacin de requerimientos, que se implemente el sistema y se tenga
operativo para optimizar el funcionamiento de la organizacin.


Objetivos
Transferir los conocimientos generados durante el desarrollo del curso del
lenguaje UML a travs del desarrollo del proyecto propuesto.
Identificar los procesos con los cuales se desarrolla un proyecto utilizando el
modelado orientado a objetos propuesto por UML
Desarrollar un proyecto a partir de un caso real que permita crear los diferentes
diagramas utilizados en UML para organizar los planos de software del
problema planteado.






Planteamiento del Problema
Una tienda especializada en componentes electrnicos, compra sus existencias a
una serie de proveedores, vendindolas posteriormente a sus clientes; a su vez se
lleva el control de almacn de sus existencias en todo momento.
La gestin de proveedores lleva unida la gestin de los datos administrativos de
stos ms la informacin de los componentes que cada proveedor vende. La
gestin de proveedores, adems del tpico mantenimiento de los datos
relacionados, se encarga de generar los listados de las piezas vendidas por un
determinado proveedor, o los proveedores que venden una determinada pieza.
Cuando un cliente solicita un determinado componente, se comprueba que hay
existencias y se le informa de su precio. Si el cliente adquiere el producto, se
actualizar el almacn y se le emitir una factura. Si no hay existencias del
componente, pero el cliente est interesado se proceder a almacenar la peticin
con objeto de realizar el correspondiente pedido al proveedor.
El control de almacn se encarga de tener actualizado el almacn de existencias,
dando de alta los componentes que llegan, eliminando componentes defectuosos,
y realizando los listados de componentes disponibles en el almacn y de los
componentes pendientes de ser pedidos a un proveedor.
Solucin del problema
En el desarrollo de las soluciones de diseo UML y de interfaz grfica que se
plasma en este documento se realizaron varios procesos de anlisis que
permitieron el entendimiento y la posibilidad de la construccin de un modelo de
software que soluciona los requerimientos.
El primer paso que se hizo fue la lectura repetida del enunciado del problema,
identificando los actores, casos de uso, entidades y verbos que intervienen en las
interacciones para lograr una apropiacin del problema con una vista general de
los requerimientos manifestados por la tienda.
El siguiente paso realizado en la construccin de la solucin fue la especificacin y
definicin de los diferentes casos de uso que se extraen del planteamiento del
enunciado y de los que son implcitos y necesarios para que la funcionalidad del
sistema sea lgica y realizable por un sistema de informacin.
Una vez se definieron los casos de uso correspondientes a las actividades del
sistema, se procedi a documentar estas actividades mirando los requisitos
lgicos para la ejecucin de cada caso de uso, esto permiti un entendimiento
mas operativo de las necesidades del cliente en su negocio.
Mediante la definicin de las actividades, los datos proporcionados por el
enunciado y las inferencias de los casos de uso se definieron las clases del
dominio del problema, especificando sus nombres, y atributos buscando un
entendimiento general del problema y su solucin mediante la orientacin a
objetos.
Luego de la especificacin de clases se hizo una captura esttica del sistema
reflejado en un diagrama de objetos que muestra las asociaciones de multiplicidad
entre las clases del sistema de informacin y las instancias con nombre requeridas
para el funcionamiento del sistema.
Los componentes del sistema se detallan en el correspondiente diagrama de
componentes, que refleja los subsistemas necesarios para el funcionamiento de la
solucin de software en una implementacin en un servidor y un ordenador cliente.
Los diagramas de secuencia que se implementan a continuacin permiten la
especificacin mas puntual de los mensajes que se envan entre los componentes
e instancias de cada interaccin, estas interacciones se corresponden con los
diagramas de actividades y los casos de uso correspondientes.
En el ltimo paso de la ejecucin de esta solucin se disea la implementacin de
la interfaz grfica a manera de esquema de gua que permite organizar los
dilogos y los procesos de interaccin entre un atendedor y el sistema de
informacin como se construira en software para su uso cotidiano en la tienda.



Diagramas de casos de uso
Caso de uso principal

Se tienen los siguientes casos de uso:
Caso de uso Rol
Atencin a cliente
Grupo de casos de uso que tratan las
situaciones en que hay que atender a
un cliente, brindar informacin,
vender, etc.
Control de inventario
Situaciones de control de inventarios,
alta y baja de componentes, listados,
etc
Gestin de proveedores
Administracin de los proveedores y
registro de sus datos
Se tienen los siguientes actores para los diagramas:
Caso de uso Rol
Proveedor
Es la persona o negocio que provee
los componentes electrnicos que
vende la tienda
Cliente
Representa los clientes que compran
de la tienda los componentes
Atendedor
Representa el encargado de la tienda
que maneja el inventario, se encarga
de atender clientes y le maneja las
compras a proveedores




Caso de uso atencin a cliente expandido


Se tienen los siguientes casos de uso hijos de cliente
Caso de uso Rol
Solicita informacin de componente
Es cuando un cliente quiere conocer
la informacin de un componente y se
la solicita al atendedor
Crear modificar cliente
Cuando es necesario crear un cliente
para alguna operacin en el sistema,
se necesita crearlo o actualizar sus
datos
Adquiere componente
Cuando un cliente manifiesta que
quiere adquirir un componente y se
genera una factura que relaciona los
elementos a llevar


Caso de uso control de inventario expandido

Se tienen los siguientes casos de uso hijos de inventario
Caso de uso Rol
Crear modificar componente
Cuando llega un nuevo componente a
la tienda o se deben actualizar los
datos de uno que ya est registrado
Alta inventario de componentes
Cuando llegan componentes, se
tienen registrados y se quiere poner
una cantidad de unidades disponibles
a la venta
Baja inventario de componentes
Cuando se dan de baja por venta los
componentes que estn disponibles
Consultar existencias de almacn
Cuando se quiere saber el inventario
de componentes con unidades
disponibles para la venta en el
almacn
Consultar componentes a ser pedidos
Ocurre cuando un cliente ha
solicitado que se pidan componentes
que no estn disponibles en la tienda
pero que un proveedor si los vende,
se guardan las solicitudes
Consultar piezas vendidas por
proveedor
Es cuando se quiere conocer cuales
piezas vende un proveedor y cuales
proveedores venden una pieza
Baja inventario de componentes
defectuosos
Ocurre cuando un componente es
encontrado defectuoso y debe
disminuirse en la lista de disponibles

Caso de uso gestin de proveedores expandido

Se tienen los siguientes casos de uso hijos de proveedor
Caso de uso Rol
Crear modificar proveedor
Ocurre cuando se debe crear y
registrar un proveedor o modificar la
ficha de uno de los que ya estn
registrados
Diagramas de actividades
En la realizacin de las actividades de los casos de uso del sistema se detallan los
procesos de adquisicin de informacin, consignacin de informacin, interaccin
con los actores, informes, etc. Se detallan a continuacin.

Adquirir/Adquiere componentes
Corresponde al caso de uso adquiere de componente parte del Caso de uso
atencin a cliente expandido.

La accin pasar a caja y bodega a entregar es una actividad que es externa al
sistema, sucede cuando un usuario recibe instrucciones para ir a pagar y una vez
hecho, recibir los componentes.







Componente/Alta inventario
Corresponde al caso de uso alta inventario de componentes parte del Caso de uso
control de inventario expandido.

El planteamiento de la actividad no detalla de registros ni fichas de entrada y
salida, por lo que se ingresa y da de baja la mercanca sin generar registros ni
papeleo adicional.
Componente/Baja inventario
Corresponde al caso de uso baja inventario de componentes parte del Caso de
uso control de inventario expandido.

El problema no habla de registros ni fichas de entrada y salida, por lo que se
ingresa y da de baja la mercanca sin generar registros ni papeleo adicional.
Componente/Baja inventario componentes
defectuosos
Corresponde al caso de uso baja inventario de componentes defectuosos parte del
Caso de uso control de inventario expandido.

El problema no habla de registros ni fichas de entrada y salida, por lo que se
ingresa y da de baja la mercanca sin generar registros ni papeleo adicional.

Componente/Consultar componentes por pedir
Corresponde al caso de uso consultar componentes a ser pedidos parte del Caso
de uso control de inventario expandido.

Estas son las acciones cuando se ha hecho una solicitud para comprar un
componente bajo pedido de un cliente.






Componente/Consultar existencias
Corresponde al caso de uso consultar existencias del almacn parte del Caso de
uso control de inventario expandido.

Estos son los pasos que suceden cuando se quiere saber los componentes
disponibles para la venta.

Componente/Consultar proveedor de componente X
Corresponde al caso de uso consultar piezas vendidas por proveedor parte del
Caso de uso control de inventario expandido.

La consulta a proveedores sobre la disponibilidad de un componente x es externa
al sistema, en esta situacin el atendedor tendr que verificar en el sistema si un
componente est registrado, en caso negativo deber llamar a los proveedores y
consultarles si tienen disponibilidad de un componente como el que se necesita.
Cliente/Crear modificar
Corresponde al caso de uso crear modificar cliente parte del Caso de uso atencin
a cliente expandido.

Sucede cuando es requerido registrar un cliente en el sistema.

Componente/Crear modificar
Corresponde al caso de uso crear modificar componente parte del Caso de uso
control de inventario expandido.

Sucede cuando llegan componentes nuevos o hay que actualizar la informacin
que se tiene de ellos.
Proveedor/Crear modificar
Corresponde al caso de uso crear modificar proveedor parte del Caso de uso
gestin de proveedores expandido.

Este es el proceso para registrar proveedores.

Componente/Solicitar informacin
Corresponde al caso de uso solicita informacin de componente parte del Caso de
uso atencin a cliente expandido.

Cuando un cliente solicita informacin de un componente el atendedor intenta
entregrsela de acuerdo a los registros del sistema.

Diagrama de clases
En el anlisis del enunciado del sistema se encuentran las definiciones de las
clases, sus atributos y sus relaciones, aunque en algunos casos son difciles de
identificar. A continuacin se muestra el diagrama de clases que muestra el
nombre de las clases, los objetos asociados, los atributos que distinguen las
clases, las funciones, responsabilidades y sus relaciones. Los atributos,
operaciones y elementos demasiado obvios no se incluyen en el diagrama
buscando la facilidad de comprensin y la simplicidad en el diseo.
En el diagrama se observan las relaciones entre las clases, se sabe que las
relaciones al trabajarse un esquema orientado a objetos mediante la persistencia,
se usan los identificadores de las instancias de clase. No se grafican para facilitar
el entendimiento del modelo.
Los mtodos a usar en las clases son getters y setters comunes, constructores y
destructores genricos que se usan para la instanciacin, modificacin de
atributos y persistencia de los datos, no se especifican debido a ser los mismos
para todas las clases y entenderse que el lector de este documento conoce estos
temas.
El problema no habla de mltiples atendedores, por lo que se asume que es uno
solo y no se crea una entidad para representarlo.


Descripcin de las clases
A continuacin se desarrolla la descripcin ampliada de las clases mostradas en el
diagrama. Las clases que se han diseado se ha reducido la cantidad de
operaciones y atributos al mnimo para facilitar su fcil entendimiento, se sobre
entiende que las clases tienen atributos que definen su unicidad mediante un
identificador, pero no se grafica.
Nombre de las clases utilizadas para plantear la solucin del problema:
Clase Descripcin
Proveedor
Representa las personas o negocios
que proveen los componentes
electrnicos que vende la tienda
Componente Electrnico
Representa los componentes que la
tienda vende, y es tan genrica como
para contener mltiples tipos de
dispositivos o elementos electrnicos
Entidad
Clase abstracta raz de proveedor y
cliente, contiene los atributos que son
comunes a las dos clases hijas
SolicitudComponenteElectrnico
Representa las solicitudes que los
clientes hacen a la tienda de que se
pidan componentes electrnicos por
encargo
Cliente
Representa los clientes que compran
de la tienda los componentes, son
personas aunque puede tratarse de
otros comercios
Factura
Representa la clase que agrupa un
conjunto de componentes
electrnicos, y un cliente para hacer
un registro que relaciona una venta
en especfico
Atributos de las clases
Clase Proveedor
Tipo Nombre de atributo
-Ninguno- -Ninguno-
Para esta clase debe tenerse en cuenta que es hija de Entidad.
Clase Componente Electrnico
Tipo Nombre de atributo
Integer cantidad Disponible
String nombre
String descripcin
String detalles Tcnicos
Float precio Venta
Clase Entidad
Tipo Nombre de atributo
String nombre
String direccin
String telfono
Clase SolicitudComponenteElectrnico
Tipo Nombre de atributo
Integer fecha
Las fechas en el esquema se tratan como marcas de tiempo unix.
Clase Cliente
Tipo Nombre de atributo
- Ninguno - - Ninguno -
Para esta clase debe tenerse en cuenta que es hija de Entidad.
Clase Factura
Tipo Nombre de atributo
Integer fecha
Float total Venta
Las fechas en el esquema se tratan como marcas de tiempo Unix. El total de una
venta es la suma de los precios individuales de los componentes relacionados.


Diagramas de objetos
El siguiente diagrama de objetos muestra la vista esttica del funcionamiento del
sistema, en especial de las relaciones que existen entre instancias de objetos.
Se puede observar que no se grafican los atributos de unicidad buscando dar la
mayor simplicidad al modelo y facilitar su entendimiento.
Se puede observar como en los nombres de los atributos que se especificaron
para cada clases se asignan valores que estn en concordancia con el tipo de
datos de cada uno.


En la relacin que hay entre la instancia c de la clase ComponenteElectrnico y la
instancia p de la clase Proveedor se puede observar que esta ltima no tiene
indicado atributos, lo que significa que en el sistema de no tenerse cuidado y
establecer reglas de completitud de los datos cuando se hace ingreso de
informacin, se pueden llegar a presentar inconsistencias con sus respectivas
complicaciones.

Diagramas de componentes
El desarrollo de la solucin de software requiere que todos los componentes
abstractos de clases y relaciones se puedan implementar en objetos fsicos como
servidores y ordenadores que hacen los roles de contenedores de la solucin y
ejecutores de las instrucciones que corresponden a los procesos de entrada y
salida de datos del sistema.

En este diagrama se observan dos componentes principales que son Servidor y
Ordenador de usuario, para entrar mas en detalle se explica cada uno y sus
componentes en la siguiente tabla.
Componente Descripcin
Servidor
Representa la computadora que
tendr el sistema de control de la
tienda
Ordenador de atendedor
Representa el ordenador desde el
cual se harn las conexiones al
sistema de administracin
Php
Es el lenguaje y el tipo de programas
en que se escribir la lgica de
negocio del proyecto
Apache
Representa el servidor web como la
base de datos que se usar para
realizar las conexiones de red y
persistencia de datos para el sistema
Sistema operativo compatible
Representa el software que maneja el
hardware del servidor, puede
encontrarse tambin en el equipo del
atendedor. Puede ser por ejemplo
GNU/Linux
Interfaz de administracin html
Corresponde a la interfaz grfica
implementada en el lenguaje html
para diseo web
El conjunto de componentes descritos interaccionan holsticamente dando como
resultado la implementacin del sistema tanto hardware como software.

Diagramas de secuencia
En esta seccin se muestran los conjuntos de pasos a ejecutarse en las
interacciones de los elementos del sistema TIENDIA. Se usa la graficacin
mediante UML de una manera sencilla que permita el entendimiento de los pasos
e interacciones en un nivel de detalle intermedio para ilustrar como fluyen los
algoritmos en su ejecucin normal.
Los diagramas de secuencia son conocidos por la dificultad que tienen para
representar las bifurcaciones lgicas en el curso de un algoritmo, es por esto que
para aclarar se establece que los diagramas mostrados a continuacin
representan el flujo normal de ejecucin, sin las posibles bifurcaciones que pueden
presentarse en los diferentes diagramas; para entenderlo mejor, basta con
comparar el conjunto de pasos representado en un diagrama de estos y su
correspondiente diagrama de actividades que se encuentra en una seccin
anterior de este documento.
Los grficos de secuencia que se muestran corresponden al diagrama de
actividades del mismo nombre.










Adquirir/Adquiere componentes
Corresponde al caso de uso adquiere de componente parte del Caso de uso
atencin a cliente expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 2 y 6. La
actividad 14: En cliente va a caja y se lleva su mercanca una vez pago, es
realizada externamente al sistema pero se representa para mostrar el flujo de
acciones de los actores.
Componente/Alta inventario
Corresponde al caso de uso alta inventario de componentes parte del Caso de uso
control de inventario expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 2. El
planteamiento de la actividad no detalla de registros ni fichas de entrada y salida,
por lo que se ingresa y da de baja la mercanca sin generar registros ni papeleo
adicional.

Componente/Baja inventario
Corresponde al caso de uso baja inventario de componentes parte del Caso de
uso control de inventario expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 5. El
planteamiento de la actividad no detalla de registros ni fichas de entrada y salida,
por lo que se ingresa y da de baja la mercanca sin generar registros ni papeleo
adicional.


Componente/Baja inventario componentes
defectuosos
Corresponde al caso de uso baja inventario de componentes defectuosos parte del
Caso de uso control de inventario expandido.

Del diagrama de actividades no se encuentran bifurcaciones. El planteamiento de
la actividad no detalla de registros ni fichas de entrada y salida, por lo que se
ingresa y da de baja la mercanca sin generar registros ni papeleo adicional.

Componente/Consultar componentes por pedir
Corresponde al caso de uso consultar componentes a ser pedidos parte del Caso
de uso control de inventario expandido.

Del diagrama de actividades no se encuentran bifurcaciones. Estas son las
acciones cuando se ha hecho una solicitud para comprar un componente bajo
pedido de un cliente.

Componente/Consultar existencias
Corresponde al caso de uso consultar existencias del almacn parte del Caso de
uso control de inventario expandido.

Del diagrama de actividades no se encuentran bifurcaciones. Estos son los pasos
que suceden cuando se quiere saber los componentes disponibles para la venta.

Componente/Consultar proveedor de componente X
Corresponde al caso de uso consultar piezas vendidas por proveedor parte del
Caso de uso control de inventario expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 2, en este
caso se omite el correspondiente bule para consultar otro elemento debido a que
el ciblo bsico de ejecucin ya se muestra. La consulta a proveedores sobre la
disponibilidad de un componente x es externa al sistema, en esta situacin el
atendedor tendr que verificar en el sistema si un componente est registrado, en
caso negativo deber llamar a los proveedores y consultarles si tienen
disponibilidad de un componente como el que se necesita.

Cliente/Crear modificar
Corresponde al caso de uso crear modificar cliente parte del Caso de uso atencin
a cliente expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 4. Sucede
cuando es requerido registrar un cliente en el sistema.












Componente/Crear modificar
Corresponde al caso de uso crear modificar componente parte del Caso de uso
control de inventario expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 2. Sucede
cuando llegan componentes nuevos o hay que actualizar la informacin que se
tiene de ellos.

Proveedor/Crear modificar
Corresponde al caso de uso crear modificar proveedor parte del Caso de uso
gestin de proveedores expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 4. Este es
el proceso para registrar proveedores.

Componente/Solicitar informacin
Corresponde al caso de uso solicita informacin de componente parte del Caso de
uso atencin a cliente expandido.

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 2. A
diferencia del diagrama de actividades se tiene que en este diagrama se verifica
que el componente est registrado, en el de actividades se tiene que se verifica la
existencia en bodega; la diferencia en el comportamiento corresponde a la
necesidad de mostrar en detalle los pasos del proceso en este diagrama, mientras
que en el de actividades se tiene una vista de mas alto nivel

Diseo de Interfaz grfica
En la construccin de la solucin para el presente proyecto se implementaron las
siguientes pantallas como un bosquejo del programa que organizar los dilogos
de interaccin entre el atendedor del sistema y la lgica de negocio.
En los grficos se observa que en la parte superior izquierda se encuentran los
botones de minimizar, maximizar y cierre; lo que esto significa es que la aplicacin
debe ejecutarse a pantalla completa sin la vista de barras de herramientas como
sucede generalmente en los navegadores web comunes.






















Conclusiones

Al finalizar este trabajo de final de diseo y especificacin se puede afirmar con
claridad que se ha asimilado la lgica y la organizacin de UML, dado que este
lenguaje permite los desarrolladores de software poder elaborar un mapa
utilizando base de datos relacional o la programacin orientados a objetos,
partiendo del anlisis y la organizacin del problema que se este analizando,
por varias razones es bastante significativa esta experiencia ya que
proporciona al estudiante la destreza en la elaboracin e identificacin de los
diferentes elementos que se manejan en un diagrama de clases como los
objetos, atributos, responsabilidades, funciones y dems que son
determinantes en construccin de software con calidad.
Se ha identificado la importancia de construir los diferentes diagramas UML
para facilitar la lectura y poder compartir el diseo de la construccin de un
sistema de informacin con personas que no estn completamente
involucradas en el desarrollo como muy importante debido a que es frecuente
que no se pueda explicar mediante solamente palabras la arquitectura de este.
La notacin UML se fundamenta en principios de modelado, lo cual es
importante para toda implementacin de un sistema de informacin, se adopt
el proceso unificado de desarrollo para modelar las actividades del proyecto de
administracin de la tienda, se crearon los diagramas a utilizar en las diferentes
etapas del desarrollo del sistema de informacin segn las variaciones
dependiendo del tamao y las interacciones de cada caso de uso aprendiendo
de forma colateral el uso de las herramientas StarUML y Pencil.











Referentes
Harold Emilio Cabrera Meza. Mdulo Lenguaje Unificado de Modelado. UNAD.
2013 Material didctico. UNAD. Colombia. Consultado el 25 de Noviembre de
2013, en la pgina web:
http://datateca.unad.edu.co/contenidos/200609/exeuml/
Mdulo Lenguaje Unificado de Modelado UML, Harold Emilio Cabrera Meza et al,
UNAD. 2013.
El proceso Unificado de desarrollo de software, Booch Graby, Rumbaugh James,
Jacobson Ivar, Edit Addison Wesly, 2002
Anlisis y Diseo de Sistemas de Informacin, Senn James, Editorial Mc Graw Hill
El lenguaje Unificado de Modelado, Booch Graby, Rumbaugh James, Jacobson
Ivar, Edit Addison Wesly, 2002
The Unified Modeling Lenguaje User Guide, Booch Graby, Rumbaugh James,
Jacobson Ivar Edit Addison Wesley Longman Inc, 1999
Anlisis y Diseo de Sistemas, Kendall && Kendall, Editorial Prentice Hall.
Herramienta para Prototipos de GUI Pencil. Iluminaticsac peru. Consultado el 25
de Noviembre, en la pgina web: