1. UML (Qué es y los diferentes tipos de diagramas que lo
componen)
UML son las siglas de “Unified Modeling Language” o
“Lenguaje Unificado de Modelado”. Se trata de un estándar que se ha adoptado a
nivel internacional por numerosos organismos y empresas para crear esquemas,
diagramas y documentación relativa a los desarrollos de software (programas
informáticos).
UML es una herramienta propia de personas que tienen
conocimientos relativamente avanzados de programación y es frecuentemente usada
por analistas funcionales (aquellos que definen qué debe hacer un programa sin
entrar a escribir el código) y analistas-programadores (aquellos que, dado un
problema, lo estudian y escriben el código informático para resolverlo en un
lenguaje como Java, C#, Python o cualquier otro).
TIPOS
DE DIAGRAMAS EN UML
Usando
UML se pueden construir numerosos tipos de diagramas. Vamos a citar algunos:
Diagramas
de casos de uso: representan a los actores y casos de uso (procesos
principales) que intervienen en un desarrollo de software.
Diagramas
de clases: para UML una clase es una entidad, no una clase software. Un
diagrama de clases UML puede ser un diagrama del dominio o representación de
conceptos que intervienen en un problema, o también un diagrama de clases
software. El sentido de un diagrama UML se lo da la persona que lo construye.
Diagramas
de secuencia: suelen usarse para representar objetos software y el intercambio
de mensajes entre ellos, representando la aparición de nuevos objetos de
izquierda a derecha.
Diagramas
de colaboración: suelen usarse para representar objetos o clases y la forma en
que se transmiten mensajes y colaboran entre ellos para cumplir un objetivo.
Diagramas
de estados: suelen usarse para representar cómo evoluciona un sistema (cómo va
cambiando de estado) a medida que se producen determinados eventos.
Otros
diagramas: diagramas de actividad, diagramas de paquetes, diagramas de
arquitectura software, etc.
●
Actor:
Un Actor es un rol que un usuario juega
con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un
Actor no necesariamente representa a una persona en particular, sino más bien
la labor que realiza frente al sistema.
●
Caso de Uso:
Es una operación/tarea
específica que se realiza tras una orden de algún agente externo, sea desde una
petición de un actor o bien desde la invocación desde otro caso de uso.
Este
diagrama representa la funcionalidad completa de un sistema (o una clase)
mostrando su interacción con los agentes externos. Esta representación se hace
a través de las relaciones entre los actores (agentes externos) y los casos de
uso (acciones) dentro del sistema. Los diagramas de casos de uso definen
conjuntos de funcionalidades afines que el sistema debe cumplir para satisfacer
todos requerimientos que tiene a su cargo
- Dominio
es un
artefacto de la disciplina de análisis , construido con las reglas de UML
durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado como
uno o más diagramas de clases y que contiene, no conceptos propios de un
sistema de software sino de la propia realidad física.
- Relación
●
Asociación
●
Es el tipo de relación más
básica que indica la invocación desde un actor o caso de uso a otra operación
(caso de uso). Dicha relación se denota con una flecha simple.
●
Dependencia o Instanciación
●
Generalización
●
Este tipo de relación es
uno de los más utilizados, cumple una doble función dependiendo de su
estereotipo, que puede ser de Uso (<<uses>>) o de Herencia
(<<extends>>).
●
Este tipo de relación esta
orientado exclusivamente para casos de uso (y no para actores).
●
extends: Se recomienda
utilizar cuando un caso de uso es similar a otro (características).
●
uses: Se recomienda
utilizar cuando se tiene un conjunto de características que son similares en
más de un caso de uso y no se desea mantener copiada la descripción de la
característica.
●
De lo anterior cabe
mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en
donde está la duda clásica de usar o heredar.
2- Que es un Diagrama de Casos de Uso y
para qué sirve?
es
una secuencia de transacciones que son desarrolladas por un sistema en
respuesta a un evento que inicia un actor sobre el propio sistema. Los
diagramas de casos de uso sirven para especificar la funcionalidad y el
comportamiento de un sistema mediante su interacción con los usuarios y/o otros
sistemas.
3- Tome como
referencia un Sistema de Información cualquiera (ficticio o real que no sea su
proyecto formativo), describa 5 requerimientos de dicho sistema.
NECESIDAD
Es necesario desarrollar un aplicativo web que permita
controlar la contabilidad, inventarios y ventas de la empresa.
Meta:
El software
se encargará de la contabilidad, inventario y ventas de productos.
Objetivos generales:
Permitir a
la empresa realizar el control de la contabilidad, inventario y ventas de
productos de una manera más ágil y eficiente por medio del aplicativo.
Requisitos
funcionales;
● El sistema debe permitir registrar, modificar y actualizar
los usuarios
● El sistema debe permitir registrar, modificar y actualizar
las ventas.
● El sistema debe permitir control de inventario.
● El sistema debe permitir control de compras y ventas.
● El sistema debe permitir registrar, modificar y actualizar
los proveedores.
Diagrama de Casos de Uso
Actores
Actor
|
AC.1 Comprador
|
Descripción
|
El
cliente es el comprador de los productos del almacén
|
Fuentes
|
Gerente, despachó de bodega y
vendedor
|
Actor
|
AC. 2 Vendedor
|
Descripción
|
Encargados de enseñar
productos y venderlos a los clientes y recibir pagos
|
Fuentes
|
Gerente, despachó de bodega y vendedor
|
Nombre
|
Venta de
articulo / CU - 1
|
|
Actor
|
ACT.1 Comprador / ACT-2
Vendedor
|
|
Descripción
|
Describe el proceso de
venta de artículo
|
|
Flujo
principal
|
Eventos
actor
|
Sistema
|
1.El comprador pide un
artículo
|
||
2.Vendedor muestra
artículos
|
||
3. Comprador selecciona
artículos
|
||
4.Vendedor registra
compra
|
4.El sistema crea factura
|
|
Flujo alterno
|
1.Vendedor Entrega imprime
factura
|
1.Imprime factura
|
Precondición
|
El Vendedor cuenta con un
dispositivo que le permite registrar la compra
|
|
Poscondición
|
El cliente selecciona un
artículo para la compra
|
|
Presunción
|
El vendedor dispone solo
de los artículos que tiene en la tienda
|
|
Actor
|
AC.3 Despachador de
bodega
|
Descripción
|
Es el
encargado de surtir los artículos a la tienda
|
Fuentes
|
Gerente, despachó de bodega y
vendedor
|
Actor
|
AC. 4 Vendedor
|
Descripción
|
Se encarga de recibir los
artículos
|
Fuentes
|
Gerente, despachó de bodega y vendedor
|
Nombre
|
Inventario
/ CU - 2
|
|
Actor
|
ACT.3 Despacho de bodega
/ ACT-4 Vendedor
|
|
Descripción
|
Describe el proceso de
compra y pagos de los artículos que ingresan a la bodega
|
|
Flujo
principal
|
Eventos
actor
|
Sistema
|
1.El gerente hace el
pedido
|
El sistema guarda el
informe
|
|
2.El proveedor toma el
pedido
|
El sistema guarda el
informe
|
|
3.El proveedor envía el
pedido
|
El sistema guarda el
informe
|
|
4.El jefe de bodega
recibe el pedido
|
El sistema guarda el
informe y actualiza el inventario
|
|
5.El gerente paga pedido
|
El sistema guarda el
informe
|
|
6.El proveedor recibe
pago
|
El sistema guarda el
informe
|
|
Flujo alterno
|
1.Proveedor y jefe de bodega
imprime informe
|
1.Imprime informe
|
Precondición
|
El Gerente, Proveedor y
Jefe de bodega cuenta con un dispositivo que le permite guardar el informe e
imprimir
|
|
Poscondición
|
El Proveedor debe enviar
los artículos
|
|
Presunción
|
El vendedor ingresar los
artículos que tiene en la tienda
|
|
Actor
|
AC.5 Gerente
|
Descripción
|
Es el
encargado de hacer y cancelar los pedidos al proveedor
|
Fuentes
|
Gerente, Jefe de bodega y proveedor
|
Actor
|
AC. 6 Proveedor
|
Descripción
|
Se encarga de enviar y
recibir pago de artículos
|
Fuentes
|
Gerente, Jefe de bodega y Proveedor
|
Actor
|
AC.7 Jefe de bodega
|
Descripción
|
Es quien
recibe los artículos
|
Fuentes
|
Gerente, Jefe de bodega y Proveedor
|
Nombre
|
Compras
/ CU - 3
|
|
Actor
|
ACT. 5 Gerente / ACT.6
Proveedor/ ACT.7 Jefe de bodega
|
|
Descripción
|
Describe el proceso del
proceso de transferencia de artículos de bodega a la tienda
|
|
Flujo
principal
|
Eventos
actor
|
Sistema
|
1.El despachador
selecciona los artículos para enviar
|
El sistema guarda el informe
y actualiza bodega
|
|
2.Vendedor recibe
artículos
|
El sistema guarda el informe
y actualiza tienda
|
|
Flujo alterno
|
1.Despachador imprime
informe
|
1.Imprime informe
|
Precondición
|
El Vendedor y el
despachador cuenta con un dispositivo que le permite registrar la
transferencia
|
|
Poscondición
|
El despachador debe
enviar artículos
|
|
Presunción
|
El vendedor ingresar los
artículos que tiene en la tienda
|
|
5. De acuerdo a la lista que se encuentra debajo,
analice los casos de uso que le corresponden. Trate de definir qué requisito
funcional describen (en los que sea posible) y detalle en palabras todo lo que está
representado en el caso de uso.
(algunos no están en español :))
33 Requisitos
funcionales;
● El sistema debe permitir listar los contactos.
● El sistema debe permitir investigar los contactos.
● El sistema debe permitir registrar los contactos.
● El sistema debe permitir editar los contactos
● El sistema debe permitir borrar los contactos
● El sistema debe permitir hacer búsquedas de los contactos
Pienso
que es un sistema de agenda de un call center un sistema que permite contactar clientes
O
es una empresa de telecomunicaciones.
Requisitos
funcionales;
● El sistema debe permitir registrar, modificar y actualizar
los usuarios
● El sistema debe permitir registrar, modificar y actualizar
el inventario de equipos.
● El sistema debe permitir control de tiempos de servicio y
costo.
● El sistema debe permitir control del alquiler de equipos y
mostrar los disponibles.
● El sistema debe permitir registrar, modificar y actualizar
las tarifas del préstamo de equipos.
● El sistema debe permitir registrar, modificar y actualizar
los pagos del préstamo de equipos.
Para mi es una sala de internet donde
se maneja el inventario, préstamo y pago de servicios de la sala.
