Universidad Nacional Experimental de la Gran Caracas

La Floresta – PNF en informática

Ingeniería del Software
30121 – Nocturno
Gabriela Fabiana Marcano Requena V- 26901734

UML- Casos de Uso de

Negocios
Grady Booch, Jim Rumbaugh e Ivar Jacobson desarrollaron el UML
a mediados de los años noventa del siglo pasado con mucha
realimentación de la comunidad de desarrollo de software. El UML
fusionó algunas notaciones de modelado que competían entre sí y que
se usaban en la industria del software en la época. En 1997, UML 1.0 se
envió al Object Management Group, un consorcio sin fines de lucro
involucrado en especificaciones de mantenimiento para su empleo en la
industria de la computación. El UML 1.0 se revisó y dio como resultado la
adopción del UML 1.1 ese mismo año. El estándar actual es UML 2.0 y
ahora es un estándar ISO.
UML 2.0 proporciona 13 diferentes diagramas para su uso en modelado
de software. En este apéndice se analizarán solamente diagramas de
clase, implementación, caso de uso, secuencia, comunicación, actividad
y estado, diagramas que se usan en esta edición de Ingeniería del
software. Un enfoque práctico.
UML (Lenguaje Unificado de Modelos); es “un lenguaje estándar para
escribir diseños de software. El UML puede usarse para visualizar,
especificar, construir y documentar los artefactos de un sistema de
software intensivo”.
Diagramas de casos de uso; representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, además de la forma, tipo y
orden en como los elementos interactuan (operaciones o casos de uso).
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.
  En 1994 Rumbaugh y Booch crean El Método Unificado
 En 1995 se incorpora Jacobson y los tres autores publican un
documento titulado Unified MethodV0.8
 El método unificado se reorienta hacia la definición de un lenguaje
universal para el modelado de objetos, transformándose en UML
(Unified Modeling Language for Object-Oriented Development)
 En 1996 se crea un consorcio de colaboradores para trabajar en la
versión 1.0 de UML
 En 1997 se produce la estandarización de UML 1.0 por la OMG
 La siguiente versión oficial de UML es la versión 1.1
 En julio de 1998 aparece una revisión interna de UML que recoge
diversos cambios editoriales, pero no técnicos. Esta versión es la
que se conoce como UML 1.2.
 Casi un año más tarde, en junio de 1999 aparece OMG UML 1.3
con algunos cambios significativos, especialmente en lo tocante a
la semántica
 En septiembre de 2001 aparece UML 1.4 y en enero de 2005 OMG
UML 1.4.2 es aceptado como un estándar ISO (ISO/IEC 19501).
 En julio de 2005 se libera UML 2.0 siendo la última versión 2.5.
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que
expresa la intención que tiene el actor al hacer uso del sistema. Como
técnica de extracción de requisito permite que el analista se centre en
las necesidades del usuario, evitando que se dirija la funcionalidad del
nuevo sistema basándose solamente en criterios tecnológicos. A su vez,
durante la extracción, el analista se concentra en las tareas centrales
del usuario describiendo por lo tanto los casos de uso que mayor valor
aportan al negocio. Esto facilita luego la priorización del requisito.
Por otro lado, los casos de uso pueden ser útiles para establecer
requisitos de comportamiento, pero no establecen completamente los
requisitos funcionales ni permiten determinar los requisitos no
funcionales. Los casos de uso deben complementarse con información
adicional como reglas de negocio, requisitos no funcionales, diccionario
de datos que complementen los requisitos del sistema. Sin embargo, la
ingeniería del funcionamiento especifica que cada caso crítico del uso
debe tener un requisito no funcional centrado en el funcionamiento
asociado.
Los casos de uso se emplean en muchos contextos y entornos diferentes
y para muchos tipos distintos de equipos. Por ejemplo, los casos de uso
pueden beneficiar tanto a equipos pequeños de desarrollo ágil que
producen aplicaciones de uso intensivo como a grandes proyectos que
producen sistemas complejos de sistemas interconectados, tales como
sistemas corporativos, líneas de productos y sistemas en la nube

Conclusión:
Si bien, los casos de uso dejan claro lo que hará un sistema y, por
omisión, lo que no hará. Estos posibilitan una visión efectiva, el manejo
del alcance y el desarrollo incremental de sistemas de cualquier tipo y
cualquier tamaño. La estrategia de los casos de uso tiene un alcance
mucho más amplio que solo la captura de requisitos. Se pueden y se
deberían emplear para conducir el desarrollo, lo que significa que los
Casos de Uso apoyan el análisis, diseño, planeación, estimación,
seguimiento y prueba de sistemas. No establecen como se debería
planear o manejar el trabajo de desarrollo o como se debería diseñar,
desarrollar o probar el sistema. Sin embargo, proporcionan una
estructura para la adopción exitosa de sus prácticas seleccionadas de
administración y desarrollo.
Referencias:
- Ingeniería de Software I - Fundamentos de la vista de casos de uso.
(2018), [Documento en línea] Recuperado de:
https://repositorio.grial.eu/bitstream/grial/1155/1/UML%20-%20Casos
%20de%20uso.pdf
-diagrama de casos de uso del negocio y del sistema. (2013),
[Documento en línea] Recuperado de:
https://es.slideshare.net/123jou/actividad2-diagrama-de-casos-de-uso-
del-negocio-y-del-sistema
-Caso de Uso. (2010), [Pag web] Recuperado de:
https://es.wikipedia.org/wiki/Caso_de_uso
-El Lenguaje de Modelado Unificado. (2008), [Pag web] Recuperado de:
https://www.docirs.cl/uml.htm#casos
-Ingeniería del Software un enfoque práctico, (2010). [Libro en línea]
Recuperado de:
http://artemisa.unicauca.edu.co/~cardila/Libro_Pressman_7.pdf