lunes, 17 de noviembre de 2014

Tema 2. Lenguaje Unificado de Modelado UML: Diagramas de Comportamiento - Casos de uso, Actividad e Iteración



ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ MANUEL FÉLIX LÓPEZ


CARRERA INFORMÁTICA

SEMESTRE SEPTIMO                 PERIODO OCT./2014-MAR./2015

INGENIERIA DE SOFTWARE
TEMA 2:
LENGUAJE UNIFICADO DE MODELADO UML

AUTORA:
JENNIFER V. LÓPEZ ÁLAVA

FACILITADOR:
ING. HIRAIDA SANTANA

CALCETA, 17 NOVIEMBRE 2014



INTRODUCCIÓN
En este capítulo se dará a conocer acerca los diagramas de comportamiento que existen, en esta ocasión se conocerá acerca del diagrama de caso de uso, que es un actor, sus reglas y su descripción. Además, se conocerá el diagrama de comportamiento y como hacer varios hilos de los programas concurrentes, y por último el diagrama de iteración, los elementos que contiene y de que parte puede ser obtenido dicho diagrama.
DIAGRAMAS DE COMPORTAMIENTO
DIAGRAMA DE CASOS DE USO
Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están pensados para representar el diseño y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar las características necesarias que tendrá el sistema.
Caso De Uso
Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible.
Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes algunas sencillas reglas:
   Cada caso de uso está relacionado como mínimo con un actor
   Cada caso de uso es un iniciador (es decir, un actor)
   Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)
   Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre casos de uso son:
   <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso
   <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro.
   Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.
Actor
Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.
Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención telefónica a clientes y realiza pedidos para los clientes estaría representada por un actor «equipo de soporte» y por otro actor «representante de ventas».
Descripción De Casos De Uso
Las descripciones de casos de uso son reseñas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso.
DIAGRAMA DE ACTIVIDAD
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesamientos paralelos. Esto es importante cuando se usan diagramas de actividad para modelar procesos de negocios algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes.
              Los diagramas de actividad permiten describir como un sistema implementa su funcionalidad.
              Los diagramas de actividad modelan el comportamiento dinámico de un procedimiento, transacción o caso de uso haciendo énfasis en el proceso que se lleva a cabo.
              Los diagramas de actividad es uno de los elementos de modelado que son mejor comprendidos por todos, ya que son herederos directos de los diagramas de flujo.
              Los diagramas de actividad son más expresivo que los diagramas de flujo.
DIAGRAMA DE ITERACIÓN
El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre sí en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).
Los componentes de un diagrama de interacción son:
   Un Objeto o Actor.
   Mensaje de un objeto a otro objeto.
   Mensaje de un objeto a sí mismo.
Elementos
    Objeto/Actor:
El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.
    Mensaje A Otro Objeto:
Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.
    Mensaje Al Mismo Objeto:
No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

CIERRE

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso, un actor es una entidad externa que interacciona con el sistema, este tipo de diagramas son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Un diagrama de actividad puede mostrar procesamientos paralelos, sirven para modelar procesos de negocios algunos de los cuales pueden actuar en paralelo, son más expresivos, describen como un sistema implementa su funcionalidad, etc. El diagrama de interacción, representa la forma en como un Cliente u Objetos se comunican entre sí en petición a un evento, puede ser obtenido del diagrama estático de clases o el de casos de uso.

BIBLIOGRÁFIA

Cáceres, J. 2012. Casos de uso. Universidad De Alcalá: Disponible en: http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf.

Kendall, K. Kendall, J. Análisis y Diseño de Sistemas. 8va ed. Pearson Education. Prentice Hall, INC., Copyright © 2011.

Pressman, R. 2010. Ingeniería del Software Un Enfoque Práctico. 7ma ed. University of        Connecticut. McGraw-Hill Interamericana Editores, S.A.

lunes, 3 de noviembre de 2014

Tema 1. Metodologías de Desarrollo de Software: Metodologías Agiles




ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ MANUEL FÉLIX LÓPEZ





CARRERA INFORMÁTICA



SEMESTRE SEPTIMO           PERIODO OCT./2014-MAR./2015



INGENIERIA DE SOFTWARE

TEMA 1:

METODOLOGÍAS DE DESARROLLO DE SOFTWARE: Metodologías Agiles.



AUTORA:

JENNIFER V. LÓPEZ ÁLAVA



FACILITADOR:

ING. HIRAIDA SANTANA



CALCETA, 03 NOVIEMBRE 2014


INTRODUCCIÓN
En este capítulo estudiaremos las diferentes metodologías agiles tales como la programación extrema, cuáles son sus valores, su procesos y XP Industrial, además de las metodologías de desarrollo adaptativo de software, scrum, el método de desarrollo de sistemas dinámicos, cristal, el desarrollo impulsado por las características, el desarrollo esbelto de software, el modelado ágil y el proceso unificado ágil. 

METODOLOGÍAS AGILES.
PROGRAMACIÓN EXTREMA (XP)

La programación extrema (XP), el enfoque más utilizado del desarrollo de software ágil. IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado específicamente en organizaciones grandes.

Valores XP
Se define un conjunto de cinco valores que establecen el fundamento para todo trabajo realizado como parte de XP: comunicación, simplicidad, retroalimentación, valentía y respeto. Cada uno de estos valores se usa como un motor para actividades, acciones y tareas específicas de XP.

El proceso XP
La programación extrema usa un enfoque orientado a objetos como paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño, codificación y pruebas.

XP INDUSTRIAL

Está imbuida del espíritu minimalista, centrado en el cliente y orientado a las pruebas que tiene XP. IXP difiere sobre todo de la XP original en su mayor inclusión de la gerencia, el papel más amplio de los clientes y en sus prácticas técnicas actualizadas”. IXP incorpora seis prácticas nuevas diseñadas para ayudar a garantizar que un proyecto XP funciona con éxito para proyectos significativos dentro de una organización grande.

Evaluación de la factibilidad. Antes de iniciar un proyecto IXP, la organización debe efectuar una evaluación de la factibilidad.

Comunidad del proyecto. En IXP, los miembros de la comunidad y sus papeles deben definirse de modo explícito, así como establecer los mecanismos para la comunicación y coordinación entre los integrantes de la comunidad.

Calificación del proyecto. La calificación analiza el contexto del proyecto a fin de determinar cómo complementa, extiende o reemplaza sistemas o procesos existentes.

Administración orientada a pruebas. La administración orientada a pruebas establece una serie de “destinos” medibles y luego define los mecanismos para determinar si se han alcanzado o no éstos.

Retrospectivas. Después de entregar un incremento de software, el equipo XP realiza una revisión técnica especializada que se llama retrospectiva y que examina “los temas, eventos y lecciones aprendidas” a lo largo del incremento de software y/o de la liberación de todo el software.

Aprendizaje continuo. Como el aprendizaje es una parte vital del proceso de mejora continua, los miembros del equipo XP son invitados a aprender nuevos métodos y técnicas que conduzcan a una calidad más alta del producto.

DESARROLLO ADAPTATIVO DE SOFTWARE (DAS)

El desarrollo adaptativo de software (DAS) fue propuesto por Jim Highsmith como una técnica para elaborar software y sistemas complejos. Los fundamentos filosóficos del DAS se centran en la colaboración humana y en la organización propia del equipo.
Se define un “ciclo de vida” del DAS que incorpora tres fases: especulación, colaboración y aprendizaje.
Durante la especulación, se inicia el proyecto y se lleva a cabo la planeación adaptativa del ciclo. La especulación emplea la información de inicio del proyecto para definir el conjunto de ciclos de entrega (incrementos de software) que se requerirán para el proyecto.
La filosofía DAS tiene un mérito, sin importar el modelo de proceso que se use. El énfasis general que hace el DAS en la dinámica de los equipos con organización propia, la colaboración interpersonal y el aprendizaje individual y del equipo generan equipos para proyectos de software que tienen una probabilidad de éxito mucho mayor.

SCRUM

Scrum (nombre que proviene de cierta jugada que tiene lugar durante un partido de rugby) es un método de desarrollo ágil de software concebido por Jeff Sutherland y su equipo de desarrollo a principios de la década de 1990.
Los principios Scrum son congruentes con el manifiesto ágil y se utilizan para guiar actividades de desarrollo dentro de un proceso de análisis que incorpora las siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad estructural, las tareas del trabajo ocurren con un patrón del proceso llamado sprint. El trabajo realizado dentro de un sprint se adapta al problema en cuestión y se define —y con frecuencia se modifica— en tiempo real por parte del equipo Scrum.

Sprints: consiste en unidades de trabajo que se necesitan para alcanzar un requerimiento definido en el retraso que debe ajustarse en una caja de tiempo predefinida (lo común son 30 días). Durante el sprint no se introducen cambios. Así, el sprint permite a los miembros del equipo trabajar en un ambiente de corto plazo pero estable.

Reuniones Scrum: son reuniones breves (de 15 minutos, por lo general) que el equipo Scrum efectúa a diario.
Un líder del equipo, llamado maestro Scrum, dirige la junta y evalúa las respuestas de cada persona.
La junta Scrum ayuda al equipo a descubrir los problemas potenciales tan pronto como sea posible. Asimismo, estas juntas diarias llevan a la “socialización del conocimiento”, con lo que se promueve una estructura de equipo con organización propia.

Demostraciones preliminares: entregar el incremento de software al cliente de modo que la funcionalidad que se haya implementado pueda demostrarse al cliente y éste pueda evaluarla.

MÉTODO DE DESARROLLO DE SISTEMAS DINÁMICOS (MDSD)

El método de desarrollo de sistemas dinámicos (MDSD) es un enfoque de desarrollo ágil de software que proporciona una estructura para construir y dar mantenimiento a sistemas que cumplan restricciones apretadas de tiempo mediante la realización de prototipos incrementales en un ambiente controlado de proyectos.

Iteración del modelo funcional: produce un conjunto de prototipos incrementales que demuestran al cliente la funcionalidad. El objetivo de este ciclo iterativo es recabar requerimientos adicionales por medio de la obtención de retroalimentación de los usuarios cuando practican con el prototipo.

Diseño e iteración de la construcción: revisita los prototipos construidos durante la iteración del modelo funcional a fin de garantizar que en cada iteración se ha hecho ingeniería en forma que permita dar valor operativo del negocio a los usuarios finales; la iteración del modelo funcional y el diseño e iteración de la construcción ocurren de manera concurrente.

Implementación: coloca el incremento más reciente del software en el ambiente de operación.

CRISTAL

Alistar Cockburn creó la familia Cristal de métodos ágiles a fin de obtener un enfoque de desarrollo de software que premia la “maniobrabilidad”.
Para lograr la maniobrabilidad, se definieron un conjunto de metodologías, cada una con elementos fundamentales comunes a todos, y roles, patrones de proceso, producto del trabajo y prácticas que son únicas para cada uno. La familia Cristal en realidad es un conjunto de ejemplos de procesos ágiles que han demostrado ser efectivos para diferentes tipos de proyectos. El objetivo es permitir que equipos ágiles seleccionen al miembro de la familia Cristal más apropiado para su proyecto y ambiente.

DESARROLLO IMPULSADO POR LAS CARACTERÍSTICAS (DIC)

El DIC pone el énfasis en las actividades de aseguramiento de la calidad del software mediante el estímulo de la estrategia de desarrollo incremental, el uso de inspecciones del diseño y del código, la aplicación de auditorías de aseguramiento de la calidad del software, el conjunto de mediciones y el uso de patrones (para el análisis, diseño y construcción).
En el contexto del DIC, una característica “es una función valiosa para el cliente que puede implementarse en dos semanas o menos”.

DESARROLLO ESBELTO DE SOFTWARE (DES)

El desarrollo esbelto de software (DES) adapta los principios de la manufactura esbelta al mundo de la ingeniería de software. Los principios de esbeltez que inspiran al proceso DES se resumen como sigue: eliminar el desperdicio, generar calidad, crear conocimiento, aplazar el compromiso, entregar rápido, respetar a las personas y optimizar al todo.

MODELADO ÁGIL (MA)

El modelado ágil (MA) es una metodología basada en la práctica para modelar y documentar con eficacia los sistemas basados en software. En pocas palabras, es un conjunto de valores, principios y prácticas para hacer modelos de software aplicables de manera eficaz y ligera a un proyecto de desarrollo de software. Los modelos ágiles son más eficaces que los tradicionales porque son sólo buenos, sin pretender ser perfectos.
El modelado ágil adopta todos los valores del manifiesto ágil. La filosofía de modelado ágil afirma que un equipo ágil debe tener la valentía para tomar decisiones que impliquen rechazar un diseño y reconstruirlo. El equipo también debe tener la humildad de reconocer que los tecnólogos no tienen todas las respuestas y que los expertos en el negocio y otros participantes deben ser respetados e incluidos.

EL PROCESO UNIFICADO ÁGIL (PUA)

El proceso unificado ágil (PUA) adopta una filosofía “en serie para lo grande” e “iterativa para lo pequeño” a fin de construir sistemas basados en computadora. Al adoptar las actividades en fase clásicas del PU —concepción, elaboración, construcción y transición—, el PUA brinda un revestimiento en serie que permite que el equipo visualice el flujo general del proceso de un proyecto de software.
Sin embargo, dentro de cada actividad, el equipo repite con objeto de alcanzar la agilidad y entregar tan rápido como sea posible incrementos de software significativos a los usuarios finales. Cada iteración del PUA aborda las actividades siguientes:
·         Modelado.
·         Implementación.
·         Pruebas.
·         Despliegue.
·         Configuración y administración del proyecto.
·         Administración del ambiente.

 CIERRE

La programación extrema es el enfoque más utilizado del desarrollo de software ágil, contiene los valores de la comunicación, simplicidad, retroalimentación, valentía y respeto, además la programación extrema usa un enfoque orientado a objetos, y engloba un conjunto de reglas y prácticas de cuatro actividades estructurales que son planeación, diseño, codificación y pruebas. El IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado específicamente en organizaciones grandes. El desarrollo adaptativo de software es una técnica para elaborar software y sistemas complejos los fundamentos filosóficos del se centran en la colaboración humana y en la organización propia del equipo esta metodología incorpora tres fases: especulación, colaboración y aprendizaje. Scrum se utilizan para guiar actividades de desarrollo dentro de un proceso de análisis que incorpora las siguientes actividades estructurales: requerimientos, análisis, diseño, evolución y entrega. El método de desarrollo de sistemas dinámicos es un enfoque de desarrollo ágil de software que proporciona una estructura para construir y dar mantenimiento a sistemas que cumplan restricciones apretadas de tiempo mediante la realización de prototipos incrementales en un ambiente controlado de proyectos. Cristal en realidad es un conjunto de ejemplos de procesos ágiles que son efectivos para diferentes tipos de proyectos. El Desarrollo Impulsado por las Características pone el énfasis en las actividades de aseguramiento de la calidad del software mediante el estímulo de la estrategia de desarrollo incremental, el uso de inspecciones del diseño y del código, la aplicación de auditorías de aseguramiento de la calidad del software, el conjunto de mediciones y el uso de patrones. El desarrollo esbelto de software adapta los principios de la manufactura esbelta al mundo de la ingeniería de software estos principios se resumen en: eliminar el desperdicio, generar calidad, crear conocimiento, aplazar el compromiso, entregar rápido, respetar a las personas y optimizar al todo. El modelado ágil es una metodología basada en la práctica para modelar y documentar con eficacia los sistemas basados en software, es decir, es un conjunto de valores, principios y prácticas para hacer modelos de software aplicables de manera eficaz y ligera a un proyecto de desarrollo de software. El proceso unificado ágil adopta una filosofía “en serie para lo grande” e “iterativa para lo pequeño” a fin de construir sistemas basados en computadora, brinda un revestimiento en serie que permite que el equipo visualice el flujo general del proceso de un proyecto de software.

BIBLIOGRÁFIA
Pressman, R. 2010. Ingeniería del Software Un Enfoque Práctico. 7ma ed. University of Connecticut. McGraw-Hill Interamericana Editores, S.A.