F08-6060-002 GUIA DE APRENDIZAJE 5° (1321642 - 03-04-2017 ) UML

SERVICIO NACIONAL DE APRENDIZAJE SENA SISTEMA INTEGRADO DE GESTIÓN Procedimiento Ejecución de la Formación Profesional Integral GUÍA DE APRENDIZAJE

Versión: 02

Código: GFPI-F-019

1. IDE IDENTI NTIFIC FICAC ACII N DE LA GU A DE AP APREN RENDIZA DIZAJE JE

Programa de Formación:

Técnico en Desarrollo de Software Nombre del Proyecto:

Aplicativo para Gestión Empresas Colombianas Colombianas

Código: Versión: 102

de la Información En Código: 228120

Fase del proyecto:

Análisis Actividad (es) del Proyecto: Proyecto:

Realizar los diagramas UML necesarios necesarios para gestionar la información información del sistema de una empresa en un contexto real. Resultados de Aprendizaje: Construir el mapa de navegación de acuerdo con el diseño entregado para orientar al usuario en el uso del aplicativo.

Competencia: Desarrollar El sistema que cumpla con los requerimientos de la solución informática

Resultados de Aprendizaje:

Competencia:

Gestionar la información de acuerdo con los procedimientos establecidos y con las tecnologías de la información y la comunicación disponibles.

Promover la interacción idónea consigo mismo, con los demás y con la naturaleza en los contextos laboral y social

Asumir actitudes actitudes críticas, argumentati argumentativas vas y propositivas propositivas en función de la resolución de problemas de carácter productivo y social. Duración de la guía ( en horas): 8 Horas

Elaborada por Víctor Rincón


Versión: 02

Código: GFPI-F-019

2. PRESENTACIÓN

INTRODUCCIÓN: En 1986, Ivar 1986, Ivar Jacobson, importante Jacobson, importante contribuyente al desarrollo de los modelos de UML de UML y proceso unificado, creó 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 de Alistair Cockburn en el libro Escribir libro Escribir casos de uso efectivos publicado en el año 2000. Durante los años los años 1990 los casos de uso se convirtieron en una de las prácticas más comunes para la captura de requisitos funcionales, especialmente funcionales, especialmente con el desarrollo del paradigma de la programación la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación. 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 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 una notación gráfica para representar casos de uso llamada modelo de casos de Elaborada por Víctor Rincón


Versión: 02

Código: GFPI-F-019

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 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 mas de un caso de uso para poder identificar que 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 uso 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



Versión: 02

Código: GFPI-F-019

lo que supuestamente va a hacer el sistema, pero no indican cómo lo va a hacer.

3. ESTRUCTURA DIDÁCTICA DE LAS ACTIVIDADESDE APRENDIZAJE

3.1 Actividades de Reflexión inicial. ¿Para que sirven ,cuando se emplean como se emplean, en que 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 (mas 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.



Versión: 02

Código: GFPI-F-019

3.2 Actividades de contextualización e identificación de conocimientos necesarios para el aprendizaje. Estimado aprendiz antes de que inicie la solución de las actividades propuestas en esta guía 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





Versión: 02

Código: GFPI-F-019

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.















Versión: 02

Código: GFPI-F-019

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 (Especificacion 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.




Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019


Versión: 02

Código: GFPI-F-019

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.



Versión: 02

Código: GFPI-F-019

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



Versión: 02

Código: GFPI-F-019

3.3 Actividades de apropiación. . 1. Como se llama la entidad que inicia el caso de uso?

La entidad que inica 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 donomina 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 l o 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 casp 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 serian los actores? ¿Cuáles serian algunos de los escenarios dentro de cada caso de uso? a. Actores: Los actores que se identifican en una tienda que vende equipos de computo, hardware, software y perifericos son: El vendedor, el administrador y el cliente. Vendedor: El vendedor podrá hacer las siguientes tareas:

* Atraer compradores de productos. * Ofrecer productos existentes * Exponer caracteristicas tecnicas 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 garantias. Cliente:

* Ver productos ofrecidos * Comparar productos * Comprar producto* Pagar por compra * Recibir producto * Recibir Factura.



Versión: 02

Código: GFPI-F-019

b. ¿Cuáles seruan algunos de los escenarios dentro de cada caso de uso? * Sistema de venta de productos de Hardware y Software * Sistema de admninistracion de ventas * Sistema de compras para almacen de Hardware y Software * Sistema de garantías de Hardware y software. 5. Cree un caso de uso relacionado con cualquier situacion de la vida real. Sistema para generar formulas medicas de pacientes: Ingresar al sistema Ingresar datos personales del paciente Generar formula medica: Nombre del medicamento, cantidad y dosis Verificar conflictos entre medicamentos e historia clinica Generar formula médica por medio de correo electronico o impreso

Actividades:

Profundice junto a su instructor ya sea por mediación tecnológica o presencial, cuales son los criterios para no permitir el envío de valores no válidos al servidor desde el lado del cliente mediante lenguaje de programación JavaScript. Profundice junto a su instructor ya sea por mediación tecnológica o presencial, cuales son los criterios para no permitir el envío de valores no válidos al servidor desde el lado del servidor.



Versión: 02

Código: GFPI-F-019

Investigue cómo se hace referencia desde Javascript, a los campos y datos hospedados en un formulario construido en HTML. Investigue cómo se realiza en Javascript toda gestión administrativa de datos provenientes de formularios HTML, mediante el uso de funciones. Construya un formulario en HTML, que me permita guardar datos de pacientes como Tipo de identificación, Número de identificación, Nombres, Apellidos, Edad, Dirección, Teléfono y Estrato. Y a través de Javascript, permita que se guarden valores válidos en el servidor.

3.4 Actividades de 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 la información que se encuentra relacionada a continuación:




Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019



Versión: 02

Código: GFPI-F-019


Versión: 02

Código: GFPI-F-019

3.1 Actividades de evaluación. En el restaurante “MAMAMIA” se realizan los siguientes procesos para atender a los clientes: Cuando el cliente ingresa la anfitriona les da la bienvenida y recibe las prendas y los objetos de los clientes. Los clientes son atendidos por meseros los cuales le van ha 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 predileccion. El mesero recoge la carta con el menú seleccionado y se dirige hacia la cocina, en donde entregara la lista con el menú seleccionado. La Cocina servirá el menú seleccionado. El mesero le hará llegar el menu preparado a los clientes que le solicitaron. Los clientes después de disfrutar el menu 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 anfitriona. Realizar el analisis de casos de uso para los siguientes casos: Sistema Registro Usuario Sistema Modificar Usuario Sistema Consultar Uusario Sistema Registro de Adminstrador Sistema Validacion Usuario Elaborar el diagrama de Clase de el Enunciado 1 (la cadena de videoclubs) Elaborar los diagramas de Clase del Sistema Propuesto en grupo, para el Proyecto que esta desarrollando en la formacion. Responder las siguientes cuestionamientos: 1. ¿En un objeto cómo o con qué elemento se representa su estado? 2. ¿Qué es el estado pasivo de un objeto? 3. ¿Cuándo se presenta el estado activo de un objeto y qué valores puede adoptar? 4. ¿Qué es un suceso, en qué ocasiones se presenta y cómo afecta un suceso al sistema? 5. ¿A qué se llama transición del objeto? 6. ¿Cuál es el símbolo que se utiliza para representar el Estado Inicial de un Objeto? 7. ¿Cuál es el símbolo que se utiliza para representar el Estado Final de un Objeto? 8. ¿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 Elaborada por Víctor Rincón


Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama

Versión: 02

Código: GFPI-F-019

de colaboración de componentes de comunicación de despliegue de estructura compuesta de flujo de objetos de paquetes de secuencia de tiempos global de interacciones

4. RECURSOS PARA EL APRENDIZAJE

Ambiente de formación, 200 Computador, Sistemas operativos (Windows) Software ideasModuler, Conexión a Internet.

5. GLOSARIO DE T RMINOS Artefacto: u n 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 Elaborada por Víctor Rincón


Versión: 02

Código: GFPI-F-019

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.

6. BIBLIOGRAF A / WEBGRAF A

Diseño y Analisis de Sistemas con UML – Randall Agenor Herrera Briones Ingenieria de Software Enfoque Practico-Roger Pressman Aprendiendo-UML-en-24-horas http://es.wikipedia.org/wiki/Caso_de_uso http://es.wikipedia.org/wiki/Categor%C3%ADa:UML

7. CONTROL DEL DOCUMENTO Elaborado por: Ing. Victor Rincon Marzo de 2015


F08-6060-002 GUIA DE APRENDIZAJE 5° (1321642 - 03-04-2017 ) UML

Recommend Documents