Taller 4 UML

GESTIÓN DE FORMACIÓN PROFESIONAL INTEGRAL
PROCEDIMIENTO DESARROLLO CURRICULAR

TALLER DE APRENDIZAJE
1. IDENTIFICACIÓN DEL TALLER
 Denominación del Programa de Formación: Técnico en Desarrollo de Software

 Código del Programa de Formación: 228120 Versión 102
 Nombre del Proyecto: Diseño y Construcción de Software para Administración de Unidades
Productivas
 Código: 990527
 Fase del Proyecto: Análisis
 Actividad de Proyecto: Diagnosticar las necesidades de Sistematizar procesos administrativos en la
empresa.
 Resultados de Aprendizaje Alcanzar: 22050103203 Interpretar los diagramas de caso de uso, de
objetos, de estados, de secuencia, de paquetes o componentes, de despliegue, de colaboración
según el diseño entregado.
 Competencia: Analizar los requerimientos del cliente para construir el sistema de información.
2. OBJETIVOS.
2.1 GENERAL
Lograr que el aprendiz comprenda diferentes situaciones que presente la sociedad para buscar una
solución a través de los diferentes diagramas de UML y al mismo tiempo que el aprendiz pueda
explicar e interpretar estos diagramas usando diversas plataformas como Ideas Modeler, ArgoUml,
UmlDraw, StarUml o RationalRose para su ejecución.
2.2 ESPECIFICOS.
 Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de
aspectos del modelado contemporáneo de una forma directa y económica.
 Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar
en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el
cómputo distribuido, etc.
 Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el
meta-modelo a un coste bajo.
 Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras
podrían desarrollarse encima del UML.
 Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la
comparación y el almacenamiento de componentes del modelo.
GFPI-F-019 V3
SERVICIO NACIONAL DE APRENDIZAJE SENA
Procedimiento de Desarrollo Curricular
 UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
 Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
Imponer un estándar mundial.
 Ser independiente del proceso de desarrollo y de los lenguajes de programación.
3. INTRODUCCION.
El UML fue creado por Grady Boch, James Rumbaugh e Iva Jacobson, el UML es una notación que se ha
vuelto estándar en el mundo del desarrollo de sistemas, está constituido por un conjunto de diagramas
que permiten al analista de sistemas generar un anteproyecto de varias facetas que sean comprensibles
para los clientes. Uno de esos diagramas es el diagrama de clases, el cual trabajaremos en este taller para
repasar y poner en práctica lo que hemos aprendido.
En 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado,
creó el concepto de caso de uso.1 Se han realizado muchas mejoras al concepto que se estableció entonces,
pero probablemente la más influyente y significativa, en términos de definición del término caso de uso, fue
la de Alistair Cockburn en el libro Escribir casos de uso efectivos publicado en el año 2000.
En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un
nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que
indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo
específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su
lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a
los analistas para el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema
y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas
de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su
interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación
entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del
modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso
se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se
producen en su ámbito o en él mismo.
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de

comportamiento UML mejorado. El Lenguaje de Modelado Unificado(UML), define una notación
gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para
que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica
Autor: Ing Victor Rincón - Centro de Materiales y Ensayos, Regional Distrito Capital
define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general
simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo
confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son
mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un
caso de uso para poder identificar qué es lo que hace un caso de uso.
 La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o
un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a
entidades externas tales como usuarios humanos u otros sistemas.
 La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de
organización, un conjunto de casos de usos coherentes y consistentes promueven una imagen fácil
de comprender del comportamiento del sistema, un entendimiento común entre el
cliente/propietario/usuario y el equipo de desarrollo.
En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que
caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen
restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de
estándares.
El UML (Lenguaje Unificado de Modelado), es una herramienta que permite a los creadores de sistemas
generar diseños que capturen sus ideas, para comunicarlas de forma unificada y fácil a otras personas.
El UML organiza el proceso de diseño de forma que todas las personas involucradas en el desarrollo del
sistema lo comprendan y convengan con él.
El UML es una notación de diseño que los analistas, desarrolladores, y clientes aceptan como pauta de
trabajo. Esa notación es como unos planos de un edificio que usa un constructor.
La notación UML está compuesta por diversos gráficos o diagramas que se usan para hacer análisis de
sistemas. Estos diagramas al final presentarán modelos que describen lo que supuestamente va a hacer
el sistema, pero no indican cómo lo va a hacer.
Estimad@ Aprendiz mucho Ánimo: En el modelo de formación por proyectos Usted es el principal actor
de su formación profesional.
3.1 REFLEXIÓN INICIAL.
¿Para qué sirven, cuando se emplean como se emplean, en qué casos debemos tener en cuenta los casos
de uso?
¿Los casos de uso, sus especificaciones y el diagrama de casos de uso de un sistema permiten acordar, entre
el equipo de desarrollo y el cliente, los límites y los requisitos funcionales de dicho sistema?
¿El diagrama de casos de uso de un sistema puede organizarse por medio de relaciones que se pueden dar
entre los diferentes casos de uso?
¿Los actores de un sistema representan, en particular, personas (más precisamente roles que interpretan
personas), dispositivos u otros sistemas, y en general, cualquier cosa que interactúa con dicho sistema?
En el diagrama de casos de uso se pueden observar un buen número de relaciones include entre casos de
uso, pero no extend. Las relaciones include aparecen pronto para mostrar aspectos comunes entre partes
del sistema. La relación extend tiende a aparecer más tarde, cuando encuentras nuevos requisitos que
extienden al sistema actual. Dado que todavía no hemos desarrollado el primer sistema no tenemos nada
que extender.
3.2 CONTEXTUALIZACIÓN E IDENTIFICACIÓN DE CONOCIMIENTOS.
Estimado aprendiz antes de iniciar el desarrollo de las actividades propuestas en este taller es importante
determinar:
¿Qué es UML?
¿Qué es un caso de uso?
¿Cuáles son los elementos que constituyen un caso de uso?
¿Cuáles son los criterios que se deben tener en cuenta para la elaboración de un caso de uso y el diagrama
de caso de uso?
¿Cómo se relacionan los casos de uso?
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto
del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en colaboración por
los analistas de requerimientos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una
perspectiva tradicional de la ingeniería de software, un caso de uso describe una característica del
sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario
especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado de la
formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel del
detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de
los sistemas. Un caso de uso contiene una descripción textual de todas las maneras que los actores previstos
podrían trabajar con el software o el sistema. Los casos de uso no describen ninguna funcionalidad interna
(oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el
actor sigue para realizar una tarea.
Un caso de uso debe:
*describir una tarea del negocio que sirva a una meta de negocio
*tener un nivel apropiado del detalle
*ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento
Situaciones que pueden darse:
*Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el
actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
*Un caso de uso extiende otro caso de uso.
*Un caso de uso utiliza otro caso de uso.
Ventajas
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor
(su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del
usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija
la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (Elicitation en inglés), 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 requerimiento.
Limitaciones
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 requerimientos 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.
Buenas prácticas y recomendaciones de uso
Los casos de uso, como el resto de los requisitos, deben tener una redacción cuidada para evitar
problemas de interpretación. En general, algunas recomendaciones a tener en cuenta son:
El caso de uso debe describir qué debe hacer el sistema a desarrollar en su interacción con los actores y no
cómo debe hacerlo. Es decir, debe describir sólo comportamiento observable externamente, sin entrar en
la funcionalidad interna del sistema.
El nombre del caso de uso debe ilustrar el objetivo que pretende alcanzar el actor al realizarlo.
El caso de uso debe describir interacciones con los actores sin hacer referencias explícitas a elementos
concretos de la interfaz de usuario del sistema a desarrollar.
La invocación de unos casos de uso desde otros casos de uso (lo que se conoce como inclusión, o
extensión si es condicional, en UML), sólo debe usarse como un mecanismo para evitar repetir una
determinada secuencia de pasos que se repite en varios casos de uso. Nunca debe usarse para expresar
posibles menús de la interfaz de usuario.
Se debe ser cuidadoso al usar estructuras condicionales en la descripción del caso de uso, ya que los
clientes y usuarios no suelen estar familiarizados con este tipo de estructuras, especialmente si son
complejas.
Se debe intentar que todos los casos de uso de una misma ERS (Especificación de Requisitos del Sistema)
estén descritos al mismo nivel de detalle.
En los diagramas de casos de uso, debe evitarse que se crucen las líneas que unen los actores a los casos
de uso.
Ejemplos
3.3 Actividades de apropiación.
1. Como se llama la entidad que inicia el caso de uso?

La entidad que inicia el caso de uso se llama Actor(es), el actor es un rol que un usuario juega con respecto
al sistema.
2. Qué se entiende con "Incluir" un caso de uso?
Se denomina Include en los casos de uso y aparecen como funcionalidad común, luego de haber
especificado varios casos de uso, éste caso de uso es usado siempre que el caso que lo usa es ejecutado.
Esto marca la diferencia con las extensiones, que son opcionales.
3. Qué se entiende con “Extender" un caso de uso?
Representa una parte de la funcionalidad del caso que no siempre ocurre y son un caso de uso en sí
mismas. Se denomina Extends.
4. Los casos de uso pueden ayudarle a analizar un negocio y un sistema.
Imagine a una gran tienda de equipos de cómputo que vende Hardware, periféricos y software.
¿Quiénes serían los actores?

Actores: Los actores que se identifican en una tienda que vende equipos de cómputo, hardware, software
y periféricos son:
El vendedor, el administrador y el cliente.
Vendedor: El vendedor podrá hacer las siguientes tareas:

* Atraer compradores de productos.
* Ofrecer productos existentes
* Exponer características técnicas de los productos.
* Ingresar al sistema.
* Generar factura de compra
* Recibir dinero de compra
* Devolver vueltas por compra.
Administrador:
* Ingresar al sistema
* Generar reportes de ventas
* Generar reporte de productos faltantes.
* Realizar inventario mensual
* Administrar dinero de ventas y compras.
* Administrar dinero para pagos de empleados.
* Administrar garantías.
Cliente:
* Ver productos ofrecidos
* Comparar productos
* Comprar producto
* Pagar por compra
* Recibir producto
* Recibir Factura.
¿Cuáles serían algunos de los escenarios dentro de cada caso de uso?
* Sistema de venta de productos de Hardware y Software
* Sistema de administración de ventas
* Sistema de compras para almacén de Hardware y Software
* Sistema de garantías de Hardware y software.
5. Cree un caso de uso relacionado con cualquier situación de la vida real.
Sistema para generar formulas médicas de pacientes:
Medico: El medico podrá hacer las siguientes tareas:

*Ingresar al sistema
*Ingresar datos personales del paciente

*Generar formula médica: Nombre del medicamento, cantidad y dosis
*Verificar conflictos entre medicamentos e historia clínica
*Generar formula médica por medio de correo electrónico o impreso
3.4 TRANSFERENCIA DEL CONOCIMIENTO.
1. Realizar individualmente una lectura al siguiente material bibliográfico: UML gota a gota de
Fowler, Martin editorial Pearson. UML Desarrollo OO Xavier Ferré Grau, Isabel Sánchez y el libro
UML en 24 horas. Este material lo encontraran en la plataforma Blackboard en el material de
apoyo referente al tema.
2. Leer y analizar la información que se encuentra relacionada a continuación:
3.5 Actividades de Evaluación.
En el restaurante “MAMAMIA” se realizan los siguientes procesos para atender a los clientes:
Cuando el cliente ingresa la propietaria le da la bienvenida y recibe las prendas y los objetos de los clientes.
Los clientes son atendidos por meseros los cuales le van a indicar una mesa disponible. El mesero entregara
a los clientes la carta con el menú del día.
Los clientes deben seleccionar el menú de su predilección.
El mesero recoge la carta con el menú seleccionado y se dirige hacia la cocina, en donde entregará la lista
con el menú seleccionado.
La cocinera servirá el menú seleccionado.
El mesero le hará llegar el menú preparado a los clientes que le solicitaron.

Los clientes después de disfrutar el menú elegido llamaran al mesero para solicitarle la cuenta.
Finalmente los clientes se retiran del restaurante “mamamia“recogiendo sus prendas y objetos que serán
entregados por la propietaria.
Proponer los diagramas de uso, clases y secuencia del anterior ejercicio.
Realizar el análisis de casos de uso para los siguientes casos:
Sistema Registro Usuario

Sistema Modificar Usuario
Sistema Consultar Usuario
Sistema Registro de Administrador
Sistema Validación Usuario
Elaborar el diagrama de clase del Enunciado 1 (la cadena de videoclubs)
Elaborar los diagramas de Clase del Sistema Propuesto en grupo, para el Proyecto que está desarrollando
en formación.
Responder los siguientes cuestionamientos:
¿En un objeto cómo o con qué elemento se representa su estado?

¿Qué es el estado pasivo de un objeto?
¿Cuándo se presenta el estado activo de un objeto y qué valores puede adoptar?
¿Qué es un suceso, en qué ocasiones se presenta y cómo afecta un suceso al sistema?
¿A qué se llama transición del objeto?
¿Cuál es el símbolo que se utiliza para representar el Estado Inicial de un Objeto?
¿Cuál es el símbolo que se utiliza para representar el Estado Final de un Objeto?
¿Con qué símbolo se representa el estado transaccional de un objeto y en qué situaciones se presenta
dicho estado?
Realizar una consulta detallada acerca de los siguientes diagramas y luego implementar los que considere
pertinentes a su proyecto dependiendo la necesidad
Diagrama de colaboración
Diagrama de componentes
Diagrama de comunicación
Diagrama de despliegue
Diagrama de estructura compuesta
Diagrama de flujo
Diagrama de objetos
Diagrama de paquetes
Diagrama de secuencia
Diagrama de tiempos
Diagrama global de interacciones
Glosario de términos
Artefacto: un artefacto es un producto del proceso de desarrollo de software, que puede

incluir los modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseño, etc.),
archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos,
manuales de usuario y más.
Diagrama de actividades: tipos de datos que pasan por un nodo de objeto.
Tipos de terminales de entrada (Input Pin) y de salida (Output Pin) de nodos de parámetros
de actividad.
Diagrama de secuencia: tipos de parámetros y valores devueltos de mensajes.
Tipos de líneas de vida. La clase de una línea de vida debe incluir las operaciones de todos
los mensajes que puede recibir.
Diagrama de componentes: interfaces de componentes, con un listado de sus operaciones.
Diagrama de casos de uso: tipos mencionados en las descripciones de los objetivos y los
pasos de un caso de uso.
Acá les dejo unas de las frases más utilizados por los programadores:
20. “Pues es raro…”
19. “Nunca había pasado antes.”
18. “Pues ayer funcionaba…”
17. “¿Cómo es posible?”
16. “Tiene que ser un problema de tu hardware.”
15. “¿Qué hiciste mal para lograr que fallara?”
14. “Algo debe de estar mal en tus datos.”
13. “¡Si no he tocado ese módulo en meses!”
12. “Debes de estar usando una versión anterior.”
11. “Es sólo una desafortunada coincidencia.”
10. “¡Es que no lo puedo probar todo!”
9. “ESTO, no puede ser la causa de ESO.”
8. “Funciona, pero no lo he probado.”
7. “¡Alguien debe de haber cambiado mi código!”
6. “¿Has comprobado que no haya algún virus en tu sistema?”
5. “Ya se que no funciona, ¿pero te gusta?”
4. “No puedes utilizar esa versión en tu sistema”
3. “¿Por qué quieres hacer eso?”
2. “¿Y tú dónde estabas cuando se colgó el programa?”
Y la respuesta número uno de los programadores con programas que no funcionan es:
1. “¡EN MI MÁQUINA SI FUNCIONA!”

Taller 4 UML

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Taller 4 UML

Transféré par

Droits d'auteur :

Formats disponibles

GESTIÓN DE FORMACIÓN PROFESIONAL INTEGRAL

PROCEDIMIENTO DESARROLLO CURRICULAR

1. IDENTIFICACIÓN DEL TALLER

 Denominación del Programa de Formación: Técnico en Desarrollo de Software

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de

3.1 REFLEXIÓN INICIAL.

3.2 CONTEXTUALIZACIÓN E IDENTIFICACIÓN DE CONOCIMIENTOS.

Un caso de uso debe:

Buenas prácticas y recomendaciones de uso

3.3 Actividades de apropiación.

1. Como se llama la entidad que inicia el caso de uso?

¿Quiénes serían los actores?

Vendedor: El vendedor podrá hacer las siguientes tareas:

5. Cree un caso de uso relacionado con cualquier situación de la vida real.

Sistema para generar formulas médicas de pacientes:

Medico: El medico podrá hacer las siguientes tareas:

*Ingresar datos personales del paciente

3.4 TRANSFERENCIA DEL CONOCIMIENTO.

3.5 Actividades de Evaluación.

El mesero le hará llegar el menú preparado a los clientes que le solicitaron.

Proponer los diagramas de uso, clases y secuencia del anterior ejercicio.

Realizar el análisis de casos de uso para los siguientes casos:

Sistema Registro Usuario

Elaborar el diagrama de clase del Enunciado 1 (la cadena de videoclubs)

Responder los siguientes cuestionamientos:

¿En un objeto cómo o con qué elemento se representa su estado?

Artefacto: un artefacto es un producto del proceso de desarrollo de software, que puede

1. “¡EN MI MÁQUINA SI FUNCIONA!”

Vous aimerez peut-être aussi