DIAGRAMA DE COMPORTAMIENTO: ACTIVIDAD Y DE ESTADOS

Fecha de clase: Lunes, 8 de diciembre del 2014

INTRODUCCIÓN

En esta clase aprendimos a usar cada uno de los diagramas de actividad de iteración, de estados, de secuencia, de comunicación y otros en este blog hablaremos de dos el diagrama de actividad y de estado, es bueno mencionar de que cada diagrama tiene su función y es necesario para cada uno de las soluciones de los problemas, es decir que cada diagrama es importante para cada ámbito en la solución de problemáticas. El diagrama de actividades visualiza desde el punto de vista fácil para la persona que soluciona el problema ya que, esta tiene detallada las actividades que se deben.

MARCO TEÓRICO

DIAGRAMA DE ACTIVIDAD

Los diagramas de actividad muestran la secuencia de actividades en un proceso, incluyendo las actividades secuenciales y paralelas, además de las decisiones que se toman. Por lo general se crea un diagrama de actividad para un caso de uso y puede mostrar los distintos escenarios posibles. (Kendall,K ; Kendall,J).

Un diagrama de actividades ilustra la naturaleza dinámica de un sistema mediante el modelado del flujo ocurrente de actividad en actividad. Una actividad representa una operación en alguna clase del sistema y que resulta en un cambio en el estado del sistema. Típicamente, los diagramas de actividad son utilizados para modelar el flujo de trabajo interno de una operación.

Estados de Acción: Los estados de acción representan las acciones no interrumpidas de los objetos.

Flujo de la Acción: Los flujos de acción, representados con flechas, ilustran las relaciones entre los estados de acción.

Estado Inicial: Estado inicial de un estado de acción.

Final State: Estado final de un estado de acción.

Ramificación

Un rombo representa una decisión con caminos alternativos. Las salidas alternativas deben estar etiquetadas con una condición.

Sincronización

Una barra de sincronización ayuda a ilustrar la ocurrencia de transiciones paralelas, así quedan representadas las acciones concurrentes. (Zapata, A).

DIAGRAMA DE ESTADO

Los diagramas de máquinas de estado son útiles para describir el comportamiento de clases y sistemas que han sido concebidos haciendo uso de un modelo de estados. En un modelo de estados se identifican las situaciones en la que el comportamiento o capacidad de respuesta con cualitativamente diferentes, así como los eventos o condiciones bajos las que se pasa de una situación a otra (transiciones de estados).

Los diagramas de estados son intensivamente utilizados en:

·         Systemas de tiempo real y críticos.

·         La descripción de sistemas reactivos.

·         La descripción de sistemas basados en protocolos. (Drake, J).

CONCLUSIÓN

Una persona usa cualquier clase de diagrama es la persona que está en la obligación de elegir el diagrama que esté a su conveniencia y así de esta manera, puede solucionar el problema de una manera gráfica. Estos diagramas son muy usados ya que tiene un parecido con el diagrama de flujo que es fácil de usar y comprender, además detalla todo el procedimiento que se debe seguir para la solución de cualquier problema.

BIBLIOGRAFÍA

Drake, J. 2007. Diagramas de actividad y Diagramas de estado. (En línea). Consultado 06 de feb 2015. Formato PDF. Disponible en: http://www.ctr.unican.es/asignaturas/procodis_3_II/Doc/stateDiagram.pdf

Kendall,K ; Kendall,J. 2011. Analisis y diseño de sistemas. Octava edición. Cap- 10. (Libro Digital.)

Zapata, A. 2006. Diseño de actividad. (En línea). Consultado 06 de feb 2015. Formato PDF. Disponible en: http://www.clubdelsuran.com.ar/site/materiales/proyecto/diagramas_del_uml.pdf

UML: DIAGRAMA DE COMPORTAMIENTO: CASOS DE USO

Fecha de clase: Lunes, 1 de diciembre del 2014

INTRODUCCIÓN

Esta clases se inició tratando con los distintos lenguajes de para hacer modelados, tratando sus principales características. Entre estos modelados en la clase tratamos sobre los casos de uso ya que este se visualiza desde el punto de vista del usuario este es la función principal; cabe recalcar que cada diagrama tiene su función y es necesario para cada una de las soluciones de los problemas.

.

MARCO TEÓRICO

UML

El Lenguaje de Modelado Unificado (UML) 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”. En otras palabras, tal como los arquitectos de edificios crean planos para que los use una compañía constructora, los arquitectos de software crean diagramas de UML para ayudar a los desarrolladores de software a construir el software. Si usted entiende el vocabulario del UML (los elementos pictóricos de los diagramas y su significado) puede comprender y especificar con mucha más facilidad un sistema, y explicar su diseño a otros.

Debe observar que existen muchas características opcionales en diagramas de UML. El UML ofrece dichas opciones (en ocasiones complejas) de modo que pueda expresar todos los aspectos importantes de un sistema. Al mismo tiempo, tiene la flexibilidad para suprimir aquellas partes del diagrama que no son relevantes para el aspecto que se va a modelar, con la finalidad de evitar confundir el diagrama con detalles irrelevantes. Por tanto, la omisión de una característica particular no significa que ésta se encuentre ausente; puede significar que la característica se suprimió. (Pressman, R).

Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas:

     • Diagrama de casos de uso.                        • Diagrama de estados.

     • Diagrama de clases.                                   • Diagrama de actividades.

     • Diagrama de objetos.                                 • Diagrama de componentes.

     • Diagrama de secuencia.                             • Diagrama de despliegue.

                                  • Diagrama de colaboración.

Un modelo UML está compuesto por tres clases de bloques de construcción:

      • Elementos: Los elementos son abstracciones de cosas reales o ficticias        (objetos, acciones, etc.)

      • Relaciones: relacionan los elementos entre sí.

      • Diagramas: Son colecciones de elementos con sus relaciones.  (Hernández, E).

DIAGRAMA DE CASOS DE USO

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar.

Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente.

ELEMENTOS BÁSICOS:

ACTORES: Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa  que interactúa con el sistema. No tiene por qué ser un ser humano, puede ser otro sistema informático o unidades organizativas o empresas. Siempre hay que intentar independizar los actores de la forma  en que se interactúa con el sistema. Por ejemplo un teclado  no es un actor en la mayor parte de los casos, sólo un medio para introducir información al sistema. Suele ser útil mantener una lista de los usuarios reales para cada actor.

Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando, no un individuo particular por lo tanto puede haber personas particulares que puedan estar usando el sistema de formas diferentes en diferentes ocasiones: socio de biblioteca y bibliotecario.

CASO DE USO: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando. Se representan mediante un óvulo. Cada caso de uso debe detallarse, habitualmente mediante una descripción textual.

ASOCIACIONES: Hay una asociación entre un actor y un caso de uso si el actor interactúa con el sistema para llevar a cabo el caso de uso.

TIPOS DE ASOCIACIONES:

Existen tres tipos de asociación o relaciones en los diagramas de casos de uso:

Include: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar comportamiento común en dos o más casos de uso.

 Extend: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relación implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. En principio esas variaciones pueden también mostrarse como diferentes descripciones de escenarios asociadas al mismo caso de uso.

Generalizaciones: En un diagrama de casos de uso también pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos están relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos últimos la semántica es muy similar a las relaciones “extend”. (Cáceres, J).

CONCLUSIÓN

Los lenguajes unificados de modelado nos sirven para las que las personas entiendan el sistema desde un modelado de manera rápida. Estos diagramas en general son importantes para todo ámbito y solución de problema, la persona que usa cualquier clase de diagrama es la persona que está en la obligación de elegir el diagrama que esté a su conveniencia y así de esta manera, puede solucionar el problema de una manera gráfica.

BIBLIOGRAFÍA

Cáceres, J. 2012. UNIVERSIDAD DE ALCALÁ. Casos de uso. (En línea). Consultado 06 de feb 2015.  Formato PDF. Disponible en: http://www2.uah.es/jcaceres/capsulas/DiagramaCasosDeUso.pdf.

Hernández, E. 2006. El Lenguaje Unificado de Modelado (UML). (En línea). Consultado 06 de feb 2015. Formato PDF. Disponible en: http://www.disca.upv.es/enheror/pdf/ActaUML.PDF

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

METODOLOGÍAS ÁGILES

Fecha de clase: Lunes, 17 de noviembre del 2014

INTRODUCCIÓN

Esta clases se inició con el narrador de la clase y los expositores luego la docente empezó a explicar sobre las metodologías ágiles que es la forma más óptima de acoplarse a nuevos requerimientos en la creación de proyecto lo principal de esta clase es dar a conocer los principales sistemas agiles en la construcción de software.

.

MARCO TEÓRICO

METODOLOGÍA ÁGIL

La historia de la ingeniería de software está salpicada de decenas de descripciones y metodologías de proceso, métodos de modelado y notaciones, herramientas y tecnología, todos ellos obsoletos. Cada uno tuvo notoriedad y luego fue eclipsado por algo nuevo y (supuestamente) mejor. Con la introducción de una amplia variedad de modelos ágiles del proceso —cada uno en lucha por la aceptación de la comunidad de desarrollo de software— el movimiento ágil está siguiendo la misma ruta histórica.

PRINCIPIOS DE AGILIDAD

1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua de software valioso.

2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada del desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja competitiva del cliente.

3. Entregar con frecuencia software que funcione, de dos semanas a un par de meses, de preferencia lo más pronto que se pueda.

4. Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y durante todo el proyecto.

5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.

6. El método más eficiente y eficaz para transmitir información a los integrantes de un equipo de desarrollo, y entre éstos, es la conversación cara a cara.

7. La medida principal de avance es el software que funciona.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante en forma indefinida.

9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.

10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.

11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con organización propia.

12. El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para después afinar y ajustar su comportamiento en consecuencia.

Un modelo de desarrollo ágil es un proceso incremental con pequeñas entregas de software ya que el software va evolucionando y necesita de nuevas características o nuevos requerimientos.

El más usado de todos los modelos ágiles de proceso es la programación extrema (XP). (Pressman, R.)

Pero se han propuesto muchos otros y están en uso en toda la industria. Entre ellos se encuentran los siguientes:

• SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

• Crystal Methodologies. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

• Dynamic Systems Development Method (DSDM). Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.

• Adaptive Software Development (ASD). Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

• Feature -Driven Development (FDD) .Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir elsoftware. Sus impulsores son Jeff De Luca y Peter Coad.

• Lean Development (LD) .Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios. (Canós, J)

CONCLUSIÓN

Las metodologías agiles son requeridas mucho en el desarrollo del proceso de software ya q estas metodologías permiten realizar pequeños incremento al equipo de desarrollo sin generar problemas ya que pasaría por lo mismo que todo el proceso de desarrollo es decir todas las actividades de desarrollo de software.

BIBLIOGRAFÍA

Canós, J. 2005. Metodología Ágil. Formato (PDF). En línea. Disponible en: http://noqualityinside.com/nqi/nqifiles/XP_Agil.pdf

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

PROCESO UNIFICADO

Fecha de clase: Lunes, 10 de noviembre del 2014

INTRODUCCIÓN

Esta clases se inició con el narrador de la clase y los expositores  con un tema muy interesante como es el proceso unificado; el Proceso Unificado no es simplemente un proceso, sino un marco de trabajo que puede ser adaptado a organizaciones o proyectos específicos para así llegar a cumplir el objetivo planteado.

El proceso Unificado reconoce la importancia de la comunicación con el cliente y los métodos  directos para describir su punto de vista respecto de un sistema.

MARCO TEÓRICO

PROCESO UNIFICADO

El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software. El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. (Stephen, R; Schach, D)

FASES DEL PROCESO UNIFICADO

La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como de planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.

La fase de elaboración incluye las actividades de comunicación y modelado del modelo general el proceso. La elaboración mejora y amplía los casos de uso preliminares desarrollados como parte de la fase de concepción y aumenta la representación de la arquitectura para incluir cinco puntos de vista distintos del software: los modelos del caso de uso, de requerimientos, del diseño, de la implementación y del despliegue.

La fase de construcción del PU es idéntica a la actividad de construcción definida para el proceso general del software. Con el uso del modelo de arquitectura como entrada, la fase de construcción desarrolla.

La fase de transición del PU incluye las últimas etapas de la actividad general de construcción y la primera parte de la actividad de despliegue general (entrega y retroalimentación). Se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como los cambios necesarios.

La fase de producción del PU coincide con la actividad de despliegue del proceso general. Durante esta fase, se vigila el uso que se da al software, se brinda apoyo para el ambiente de operación (infraestructura) y se reportan defectos y solicitudes de cambio para su evaluación. (Pressman, R.)

CARACTERÍSTICAS DEL PROCESO UNIFICADO:

- Soporta técnicas orientadas a objeto, por lo que se basa en los conceptos de clase y objeto y las relaciones entre ellos, usando UML como notación común.

- Es una metodología que sigue un proceso iterativo e incremental. Propone una descomposición incremental del problema a través de refinamientos sucesivos y una producción incremental de la solución, a través de la realización de varios ciclos. Esta filosofía es lógica cuando se aplica a sistemas grandes ya que “no se puede abarcar todo a la vez”.

- El PU está dirigido por el riesgo. Esta es una de las características fundamentales del este modelo, y propone identificar, afrontar y resolver los elementos de riesgo lo más pronto posible. En etapas iniciales se desarrollan las funcionalidades con mayor riesgo y las de mayor complejidad. De este modo se mejoran las posibilidades de éxito del proyecto.

- Se utilizan modelos gráficos de representación más que documentación, en particular se usan diagramas UML que son representaciones expresivas y pueden aplicarse durante todo el desarrollo.

- El PU está centrado en la arquitectura software. La arquitectura del software para el sistema en desarrollo se define al principio y guía su desarrollo. Propone la definición de una arquitectura robusta, lo que facilita el desarrollo del sistema en paralelo, aumentando las posibilidades de reutilización de componentes y el mantenimiento del sistema. El diseño arquitectónico aporta una base sólida sobre la que planificar y gestionar el desarrollo software basado en componentes. Al basarse en la definición de una arquitectura clara y sencilla, el PU sirve de marco común para toda una familia de procesos y que puede acomodarse a distintas situaciones. Para ello, el PU da las guías para configurar el proceso de modo que se adapte a cada situación.

- EL PU está dirigido por los casos de uso. Esto es así porque el PU pone gran énfasis en la construcción de sistemas basados en la comprensión de cómo se va a utilizar ese sistema. Así, los casos de uso y los escenarios se usan para guiar el flujo de procesos, desde la definición de los requisitos hasta las pruebas.

- El PU es un proceso adaptable a los distintos tipos de desarrollo y se puede configurar dependiendo de las necesidades de cada proyecto (desde los más sencillos a los más complejos).

- Control continuo de la calidad. El PU propone llevar un adecuado control de calidad y una adecuada gestión de riesgos. Ambos conceptos están incluidos en el propio proceso, formando parte de sus actividades. (Stephen, R; Schach, D)

CONCLUSIÓN

Un proceso es la parte que lleva al objetivo principal, es un conjunto de pasos ordenados  que al finalizarlos se alcanza un objetivo. 

En  ingeniería de software, el objetivo es construir un producto de software nuevo o  extender uno existente obteniendo las características deseadas. 

BIBLIOGRAFÍA

Stephen, R; Schach, D. 2005. Proceso unificado. Formato (PDF). En línea. Disponible en: http://es.slideshare.net/bebeyom/proceso-unificado

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición