Proyecto Final Uml

8/12/2019 Proyecto Final Uml

1/31

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


2/31

INTRODUCCINEn 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 decomponentes 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.


3/31

Planteamiento del ProblemaUna 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 hayexistencias 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 problemaEn 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.


4/31

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


5/31

Diagramas de casos de usoCaso 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 aun cliente, brindar informacin,vender, etc.

Control de inventarioSituaciones de control de inventarios,alta y baja de componentes, listados,etc

Gestin de proveedores Administracin de los proveedores yregistro de sus datosSe tienen los siguientes actores para los diagramas: Caso de uso Rol

ProveedorEs la persona o negocio que proveelos componentes electrnicos quevende la tienda

Cliente Representa los clientes que comprande la tienda los componentes

Atendedor

Representa el encargado de la tiendaque maneja el inventario, se encarga

de atender clientes y le maneja lascompras a proveedores
http://dns00.files.wordpress.com/2013/12/a.jpg


6/31

Caso de uso atencin a cliente expandido

Se tienen los siguientes casos de uso hijos de cliente Caso de uso Rol

Solicita informacin de componenteEs cuando un cliente quiere conocerla informacin de un componente y sela solicita al atendedor

Crear modificar cliente

Cuando es necesario crear un clientepara alguna operacin en el sistema,se necesita crearlo o actualizar susdatos

Adquiere componente

Cuando un cliente manifiesta quequiere adquirir un componente y segenera una factura que relaciona loselementos a llevar

Caso de uso control de inventario expandido

Se tienen los siguientes casos de uso hijos de inventario
http://dns00.files.wordpress.com/2013/12/ass.jpghttp://dns00.files.wordpress.com/2013/12/asd.jpghttp://dns00.files.wordpress.com/2013/12/ass.jpghttp://dns00.files.wordpress.com/2013/12/asd.jpg


7/31

Caso de uso Rol

Crear modificar componenteCuando llega un nuevo componente ala tienda o se deben actualizar losdatos de uno que ya est registrado

Alta inventario de componentesCuando llegan componentes, setienen registrados y se quiere poneruna cantidad de unidades disponiblesa la venta

Baja inventario de componentes Cuando se dan de baja por venta loscomponentes que estn disponibles

Consultar existencias de almacn

Cuando se quiere saber el inventariode componentes con unidadesdisponibles para la venta en el

almacn

Consultar componentes a ser pedidos

Ocurre cuando un cliente hasolicitado que se pidan componentesque no estn disponibles en la tiendapero que un proveedor si los vende,se guardan las solicitudes

Consultar piezas vendidas porproveedor

Es cuando se quiere conocer cualespiezas vende un proveedor y cualesproveedores venden una pieza

Baja inventario de componentesdefectuosos

Ocurre cuando un componente esencontrado defectuoso y debedisminuirse en la lista de disponibles

Caso de uso gestin de proveedores expandido

Se tienen los siguientes casos de uso hijos de proveedorCaso de uso Rol

Crear modificar proveedor

Ocurre cuando se debe crear yregistrar un proveedor o modificar laficha de uno de los que ya estnregistrados
http://dns00.files.wordpress.com/2013/12/asdff.jpg


8/31

Diagramas de actividadesEn 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 componentesCorresponde 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.
http://dns00.files.wordpress.com/2013/12/asxc.jpg


9/31

Componente/Alta inventarioCorresponde 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 inventarioCorresponde 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.
http://dns00.files.wordpress.com/2013/12/aac.jpghttp://dns00.files.wordpress.com/2013/12/afa.jpghttp://dns00.files.wordpress.com/2013/12/aac.jpghttp://dns00.files.wordpress.com/2013/12/afa.jpg


10/31


11/31

Componente/Consultar existenciasCorresponde al caso de uso consultar existencias del almacn parte del Caso de


Estos son los pasos que suceden cuando se quiere saber los componentes

disponibles para la venta.

Componente/Consultar proveedor de componente XCorresponde 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.
http://dns00.files.wordpress.com/2013/12/axs.jpghttp://dns00.files.wordpress.com/2013/12/ses.jpghttp://dns00.files.wordpress.com/2013/12/axs.jpghttp://dns00.files.wordpress.com/2013/12/ses.jpg


12/31

Cliente/Crear modificarCorresponde 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


Sucede cuando llegan componentes nuevos o hay que actualizar la informacin

que se tiene de ellos.
http://dns00.files.wordpress.com/2013/12/acsw.jpghttp://dns00.files.wordpress.com/2013/12/aswq.jpghttp://dns00.files.wordpress.com/2013/12/acsw.jpghttp://dns00.files.wordpress.com/2013/12/aswq.jpg


13/31

Proveedor/Crear modificarCorresponde 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 informacinCorresponde 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.
http://dns00.files.wordpress.com/2013/12/zsc.jpghttp://dns00.files.wordpress.com/2013/12/acss.jpghttp://dns00.files.wordpress.com/2013/12/zsc.jpghttp://dns00.files.wordpress.com/2013/12/acss.jpg


14/31

Diagrama de clasesEn 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 ydestructores 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.
http://dns00.files.wordpress.com/2013/12/avqq.jpg


15/31

Descripcin de las clasesA 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 unidentificador, pero no se grafica.Nombre de las clases utilizadas para plantear la solucin del problema: Clase Descripcin

ProveedorRepresenta las personas o negociosque proveen los componenteselectrnicos que vende la tienda

Componente Electrnico

Representa los componentes que latienda vende, y es tan genrica comopara contener mltiples tipos dedispositivos o elementos electrnicos

EntidadClase abstracta raz de proveedor ycliente, contiene los atributos que soncomunes a las dos clases hijas

SolicitudComponenteElectrnico

Representa las solicitudes que losclientes hacen a la tienda de que sepidan componentes electrnicos porencargo

Cliente

Representa los clientes que comprande la tienda los componentes, sonpersonas aunque puede tratarse deotros comercios

Factura

Representa la clase que agrupa unconjunto de componenteselectrnicos, y un cliente para hacerun registro que relaciona una ventaen especfico

Atributos de las clasesClase ProveedorTipo Nombre de atributo-Ninguno- -Ninguno-Para esta clase debe tenerse en cuenta que es hija de Entidad.


16/31

Clase Componente ElectrnicoTipo Nombre de atributoInteger cantidad DisponibleString nombreString descripcinString detalles TcnicosFloat precio VentaClase EntidadTipo Nombre de atributoString nombreString direccinString telfonoClase SolicitudComponenteElectrnicoTipo Nombre de atributoInteger fechaLas fechas en el esquema se tratan como marcas de tiempo unix.Clase ClienteTipo Nombre de atributo- Ninguno - - Ninguno -Para esta clase debe tenerse en cuenta que es hija de Entidad.Clase FacturaTipo Nombre de atributoInteger fechaFloat total VentaLas 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.


17/31

Diagramas de objetosEl 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 yestablecer reglas de completitud de los datos cuando se hace ingreso de

informacin, se pueden llegar a presentar inconsistencias con sus respectivas

complicaciones.
http://dns00.files.wordpress.com/2013/12/qqvqve.jpg


18/31

Diagramas de componentesEl 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

ServidorRepresenta la computadora quetendr el sistema de control de latienda

Ordenador de atendedorRepresenta el ordenador desde elcual se harn las conexiones alsistema de administracin

PhpEs el lenguaje y el tipo de programasen que se escribir la lgica denegocio del proyecto

Apache

Representa el servidor web como labase de datos que se usar pararealizar las conexiones de red ypersistencia de datos para el sistema

Sistema operativo compatible Representa el software que maneja elhardware del servidor, puede
http://dns00.files.wordpress.com/2013/12/acacca.jpg


19/31

encontrarse tambin en el equipo delatendedor. Puede ser por ejemploGNU/Linux

Interfaz de administracin htmlCorresponde a la interfaz grfica

implementada en el lenguaje htmlpara diseo webEl conjunto de componentes descritos interaccionan holsticamente dando como

resultado la implementacin del sistema tanto hardware como software.

Diagramas de secuenciaEn 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 pasose 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.


20/31

Adquirir/Adquiere componentesCorresponde 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.
http://dns00.files.wordpress.com/2013/12/acsazx.jpg


21/31

Componente/Alta inventarioCorresponde al caso de uso alta inventario de componentes parte del Caso de uso


Del diagrama de actividades se sabe que hay bifurcaciones en el paso 2. Elplanteamiento 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 inventarioCorresponde al caso de uso baja inventario de componentes parte del Caso de

http://dns00.files.wordpress.com/2013/12/azx.jpg


22/31

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

defectuososCorresponde al caso de uso baja inventario de componentes defectuosos parte delCaso de uso control de inventario expandido.
http://dns00.files.wordpress.com/2013/12/ca.jpg


23/31

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 pedirCorresponde al caso de uso consultar componentes a ser pedidos parte del Caso

de uso control de inventario expandido.
http://dns00.files.wordpress.com/2013/12/qfe.jpghttp://dns00.files.wordpress.com/2013/12/qcce.jpghttp://dns00.files.wordpress.com/2013/12/qfe.jpghttp://dns00.files.wordpress.com/2013/12/qcce.jpg


24/31

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 existenciasCorresponde al caso de uso consultar existencias del almacn parte del Caso de


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 XCorresponde al caso de uso consultar piezas vendidas por proveedor parte del

Caso de uso control de inventario expandido.
http://dns00.files.wordpress.com/2013/12/cqs.jpg


25/31

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 elatendedor 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 modificarCorresponde al caso de uso crear modificar cliente parte del Caso de uso atencin

a cliente expandido.
http://dns00.files.wordpress.com/2013/12/qver.jpg


26/31

Del diagrama de actividades se sabe que hay bifurcaciones en el paso 4. Sucede

cuando es requerido registrar un cliente en el sistema.
http://dns00.files.wordpress.com/2013/12/qverrq.jpg


27/31

Componente/Crear modificarCorresponde al caso de uso crear modificar componente parte del Caso de uso


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 modificarCorresponde al caso de uso crear modificar proveedor parte del Caso de uso

gestin de proveedores expandido.
http://dns00.files.wordpress.com/2013/12/zacaqcce.jpg


28/31

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

Componente/Solicitar informacinCorresponde 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
http://dns00.files.wordpress.com/2013/12/qdwqxc.jpghttp://dns00.files.wordpress.com/2013/12/qvrbw.jpghttp://dns00.files.wordpress.com/2013/12/qdwqxc.jpghttp://dns00.files.wordpress.com/2013/12/qvrbw.jpg


29/31

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


30/31

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


31/31

ReferentesHarold 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, 2002Anlisis y Diseo de Sistemas de Informacin, Senn James, Editorial Mc Graw HillEl lenguaje Unificado de Modelado, Booch Graby, Rumbaugh James, Jacobson

Ivar, Edit Addison Wesly, 2002The Unified Modeling Lenguaje User Guide, Booch Graby, Rumbaugh James,

Jacobson Ivar Edit Addison Wesley Longman Inc, 1999Anlisis 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:
http://datateca.unad.edu.co/contenidos/200609/exeuml/http://datateca.unad.edu.co/contenidos/200609/exeuml/http://datateca.unad.edu.co/contenidos/200609/exeuml/

Documents

Proyecto Final Uml