Asignatura Datos del estudiante Fecha

Apellidos: jaraba coneo

Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Actividad
Protocolo individual de la unidad n°: 1

Metodologías tradicionales

Las metodologías tradicionales, como su nombre nos indica, son las que se han
usado toda la vida. Buscan imponer disciplina al proceso de desarrollo de software
y de esa forma volverlo predecible y por ello eficiente.

De hecho, estas metodologías tienen un enfoque predictivo, donde se sigue un

proceso secuencial en una sola dirección y sin marcha atrás. La
estimación/captura de requisitos se realiza una única vez (exacto, una vez solo) al
principio del proyecto y es precisamente por eso que nuestra estimación tendrá
mucha importancia ya que de ella dependen todos los recursos que emplearemos
en el proyecto. Si queremos adoptar una metodología tradicional, el desarrollo de
un proyecto debe empezar siempre con un riguroso proceso de captura de
requisitos, análisis y diseño. Recuerda: los requisitos son acordados de una vez y,
para todo el proyecto, no se esperan cambios en ellos.

Un consejo: adopta este tipo de metodología cuando ya tienes mucha experiencia

con un determinado tipo de producto y sabes estimarlo perfectamente. Además,
es la opción ideal para proyectos donde los requisitos no cambian y las
condiciones del entorno son conocidas y estables.

¿Y qué pasa si tienes que desarrollar un proyecto/producto nuevo? ¿Estás 100%

seguro de que todo saldrá exactamente según la estimación y lo previsto?

Un consejo: en este caso, considera aplicar una metodología ágil.

Las metodologías ágiles surgen como alternativa a las tradicionales porque nos
ayudan a reducir la probabilidad de fracaso por sub-estimación de costos, tiempos
y funcionalidades en entornos cambiantes.

Metodologías ágiles

Los marcos de trabajo (frameworks) y metodologías ágiles se caracterizan por ser

adaptativas y flexibles, esto significa que no son reticentes a los cambios, al revés,
los imprevistos son eventos esperados que aprenderás a acoger con gran
normalidad. Hoy en día, el marco de trabajo ágil más utilizado y conocido es
Scrum pero recuerda que existen también Kanban, Lean y otros.
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Muy en resumen, podríamos decir que las características principales de la

Metodología XP

La Metmetodologías ágil son: comunicación, cohesión, funcionalidad y

conocimientos.

las llamadas metodologías Ágiles de desarrollo de software más exitosas. Es

habitual odología XP “Extreme Programming” o “Programación Extrema” es una
de relacionarla con scrum, y la combinación de ambas asegura un mayor control
sobre el proyecto, y una implementación más efectiva y eficiente.

La Metodología XP: El Modelo

La metodología XP define cuatro variables para cualquier proyecto de software:

costo, tiempo, calidad y alcance. El método especifica que de estas cuatro
variables, tres de ellas podrán ser fijadas arbitrariamente por actores externos al
grupo de desarrolladores (clientes y jefes de proyecto), y el valor de la restante
deberá será establecida por el equipo de desarrollo, quien establecerá su valor en
función de las otras tres.

Por ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el

precio, el grupo de desarrollo tendrá libertad para determinar el tiempo que durará
el proyecto. Se trata de establecer un equilibrio entre las cuatro variables del
proyecto.

La Metodología Xp: El Ciclo de vida

Al igual que otras metodologías de gestión de proyectos, tanto Ágiles como

tradicionales, el ciclo XP incluye:

Entender lo que el cliente necesita > Fase de Exploración

Estimar el esfuerzo > Fase de Planificación

Crear la solución > Fase de Iteraciones

Entregar el producto final al cliente > Fase de puesta en producción

Lo que caracteriza a XP, al igual que al resto de métodos Agiles es un ciclo de

vida dinámico. ¿Cómo lo logra XP?metodología xp Ciclo XP Mediante ciclos de
desarrollo cortos (llamados iteraciones), al fin de los cuales se generan unos
entregables funcionales.
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y

pruebas, pero utilizando un conjunto de reglas y prácticas especificas de XP. Un
proyecto con XP, implica de entre a 10 a 15 iteraciones habitualmente.

Prácticas XP

No voy a entrar en el detalle de cada una de las reglas y prácticas, pues hay
mucha información al respecto en la red. A continuación, te propongo una manera
de agruparlas, en función del ámbito en el que aplican:
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Metodología MSF

En la empresa consultora donde trabajo, una de las verticales principales del

negocio es el desarrollo de software, donde tengo la oportunidad de utilizar
Microsoft Solution Framework (MSF) como una herramienta, donde la misma nos
ofrece orientación sobre cómo organizarnos como equipo, planificar los proyectos,
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

construir e implementar con exito las soluciones que desarrollamos a nuestros

clientes.

Cabe destacar que no puede haber un solo proceso de desarrollo de software

para todos los proyectos que ejecutemos. En eso consiste la filosofía principal que
esconde Microsoft Solutions Framework. MSF es una metodología flexible e
interrelacionada con una serie de conceptos, modelos y prácticas de uso, que
controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF
se centra en los modelos de proceso y de equipo dejando en un segundo plano las
elecciones tecnológicas.

MSF nos brinda las siguientes características:

 Es Adaptable: es parecido a un compás, usado en cualquier parte como un

mapa, del cual su uso es limitado a un específico lugar.

 Es Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas,

así como también, proyectos que requieren 50 personas a más.

 Es Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

 Es Tecnología Agnóstica: porque puede ser usada para desarrollar

soluciones basadas sobre cualquier tecnología.

soft Solution Framework

En la empresa consultora donde trabajo, una de las verticales principales del

negocio es el desarrollo de software, donde tengo la oportunidad de utilizar
Microsoft Solution Framework (MSF) como una herramienta, donde la misma nos
ofrece orientación sobre cómo organizarnos como equipo, planificar los proyectos,
construir e implementar con exito las soluciones que desarrollamos a nuestros
clientes.

Cabe destacar que no puede haber un solo proceso de desarrollo de software

para todos los proyectos que ejecutemos. En eso consiste la filosofía principal que
esconde Microsoft Solutions Framework. MSF es una metodología flexible e
interrelacionada con una serie de conceptos, modelos y prácticas de uso, que
controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF
se centra en los modelos de proceso y de equipo dejando en un segundo plano las
elecciones tecnológicas.
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

MSF nos brinda las siguientes características:

Es Adaptable: es parecido a un compás, usado en cualquier parte como un mapa,

del cual su uso es limitado a un específico lugar.

Es Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así

como también, proyectos que requieren 50 personas a más.

Es Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

Es Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones

basadas sobre cualquier tecnología.

MSF se compone de varios modelos y disciplinas encargados de planificar las

diferentes partes implicadas en el desarrollo de un proyecto: Véase Figura

Modelos y Disciplinas con MSF

 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Modelo de Equipo: Es un modelo que ha sido diseñado para mejorar el

rendimiento del equipo de desarrollo. Proporciona una estructura flexible para
organizar los equipos de un proyecto, asignando roles y responsabilidades a cada
miembro del equipo con el objetivo de satisfacer los objetivos del proyecto. Puede
ser escalado dependiendo del tamaño del proyecto y del equipo de personas
disponibles. En publicaciones posteriores se explicara con detalle la propuesta de
Modelo de Equipo planteado por MSF.

Modelo de Proceso: Diseñado para mejorar el control del proyecto, minimizando el

riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una
estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las
fases, las actividades, la liberación de versiones y explicando su relación con el
Modelo de equipo.

Disciplina Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las
prioridades, tomar las decisiones estratégicas correctas y controlar las
emergencias que puedan surgir. Este modelo proporciona un entorno estructurado
para la toma de decisiones y acciones valorando los riesgos que puedan provocar

Disciplina Administración de Proyectos o Gerencia de Proyectos Es una disciplina

que describe el rol de la gestión del proyecto que se basa en:

Planificar sobre entregas cortas

Incorporar nuevas Caracteristicas sucesivamente

Identificar cambios ajustando el cronograma

MSF incluye modelos propios asociados a Proyectos de Desarrollo de Software

los cuales se mencionan a continuación:

Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del

ciclo de vida. Este modelo define las pautas para construir proyectos
empresariales a través del lanzamiento de versiones.

Modelo de Diseño de Proceso : Diseñado para distinguir entre los objetivos

empresariales y las necesidades del usuario. Proporciona un modelo centrado en
el usuario para obtener un diseño eficiente y flexible a través de un enfoque
iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas
diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el

soporte, proporciona un modelo de tres niveles para diseñar y desarrollar
aplicaciones software. Los servicios utilizados en este modelo son escalables, y
pueden ser usados en un solo ordenador o incluso en varios servidores.

metodología RUP

La metodología de desarrollo RUP por sus siglas en inglés ó Proceso de

Desarrollo Unificado es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología estándar más
utilizada para el análisis, implementación y documentación de sistemas orientados
a objetos.

¿Cuándo debo utilizar RUP? Puede utilizar RUP desde el principio de un nuevo
proyecto de software, y puede seguir utilizándolo en los ciclos de desarrollo
subsiguientes tiempo después de que el proyecto inicial haya terminado. No
obstante, la forma de utilizar RUP varía para ajustarse a sus necesidades.

En el ciclo de vida RUP veremos una implementación del desarrollo en espiral.

Con el ciclo de vida se establecen tareas en fases e iteraciones. El RUP maneja el
proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,
la eliminación de los riesgos críticos, y al establecimiento de una base de inicio.

metodología Scrum

La metodología Scrum es un proceso para llevar a cabo un conjunto de tareas de

forma regular con el objetivo principal de trabajar de manera colaborativa, es decir,
para fomentar el trabajo en equipo.

Con este método de trabajo lo que se pretende es alcanzar el mejor resultado de

un proyecto determinado. Las prácticas que se aplican con la metodología Scrum
se retroalimentan unas con otras y la integración de las mismas tiene su origen en
un estudio de cómo hay que coordinar a los equipos para ser potencialmente
competitivos.

En Scrum se van realizando entregas regulares y parciales del trabajo final, de

manera prioritaria y en función del beneficio que aportan dichas entregas a los
receptores del proyecto. Por este motivo, es una metodología especialmente
indicada para proyectos complejos, con requisitos cambiantes y en los que la
innovación y la flexibilidad son protagonistas.
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

¿Cuándo aplicar la metodología Scrum?

Este método se aplica en proyectos donde la obtención de resultados a corto

plazo es necesaria y en aquellos en los que existen situaciones de incertidumbre y
tareas poco definidas.

Nos permite solucionar e identificar ineficiencias de forma sistemática o cuando un

cliente demanda un proceso altamente especializado para el desarrollo de un
producto determinado

La competitividad, la innovación, la productividad y la flexibilidad son totalmente

fundamentales para el éxito del proyecto.

Por otro lado, con este método también se resuelven aquellas partes de un
proyecto que no se le está entregando a tiempo a un determinado cliente, cuando
dichas tareas se dilatan demasiado en el tiempo o la calidad es baja.

Además, nos ayuda a reaccionar frente a los competidores directos, cuando la

moral de los equipos de trabajo se ve disminuida o la rotación de la plantilla es
alta.

El método Scrum nos permite identificar y solucionar ineficiencias de forma

sistemática o cuando un cliente demanda un proceso altamente especializado
para el desarrollo de un producto determinado.

¿Quiénes forman el equipo de trabajo para la metodología Scrum?

Existen diferentes perfiles que forman parte del equipo de trabajo para desarrollar
la metodología Scrum:

Product Owner

La misión principal de este perfil es conseguir dejar clara la priorización de los

objetivos de un proyecto determinado y maximizar el trabajo que desarrolla el
equipo en su conjunto. Este perfil puede ser externo o interno a la organización.

Scrum Master

La misión principal del Scrum Master es sacar un alto rendimiento al equipo de

trabajo. Tiene que conseguir que este sienta los valores y principios de este
método, así como la práctica y la teoría para que se utilicen en todos los procesos.
Además, es el facilitador de reuniones y elimina aquellos obstáculos que impiden
ser ágil al equipo.
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Scrum Team

Cuando hablamos de un equipo específico de desarrollo nos referimos a los

integrantes más técnicos que conjuntamente desarrollan el proyecto. El Scrum
Team tiene un objetivo común.

Skateholders

Podemos entender por Stakeholders como aquellas personas, organizaciones o

empresas que pueden tener una relación directa o indirecta con un proyecto
determinado.

Qué es el lenguaje unificado de modelado (UML)

Una imagen vale más que mil palabras. Es por eso que se creó la generación de
diagramas con el Lenguaje Unificado de Modelado (UML): para forjar un lenguaje
visual común en el complejo mundo del desarrollo de software que también fuera
comprensible por los usuarios de negocios y quienquiera que desee entender un
sistema. Aprende lo básico de los diagramas UML, además de sus orígenes, usos,
conceptos, tipos y pautas sobre cómo dibujarlos usando nuestra herramienta de
diagramas UML.

¿Qué es UML?

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de

modelado visual común y semántica y sintácticamente rico para la arquitectura, el
diseño y la implementación de sistemas de software complejos, tanto en estructura
como en comportamiento. UML tiene aplicaciones más allá del desarrollo de
software, p. ej., en el flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en diferentes tipos

de diagramas. En general, los diagramas UML describen los límites, la estructura y
el comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se

pueden usar para generar código en diversos lenguajes usando los diagramas
UML. UML guarda una relación directa con el análisis y el diseño orientados a
objetos.

UML y su función en el modelado y diseño orientados a objetos

Hay muchos paradigmas o modelos para la resolución de problemas en la

informática, que es el estudio de algoritmos y datos. Hay cuatro categorías de
modelos para la resolución de problemas: lenguajes imperativos, funcionales,
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

declarativos y orientados a objetos (OOP). En los lenguajes orientados a objetos,

los algoritmos se expresan definiendo 'objetos' y haciendo que los objetos
interactúen entre sí. Esos objetos son cosas que deben ser manipuladas y existen
en el mundo real. Pueden ser edificios, artefactos sobre un escritorio o seres
humanos.

Los lenguajes orientados a objetos dominan el mundo de la programación porque

modelan los objetos del mundo real. UML es una combinación de varias
notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado
de objetos e ingeniería de software orientada a objetos.

UML usa las fortalezas de estos tres enfoques para presentar una metodología
más uniforme que sea más sencilla de usar. UML representa buenas prácticas
para la construcción y documentación de diferentes aspectos del modelado de
sistemas de software y de negocios.

La historia y los orígenes de UML

"The Three Amigos" (los tres amigos) de la ingeniería de software, como se los
conocía, habían desarrollado otras metodologías. Se asociaron para brindar
claridad a los programadores creando nuevos estándares. La colaboración entre
Grady, Booch y Rumbaugh fortaleció los tres métodos y mejoró el producto final.

Los esfuerzos de estos pensadores derivaron en la publicación de los documentos

UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones,
incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su
propio desarrollo de negocios. Ellos, junto con muchas otras personas y
compañías, establecieron los recursos necesarios para desarrollar un lenguaje de
modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para
el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye
información sobre UML 2.0 en la segunda edición de 2005.

Diagrama de objetos: el diagrama de objetos tiene una estructura similar a la del

diagrama de clases. Cuando el nombre aparece en el diagrama de clase (ver
Persona arriba), el diagrama de objeto especifica el nombre de la instancia junto
con el nombre del clasificador/categoría. De acuerdo con el pliego de condiciones,
se subraya lo siguiente (por ejemplo: Helga: Persona)

Diagrama de componentes: un componente es un módulo que está aislado del

sistema externo e interactúa con otros componentes mediante interfaces definidas.
Es un subformulario de la clase. Por lo tanto, las características estructurales,
como las operaciones y los atributos, definen el componente con mayor precisión.
El componente contiene varios componentes. Estos pueden ser de nuevo
componentes, pero también clases, subsistemas o partes. Hay dos opciones de
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

visualización diferentes para el modelado: Black Box o caja negra (el contenido
está oculto) y White Box o caja blanca (el contenido es visible).

Diagrama de casos de uso: el diagrama de casos de uso muestra el

comportamiento que se esperará de un sistema más adelante. Este modelo no
solo es adecuado para sistemas de software, sino también, por ejemplo, para
procesos esperados en las relaciones comerciales. El caso de uso involucra a un
actor (humano o sistema) con un objetivo. El diagrama normalmente tiene como
nombre el objetivo. Los diferentes casos de uso dentro del sistema cumplen el
objetivo del actor.

El diagrama del caso de uso representa a UML con un rectángulo con la etiqueta
use case. El remitente es el actor (esto se representa como una figura de palo,
como en el caso anterior, incluso si se trata de un sistema). El actor está
conectado por una relación de dependencia (representada como un guion) con el
caso de uso (elipse con etiqueta) dentro de un sistema (rectángulo con etiqueta
<<sistema>> y nombre del sistema)
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Diagramas de secuencia: como diagrama de interacción, el diagrama de

secuencia representa el intercambio de mensajes entre objetos. El tipo de
diagrama UML modela estos objetos como las llamadas líneas de vida. En este
sentido, es similar a otros diagramas de comportamiento como el diagrama de
actividad. Sin embargo, a diferencia de estos, el diagrama de secuencia no se
utiliza para obtener una visión general del comportamiento de un sistema, sino
para presentar un posible comportamiento entre muchos otros en detalle.
Prescribe una cronología. Una línea discontinua representa el curso del tiempo.

UML 2.0 muestra mensajes síncronos (UML: flecha con la punta llena) y mensajes
asíncronos (UML: flecha con la punta abierta). Los mensajes síncronos son
aquellos que bloquean un canal hasta que reciben una respuesta del objeto de
destino. Determinan las características de comportamiento en forma de
operaciones sincrónicas. Los mensajes asincrónicos controlan el objeto fuente de
llamada. Éstas incluyen tanto las operaciones asíncronas como las señales
(paquetes de datos enviados entre acciones).
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

Diagrama de actividades: las actividades consisten en una red de acciones que se

relacionan entre sí mediante flujos de datos y de control. Mientras que el Diagrama
de casos de uso muestra los requisitos del sistema, el Diagrama de actividades
muestra cómo funcionan estos casos de uso. En este tipo de diagrama, por
ejemplo, el token juega un papel importante: en los procesos paralelos, es un
marcador para el cual se priorizan los procesos y, por lo tanto, se reciben los
recursos (por ejemplo, la memoria de trabajo).

Diagrama de máquina de estados: una máquina de estados, también llamada

autómata finito, representa un conjunto finito de estados en un sistema. Si se
cumple una condición definida en el sistema (se detona un desencadenante), se
produce una situación correspondiente. Esto puede incluir actividades o
interacciones. Bajo UML 2.0, un estado representa esta situación. Los estados se
consideran como nodos (inglés: vértices) y se muestran como rectángulos con
esquinas redondeadas. Además, el diagrama de máquina de estados modela las
transiciones de un estado (nodo fuente) a otro (nodo destino). Los modelos UML
presentan las transiciones de estado como bordes. Las acciones son la última
piedra angular. Se asignan especificaciones de comportamiento al estado.

El comportamiento está ligado a ciertas situaciones o eventos. El diagrama de

máquina de estados UML tiene 4 especificaciones:

Comportamiento de entrada (entry behavior)

Comportamiento en el estado (doActivity)

Comportamiento que ocurre en caso de un evento (event behavior)

Comportamiento de salida (exit behavior)

Además, un estado puede ser interrumpido y continuado en el mismo punto. Esta

propiedad se llama estado de la historia.

Diagrama de componentes

Los diagramas de componentes UML representan las relaciones entre los

componentes individuales del sistema mediante una vista de diseño estática.
Pueden ilustrar aspectos de modelado lógico y físico.

En el contexto del UML, los componentes son partes modulares de un sistema

independientes entre sí, que pueden reemplazarse con componentes
equivalentes. Son autocontenidos y encapsulan estructuras de cualquier grado de
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

complejidad.Los elementos encapsulados solo se comunican con los otros a

través de interfaces. Los componentes no solo pueden proporcionar sus propias
interfaces, sino que también pueden utilizar las interfaces de otros componentes,
por ejemplo, para acceder a sus funciones y servicios. A su vez, las interfaces de
un diagrama de componentes documentan las relaciones y dependencias en una
arquitectura de software

Diagrama de distribución

Una herramienta de análisis que dibuja pares relacionados de variables para

presentar un patrón de relación o de correlación. Cada conjunto de datos
representa un factor diferente que puede ser cuantificado. Un conjunto de datos es
dibujado en un eje horizontal (eje x) y el otro conjunto de datos se dibuja en el eje
vertical (eje y). El resultado es un número de puntos que pueden ser analizados
para determinar si existe una relación significativa (también conocida como
“correlación”) entre los dos conjuntos de datos.

Diagrama de actividades

Los diagramas de actividades UML pertenecen al grupo de diagramas de

comportamiento en UML. Mientras que un diagrama de estructura registra el
estado de un sistema, es decir, los objetos existentes y sus jerarquías, así como
las conexiones entre ellos en un momento determinado, los diagramas de
comportamiento describen el flujo cronológico de la circulación de datos. Además
del diagrama de actividades, el diagrama de caso de uso y el diagrama de
máquina de estados también pertenecen a este grupo. Los diagramas de
actividades son similares en su uso y notación a los diagramas de flujo
(especialmente a los diagramas de programas), pero se adaptan a la
programación orientada a objetos.

Básicamente se puede decir que el diagrama de actividades modela el flujo de

actividades. Estos pueden ser procesos dentro de un sistema informático,
procesos de casos de uso o procesos comerciales. Por ejemplo, la actividad
“preparar una tortilla de queso” puede descomponerse en muchas actividades
secundarias más pequeñas: las acciones, que pueden llevarse a
cabocronológicamente. Una acción, por ejemplo, sería “cascar los huevos” y
vendría seguida de la acción “batir los huevos con especias”. La segunda acción
está supeditada a la primera. Están en un estado de evolución, por así decirlo.

También pueden representarse procesos paralelos. Por ejemplo, en el caso de

que sean dos personas las que preparan la tortilla, es posible que las acciones de
“cascar los huevos” y “picar las especias” sean simultáneas. Por lo tanto, la
actividad tiene dos puntos de partida, desde los que las personas comienzan su
actividad, moviéndose de una acción a otra. En el diagrama de actividades, los
 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

dos actores de la acción (las dos personas) desempeñan un papel importante,

pero no reciben notación propia. Se mueven de un punto de partida a un punto
final, atravesando los flujos de prueba u objetos para pasar de una acción a la
siguiente. En el camino hay obstáculos ocasionales, los llamados pines, que solo
dejan pasar bajo ciertas condiciones, por ejemplo, cuando ambas personas están
presentes.

En el diagrama de actividades, estas “personas” se denominan tokens. Hay dos

tipos de token en el diagrama de actividades UML: el primero es el objeto token,
que transmite información a los nodos de acción, inicia allí una acción y (si se
especifica) almacena el resultado como un valor. Si el resultado y el token
corresponden a las especificaciones definidas en un pin, este pin de salida envía
el objeto token mediante un flujo de objetos a la siguiente acción. Antes de que el
token pueda iniciar esta acción, debe cumplir con las especificaciones del pin de
entrada. Los tokens de control, por otra parte, solo migran a través de flujos de
control y sirven como marcadores. Inician una acción, pero no transmiten ningún
dato.

Diagrama de casos de uso

Un diagrama de casos de uso UML comprende conjuntos de datos que describen

las múltiples formas en que los usuarios pueden elegir interactuar con las nuevas
soluciones de software. Este tipo de diagrama sólo puede utilizarse con un
conjunto de plantillas específicas, como los conectores de diagrama. Como son
elementos cruciales a la hora de construir un diagrama de casos de uso, ya se han
incorporado a nuestra plantilla. Descúbrelos en Stencils, en la sección de Casos
de Uso.

- Actores. El actor se describe con un nombre y una breve descripción. El nombre

debe ser un sustantivo singular que represente el rol que el actor juega en el
sistema. Ejemplo, Estudiante:

Cualquier estudiante activo de la universidad que tiene la posibilidad de inscribirse

a los cursos ofrecidos para el semestre actual. Adicionalmente deberá tenerse en
cuenta como guía de calidad para la definición de actores que:

• Cada actor debe participar por lo menos en un caso de uso.

 Asignatura Datos del estudiante Fecha
Apellidos: jaraba coneo
Análisis y diseño de
23/11/2021
software
Nombre: jose daniel

• Evitar la definición excesiva de actores. Los actores que jueguen roles similares
pueden unirse en uno solo.

• Usar nombres intuitivos. Todos los interesados en un proyecto deben poder

entender los nombres de los actores.

Precondición. En este campo se expresan en lenguaje natural las condiciones

necesarias para que se pueda realizar el caso de uso. Estas condiciones se
establecen bien sobre el entorno en el que opera el sistema, y que por lo tanto
quedarán fuera de su control o bien sobre el estado del propio sistema. El CU sólo
puede ser comenzado por el actor cuando las precondiciones sean ciertas y como
no son evaluadas en el flujo básico (FB) ni en los flujos alternos (FA), se asumen
como ciertas.

Postcondición. En este campo, se expresan en lenguaje natural las condiciones

que se deben cumplir después de la terminación normal del caso de uso. Al igual
que en el caso de las precondiciones, las postcondiciones se pueden establecer
tanto sobre el entorno del sistema como sobre el estado del propio sistema.

Las postcondiciones son importantes puesto que guían acerca de las condiciones
que garantizan que siempre que termine el CU el sistema queda en un estado
válido y los datos inherentes (en caso de existir) se encuentran consistentes. Las
postcondiciones son igualmente útiles para verificar que las pruebas que se
realicen sobre el CU aseguren que estas condiciones se cumplan.

Inclusión: Un caso de uso puede incorporar el comportamiento de otros casos de

uso como fragmentos de su propio comportamiento

• Extensión: Un caso de uso también se puede definir como una extensión

incremental de un caso de uso base