Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Unidad 2
ÍNDICE
Propósito....................................................................................................................................................3
Módulo elegido..........................................................................................................................................3
Organizador................................................................................................................................................6
Conclusión...............................................................................................................................................14
Referencias...............................................................................................................................................14
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)
Propósito
Diagramar casos de uso respecto a la funcionalidad del software a desarrollar, considerando a los
actores involucrados y sus interacciones con el sistema.
Módulo elegido
El módulo elegido es el de FABRICACIÓN.
Fabricación: permitirá seleccionar el diseño, y desglosará los artículos que componen el producto, así
como las cantidades que se requieren de cada uno.
“Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro en algún lugar
de su secuencia. La relación de inclusión sirve para enriquecer un caso de uso con otro y compartir
una funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un
caso de uso describiendo sus subfunciones. El caso de uso incluido existe únicamente con ese
propósito, ya que no responde a un objetivo de un actor. Estas relaciones se representan mediante
una flecha discontinua con el estereotipo <<include>> o <<uses>>” (SEAS, 2013)
“Extensión: Un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en
el lugar especificado indirectamente por este otro caso de uso. En el caso de uso base, la extensión
se hace en una serie de puntos concretos y previstos en el momento del diseño, llamados puntos de
extensión, los cuáles no son parte del flujo principal. La relación de extensión sirve para modelar: la
parte opcional del sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que
se pueden insertar en un punto determinado. Este tipo de relación produce confusión y no debería
utilizarse en exceso. Conviene su uso sólo para insertar un nuevo comportamiento no previsto en un
caso de uso existente. Estas relaciones se representan mediante una flecha discontinua con el
estereotipo <<extend>>.” (SEAS, 2013)
“Herencia: Especialización y generalización de los casos de uso: Un caso de uso (subcaso) hereda el
comportamiento y significado de otro, es decir las relaciones de comunicación, inclusión y extensión
del super-caso de uso. En muchas ocasiones este super-caso de uso es abstracto y corresponde a
un comportamiento parcial completado en el subcaso de uso. O dicho de otra manera, Los casos de
uso “hijo” son una especialización del caso de uso “padre”. En la medida de lo posible debería
evitarse puesto que produce cierta confusión en algunas ocasiones.” (SEAS, 2013)
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)
Organizador
Elementos
Casos de uso: Consulta diseño, Validar usuario, Desglosa requerimientos, Genera orden de
surtido, Baja de insumos, Registro en sistema, Imprime orden, Valida existencia
insumos, Autoriza fabricación, Reporta insuficiencia inventario
Descripción
El supervisor consulta un diseño, y al consultar diseño además de ver los diseños ve también los insumos
que lo componen. Posterior a esto, lo autoriza o no lo autoriza, en caso que lo autorice entonces el sistema
hace una validación de existencias, para ver si se puede cubrir el requerimiento de materiales de acuerdo a la
cantidad de piezas a producir así como a los insumos necesarios por unidad.
Para que el jefe de producción pueda generar una orden de surtido, tiene que estar primero autorizado el
trabajo de fabricación. Una vez autorizado, entonces el jefe de producción puede solicitar o generar una
orden de surtido, la cuál se imprime de forma automática y el almacenista hace el surtido de dicho material,
en las cantidades y especificaciones descritas en la orden de surtido.
Una vez surtido el material, el almacenista ingresa al sistema y da de baja de inventario las cantidades y
modelos de insumos que utilizó.
Todos estos movimientos tienen en común que conllevan varias validaciones; de usuarios cada vez que algún
usuario intenta interactuar con el sistema así como validación de existencia de mercancía previa a la
generación de la orden de surtido.
Si no se tiene suficiente existencia, el sistema reporta esto al supervisor y a otros usuarios definidos por el
administrador del sistema.
Ingeniería en Desarrollo de Software
Universidad Abierta y a Distancia de México (UNADM)
a 6 lunes a viernes.
Prioridad Alta
Observaciones No puede existir un diseño sin su desglose. El
departamento de Diseño debe cargar ambos. El
supervisor no tiene permisos de cargar desgloses
de insumos.
Conclusión
Sin duda esta ha sido una de las actividades más enriquecedoras, porque me han permitido viajar
desde un requerimiento platicado (audio de la actividad), hasta aterrizar dichos requerimientos dentro
de una estructura que me ha permitido disectar las distintas partes que componen el requerimiento y
poder pensar así en que tengan sentido, que estén correctamente conectadas y tengan razón de ser.
Muy interesante actividad, y si continuo desarrollando todos los módulos, veo que podría tener una
documentación de más de 200 hojas sin problema, por el grado de detalle que conlleva e implica
cada herramienta.
Referencias
1) UNADM (2019), Desarrollo de Software, Unidad 1 Ingeniería de Software, Universidad Abierta y a
Distancia de México (UNADM), Recuperado de
https://unadmexico.blackboard.com/bbcswebdav/institution/DCEIT/Bloque2/DS/03/DIIS/U1/Unidad_1_
Ingenieria_de_software.pdf
2) UNADM (2019), Desarrollo de Software, Unidad 2 Análisis y modelado de requerimientos,
Universidad Abierta y a Distancia de México (UNADM), Recuperado de
https://unadmexico.blackboard.com/bbcswebdav/institution/DCEIT/Bloque2/DS/03/DIIS/U2/Unidad_2_
Analisis_y_modelado_de_requerimientos.pdf
3) SEAS (2013), Tipos de relaciones en diagramas de casos de uso. UML., BlogSeas, recuperado de
https://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-de-uso-uml/