Ingeniería en Desarrollo de software

Semestre 4

Unidad 1. Herramientas para el modelado de software

Actividades de aprendizaje

Clave:
Licenciatura TSU
15142420 / 16142420

Universidad Abierta y a Distancia de México

Actividad 2. Fases del proceso RUP

Propósito: Distinguir actividades que se realizan en un proyecto real siguiendo la

metodología RUP para la elaboración y finalización de un proyecto.

Instrucciones:
1. De la lista de actividades resumida de un proyecto real y que se enlistan de manera
desordenada, identifica cuál de las 4 fases del modelo RUP es la adecuada para
comenzar su ejecución. Para eso coloca la letra que identifica a la fase en el lado
derecho (columna fase) de la actividad que le corresponde.
2. Copia las tablas en un archivo de texto.
3. Coloca tus respuestas en la columna de la derecha y redacta brevemente el porqué
de tus respuestas.
4. Guarda la actividad con el nombre DMMS_U1_A2_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y la Z
por la inicial de tu segundo apellido.
5. Envía el archivo a tu Docente en línea para recibir retroalimentación mediante la
herramienta Tarea.

FASES DEL PROCESO RUP

LETR NOMBRE DE FASE
A
I INICIO
E ELABORACION
C CONSTRUCCION
T TRANSICION/CIERRE

LISTA DE ACTIVIDADES EN DESORDEN

Orden ACTIVIDAD FASE
1 Clarificar los requisitos pendientes. E
2 Desarrollar la especificación de los casos de uso, E
3 Definir visión general de la arquitectura. E
4 Realizar las mejoras del proyecto. T
5 Ajustar los errores y defectos encontrados en las pruebas de
aceptación. C
6 Capacitar a los usuarios. T
7 Desarrollar la arquitectura base del sistema. E
8 Verificar que el producto cumple con las especificaciones involucradas
en el proyecto. C
9 Diseñar la solución preliminar. I
 10 Completar la funcionalidad de la iteración. C
11 Definir casos de uso de la arquitectura base del sistema. E
12 Administrar los cambios de las evaluaciones realizadas por los usuarios. C
13 Identificar riesgos. E
14 Asegurar la disponibilidad del software para los usuarios. T
15 Definir el plan de las fases e iteraciones siguientes de desarrollo. E
16 Definir el alcance del proyecto. I
17 Proveer soporte técnico. T
18 Definir la viabilidad del proyecto. I

1.-

2.-

3.-

4.-

5.-

6.-

7.-

8.-

9.-

10.-

11.-

12.-

13.-

14.-

15.-

16.-

17.-

18.-
Carrera: Desarrollo de software Semestre 04
Programa de la asignatura: Métodos y modelos de desarrollo de software
Unidad 1. Herramientas para el modelado de software
Autorreflexiones.
Repasemos: En un breve párrafo menciona todas las ideas, conceptos o
características que conozcas sobre UML, RUP y modelado de procesos.
1. ¿Qué es UML y para qué es utilizado?
El lenguaje unificado de modelado (UML), es un lenguaje de modelado visual que
se usa para especificar, visualizar, construir y documentar artefactos de un
sistema de software. Captura de decisiones y conocimiento sobre los sistemas que
se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener y
controlar la información sobre tales sistemas, se usa con todos los métodos de
desarrollo, etapas del ciclo de vida, dominios de aplicación y medios.

2. ¿Cuáles son los componentes de UML? Descríbelos brevemente.

FORMA ELEMENTO DESCRIPCIÓN
1 componente Un fragmento reutilizable de
funcionalidad del sistema. Un
componente proporciona y consume
el comportamiento a través de
interfaces y puede usar otros
componentes.
Puede ocultar o mostrar los
elementos internos de un
componente mediante el control
expandir y contraer.
- Is Indirectly Instantiated.
Si es valor true
(predeterminado), el
componente solo existe
como artefacto de diseño.
En tiempo de ejecución.
2 Puerto de la interfaz Representa un grupo de mensajes o
proporcionada. llamadas que implementa el
componente y que pueden usar
otros componentes o sistemas
externos. Un puerto es una
propiedad de un componente que
tiene una interfaz como su tipo.
3 Puerto de la interfaz necesaria. Representa un grupo de mensajes o
llamadas que envía el componente
a otros componentes o sistemas
externos. El componente está
diseñado para acoplarse a
componentes que proporcionan al
menos estas operaciones. El puerto
tiene una interfaz como su tipo.
4 Dependencia Se puede usar para identificar una
interfaz necesaria en un
componente, se puede satisfacer
mediante una interfaz
proporcionada por otro.
Las dependencias también se
pueden usar de manera más
general entre los elementos del
modelo para mostrar que el diseño
de uno depende del diseño del otro.
5 Parte Un atributo de un componente, cuyo
tipo suele ser otro componente.
Un elemento se usa en el diseño
interno de su componente primario.
Los elementos se muestran
gráficamente, anidados dentro del
componente primario.
Para crear un elemento de un tipo
de componente existente, arrastre el
componente desde el Explorador de
modelos UML hasta el componente
 propietario.
Para crear un elemento de un nuevo
tipo, haga clic en la herramienta
Componente y, a continuación,
haga clic en el componente
propietario.
Por ejemplo, un componente Car
tiene los elementos engine:
CarEngine, backLeft: Wheel,
frontRight: Wheel, etc.
Más de un elemento puede tener el
mismo tipo y componentes
diferentes pueden tener elementos
del mismo tipo.
- Tipo: el tipo de elemento,
que se define en otra
parte del modelo.
Normalmente, el tipo es
otro componente.
- Multiplicidad: el valor
predeterminado 1. Puede
establecerlo en 0….1 para
indicar que el elemento
puede tener valor null, en
* para indicar que el
elemento es una
colección de estancias del
tipo especificado o en
cualquier expresión que
pueda evaluar en un
intervalo de números.
6 Part Assembly Una conexión entre los puertos de
la interfaz necesaria de un elemento
y los puertos de la interfaz
proporcionada de otro elemento.
La implementación de un
ensamblado de elementos puede
variar de un componente a otro.
Los elementos conectados deben
tener el mismo componente
primario.
7 Delegación Una conexión entre los puertos de
la interfaz necesaria de un elemento
y los puertos de la interfaz
proporcionada de otro elemento. La
implementación de un ensamblado
de elementos puede variar de un
componente a otro. Los elementos
conectados deben tener el mismo
componente primario. Vincula un
puerto a una interfaz de uno de los
elementos del componente. Indica
que los mensajes enviados al
componente son administrados por
el elemento o que los mensajes
enviados desde el elemento se
envían desde el componente
primario.
Generalizaion Indica que un componente hereda
de otro componente.
Los elementos y las interfaces se
heredan.
9 Control Úselo para mostrar u ocultar los
Contraer o expandir elementos internos de un
componente.
comentario Para obtener notas adicionales.
Puede vincular un comentario a
cualquier número de elementos del
diagrama mediante la herramienta
Conector.
 3. ¿Qué es un proceso de desarrollo de software?

Un proceso está definido como una serie de acciones u operaciones que

conducen a un fin. En general, una empresa u organización requiere de uno o más
procesos para lograr sus objetivos, los cuales por lo general involucran la
utilización de sistemas de software. En el caso de una empresa que se dedica al
desarrollo de software, se requieren procesos que abarquen desde la creación de
un sistema de software hasta su mantenimiento. Todo esto es conocido como el
ciclo de vida del software., el desarrollo de sistemas de software es algo muy
complejo. De lo contrario todos haríamos siempre software perfecto Un aspecto
básico para manejar la complejidad inherente en los sistemas de software es
contar con un modelo de proceso a seguir.
4. ¿Cómo define el Autor Booch, que es un modelo?
Es un generador de potenciales configuraciones del sistema; los posibles sistemas
son sus extensiones, o valores. Idealmente, todas las configuraciones consistentes
con el modelo deberán ser posibles. A veces, sin embargo, no es posible
representar todas las restricciones dentro del modelo.
Es también una descripción de la estructura genérica y del significado de un
sistema.
Las descripciones son su objetivo o significado.
Es siempre una abstracción a un cierto nivel. Captura los aspectos esenciales de
un sistema y omite algunos de los detalles.

Tiene los siguientes aspectos:

Abstracción frente a detalle.

Especificación frente a implementación
Descripción frente a estancia.
Variaciones a la interpretación

5. Define y describe los siguientes conceptos:

Objeto
 Entidades discretas, con límites bien definidos y con identidad, que encapsulan el estado
y el comportamiento; se dice también de las estancias de una clase.
Abstracción

Acto de identificar aquellas características esenciales de una cosa que la distinguen del
resto de las cosas.
Tipo de dependencia que relaciona dos elementos que representan el mismo concepto
en diferentes niveles de abstracción.
Clases de objetos

Herencia

Se refiere al mecanismo por el que se comparten atributos y operaciones usando la

relación de generalización.
Clases

Clases
Una clase es un conjunto de objetos que comparten una estructura y comportamiento
comunes.

Clase representa una abstracción, la esencia que comparten los objetos.

Un objeto es un ejemplo de una clase.
Un objeto no es una clase, y una clase no es un objeto. Las clases actúan como
intermediarias entre una abstracción y los clientes que pretenden utilizar la abstracción.
De esta forma, la clase muestra:

Visión externa de comportamiento (interface), que enfatiza la abstracción escondiendo su

estructura y secretos de comportamiento.

Visión interna (implementación), que abarca el código que se ofrece en la interface de la

clase.
Polimorfismo.

Es una desahogo del sistema de tipos, de tal manera que una referencia a una clase
(atributo, parámetro o declaración local o elemento de un vector) acepta direcciones de
objetos de dicha clase y de sus clases derivadas (hijas, nietas,…).
5. ¿Cuáles son los tipos de diagramas que incluye UML y cuál es su objetivo?
Tipos de diagrama objetivo grafica
Casos de uso Estos diagramas
muestran operaciones
que se esperan de una
aplicación o sistema y
como se relaciona con
su entorno, es por ello
que se ve desde el
punto de vista del
usuario. Describen un
uso del sistema y
como éste interactúa
con el usuario.

De clases Estos diagramas son

utilizados durante el
proceso de análisis y
diseño de los sistemas
informáticos, en
donde se intentan
conformar el diagrama
conceptual de la
información que se
manejará en el
sistema.

De objetos Forma parte de la vista

estática del sistema.
En este diagrama se
modelan las instancias
de las clases del
Diagrama de Clases.
Este diagrama cabe
aclarar que cuenta con
objetos y enlaces. En
estos diagramas
también es posible
encontrar las clases
para tomar como
referencia su
instanciación.
Muestra un conjunto
de objetos y sus
relaciones en un
momento concreto.
Los Diagramas de
Objetos son realmente
útiles para modelar
estructuras de datos
complejas
De comportamientos: Diagrama de estados
De estados. engloba todos los
De actividad. mensajes que un
objeto puede enviar o
recibir, en otras
palabras es un
escenario que
representa un camino
dentro de un
diagrama.

Como característica
de estos diagramas
siempre cuentan con
dos estados
especiales, el inicial y
el final, con la
particularidad que este
diagrama puede tener
solo un estado inicial
pero varios estados
finales.

Es una variación del

Diagrama de Estados
UML donde los
estados representan
operaciones y las
transiciones
representan las
actividades que
ocurren cuando la
operación es
completa.
 De interacción: Un Diagrama de
De secuencia. Secuencias muestra
De Colaboración. una interacción
ordenada según la
secuencia temporal de
eventos y el
intercambio de
mensajes. Los
diagramas de
secuencia ponen
especial énfasis en el
orden y el momento en
el que se envían los
mensajes a los
objetos.

De Implementación: Normalmente contiene

De componentes. componentes,
De Despliegue. interfaces y relaciones
entre ellos.
Los componentes
perteneces a un
mundo físico, es decir,
representan a un
bloque de
construcción al
modelar aspectos
físicos de un sistema.
Básicamente este tipo
de diagrama se utiliza
para modelar el
Hardware utilizado en
la implementación del
sistema y las
relaciones entre sus
componentes.

6. Dentro de UML ¿Qué son las vistas y cuál es su clasificación?

Vistas:
Proyección de un modelo, que se ve desde cierta perspectiva o punto de
observación y emite aquellas entidades que no son relevantes para esa
perspectiva. Se refiere a las proyecciones tanto en el modelo semántico como en
la notación visual.
Clasificación:

Vista de Casos de Uso: Nos facilita información sobre el comportamiento y

funcionalidad del sistema.

Vista de Diseño: Nos proporciona información del vocabulario y la funcionalidad

del sistema.
 Vista de Interacción: Nos da información sobre el rendimiento del sistema, la
escalabilidad del mismo y la capacidad de procesamiento necesaria.

Vista de Implementación: Establece el ensamblado del sistema y la gestión de la

configuración.

Vista de Despliegue: Nos permite establecer la topología del sistema, su

distribución y las pautas para su instalación.

7. ¿Qué es un caso de uso?

Vista de Es una operación/tarea específica que se realiza tras una orden de algún
agente externo, sea desde una petición de un actor o bien desde la invocación
desde otro caso de uso.
9. Dentro de los casos de uso ¿Qué significa:
Asociaciones, generalización y relaciones?

 Relaciones:
o Asociación 

Es el tipo de relación más básica que indica la invocación desde un

actor o caso de uso a otra operación (caso de uso). Dicha relación se
denota con una flecha simple.
 o Dependencia o Instanciación 

Es una forma muy particular de relación entre clases, en la cual una

clase depende de otra, es decir, se instancia (se crea). Dicha relación
se denota con una flecha punteada.

o Generalización 

Este tipo de relación es uno de los más utilizados, cumple una doble
función dependiendo de su estereotipo, que puede ser
de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación está orientado exclusivamente para casos de

uso (y no para actores).

Extends: Se recomienda utilizar cuando un caso de uso es similar a

otro (características).

Uses: Se recomienda utilizar cuando se tiene un conjunto de

características que son similares en más de un caso de uso y no se
desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en

diseño y modelamiento de clases, en donde está la duda clásica
de usar o heredar.

Ejemplo:

Como ejemplo está el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El

sistema debe controlar y/o aceptar:

 Registrar el número de ítems ingresados.

 Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada ítem
c. Total
 El usuario/cliente presiona el botón de comienzo
 Existe un operador que desea saber lo siguiente:
a. Cuantos ítems han sido retornados en el día.
 b. Al final de cada día el operador solicita un resumen de todo lo
depositado en el día.
 El operador debe además poder cambiar:
a. Información asociada a ítems.
b. Dar una alarma en el caso de que:
i. Ítem se atora.
ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con
el sistema:

Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede

cambiar la información de un Ítem o bien puede Imprimir un informe:

Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después

de depositar algún ítem por un cliente o bien puede ser realizada a petición de un
operador.
Entonces, el diseño completo del diagrama Use Case es:

10. ¿Qué significa RUP?

El Proceso Unificado de Desarrollo de Software (RUP)
Introducción
El Proceso Unificado es un proceso de software genérico que puede ser utilizado para
una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes
tamaños de proyectos.
Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de
una organización de desarrollo. Su meta es asegurar la producción de software de muy
alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario
y presupuesto predecible.

• Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida
del proceso a lo largo de su desenvolvimiento
• Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el aspecto dinámico del proceso conforme se va
desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).
La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en
términos de componentes del proceso, disciplinas, actividades, flujos de trabajo,
artefactos y roles.
11. ¿Para qué nos sirve RUP en el desarrollo de software?
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un
sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios
prospectos.
El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas.
En este contexto, el término usuario representa algo o alguien que interactúa con el
sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un
resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los
casos de uso juntos constituyen el modelo de casos de uso el cual describe la
funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación
funcional del sistema. Una especificación funcional tradicional se concentra en responder
la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso
puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario?
Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en términos
del valor a los usuarios y no solamente en términos de las funciones que sería bueno que
tuviera. Sin embargo, los casos de uso no son solamente una herramienta para
especificar los requerimientos del sistema, también dirigen su diseño, implementación y
pruebas, esto es, dirigen el proceso de desarrollo.
Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada.
Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso
dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los
casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran
conforme avanza el ciclo de vida.
12. ¿Qué relevancia encontré en los contenidos para enriquecerme como persona y
en un futuro como profesional?
Encontré que con una buena planeación y análisis se puede facilitar la solución de
casi cualquier problema que ocurre en la vida diaria
13. ¿Qué me aporto esta unidad?
Me aporto mucho conocimiento, el uso de UML, me ayudara bastante cuando
necesite programar un código en algún lenguaje de programación como, ya lo
mencionaba antes, realizando los pasos convenientes facilitará la realización de
proyectos.
Bibliografía:

https://msdn.microsoft.com/es-mx/library/dd409390.aspx
http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html#casosuso