USAT – Ingeniería De Sistemas y Computación

DISEÑO DE SOFTWARE

RESUMEN

En la actualidad, el recurso primordial de las organizaciones es la Información. Esta constituye

la base de sus operaciones y servicios que brindes a sus clientes. El proceso de automatización
y manejo de la información mediante ordenadores ayuda a las empresas y organizaciones en el
proceso de tratamiento y administración de la información.
El apoyo en sistemas de información transaccional y gerencial es indispensable para poder
competir y tener ventajas en el medio.
Para desarrollar sistemas informáticos no basta con programar una aplicación, es necesario todo
un proceso de planificación, análisis, diseño y una posterior implementación e implantación del
sistema, de esto depende el éxito o fracaso de un sistema.
El RUP es un procesos de desarrollo que te orienta y guía durante las actividades implicadas en
los procesos de desarrollo de sistemas. Actualmente, esta metodología es muy utilizada en
nuestro medio para desarrollo de sistemas y nos permite construir diferentes tipos de
aplicaciones comerciales.

Ing. Consuelo Del Castillo Castro 1

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

INTRODUCCIÓN

El RUP (Proceso Unificado Rational) es un proceso Unificado de Desarrollo de Software,

ampliado utilizado en los entornos de desarrollo y construcción de aplicaciones informáticas.
Actualmente el RUP, es una de las metodologías más utilizadas y que junto a UML se han
constituido como los estándares en el proceso de construcción de aplicaciones comerciales de
distinta magnitud.

RUP, como proceso de desarrollo, fue diseñado específicamente para construir sistemas
informáticos basados en un lenguaje estándar de modelado, es decir UML. Ambos pertenecen
a la misma organización Rational Software Coorporation, y como es de suponer, junto al éxito
de UML como estándar abierto de modelado lo acompaña el RUP como proceso de desarrollo,
es por eso la importancia de construir sistemas basados en RUP.

Existen muchos proyectos que se dicen han aplicado el RUP como metodología o proceso de
desarrollo, pero son pocos los que realmente han aplicado realmente el RUP y han seguido
fielmente los flujos y procesos de documentación que propone.

Existe poco material documentado acerca de la aplicación del RUP en todo el proceso de
desarrollo de una solución informática y por lo tanto mucho desconocimiento acerca de cómo
seguir y aplicar adecuadamente esta metodología.

Es por eso, que al desarrollar este texto universitario, nuestro objetivo es proporcionar a los
lectores un material confiable de guía, donde demuestre y aplique adecuadamente todo un
proceso de desarrollo utilizando el RUP.

Ing. Consuelo Del Castillo Castro 2

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

INDICE

CAPITULO I .............................................................................................................................. 5
El Proceso Unificado de Desarrollo de Software ....................................................................... 5
1.1 PROCESO DE DESARROLLO DE SOFTWARE ................................................... 6
1.2 HISTORIA DEL PROCESO UNIFICADO .............................................................. 7
1.3 EL PROCESO UNIFICADO ................................................................................... 14
1.3.1 Proceso Unificado dirigido por casos de uso ................................................... 15
1.3.2 Proceso Unificado está centrado en la arquitectura ......................................... 16
1.3.3 Proceso Unificado es iterativo e Incremental ................................................... 17
1.4 LA VIDA DEL PROCESO UNIFICADO ............................................................... 18

CAPITULO II .......................................................................................................................... 22
Proceso Unificado Rational ...................................................................................................... 22
2.1 UN PROCESO DIRIGIDO POR CASOS DE USO ................................................ 23
2.2 UN PROCESO CENTRADO EN LA ARQUITECTURA...................................... 23
2.3 UN PROCESO ITERATIVO E INCREMENTAL .................................................. 26

CAPITULO III ......................................................................................................................... 28

Captura de Requisitos: Visión de los requisitos ....................................................................... 28
3.1 PROPÓSITO DEL FLUJO DE TRABAJO DE LOS REQUISITOS ...................... 29
3.2 VISIÓN GENERAL ................................................................................................. 29
3.3 MODELO DE DOMINIO ........................................................................................ 30
3.4 MODELO DE NEGOCIO ....................................................................................... 30

CAPITULO IV ......................................................................................................................... 32
Captura de Requisitos: Casos de uso........................................................................................ 32
4.1 ARTEFACTOS ........................................................................................................ 34
4.2 TRABAJADORES ................................................................................................... 36
4.3 FLUJO DE TRABAJO............................................................................................. 36

CAPITULO V .......................................................................................................................... 40
Análisis ..................................................................................................................................... 40
5.1 ARTEFACTOS ........................................................................................................ 44
5.2 TRABAJADORES ................................................................................................... 50
5.3 FLUJOS DE TRABAJO .......................................................................................... 50

CAPITULO VI ......................................................................................................................... 52
Diseño....................................................................................................................................... 52
6.1 ARTEFACTOS ........................................................................................................ 55
6.2 TRABAJADORES ................................................................................................... 59
6.3 FLUJOS DE TRABAJO .......................................................................................... 60

CAPITULO VII........................................................................................................................ 62
Implementación ........................................................................................................................ 62
7.1 ARTEFACTOS ........................................................................................................ 65
7.2 TRABAJADORES ................................................................................................... 69
7.3 FLUJOS DE TRABAJO .......................................................................................... 70

Ing. Consuelo Del Castillo Castro 3

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO VIII ...................................................................................................................... 73

Prueba del Sistema ................................................................................................................... 73
8.1 ARTEFACTOS ........................................................................................................ 76
8.2 TRABAJADORES ................................................................................................... 78
8.3 FLUJOS DE TRABAJO .......................................................................................... 80

CAPITULO IX ......................................................................................................................... 83
Aplicación del RUP .................................................................................................................. 83

BIBLIOGRAFIA………………………………………………………………………...….173

Ing. Consuelo Del Castillo Castro 4

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO I
El Proceso Unificado de Desarrollo de
Software

Ing. Consuelo Del Castillo Castro 5

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

1.1 PROCESO DE DESARROLLO DE SOFTWARE

Un proceso define quien está haciendo qué, cuándo y como alcanzar un determinado
objetivo. En la ingeniería del software el objetivo es construir un producto software o
mejorar uno existente.

Un proceso de desarrollo de software debería también ser capaz de evolucionar durante

muchos años, debiendo limitar su alcance a realidades que permitan las tecnologías,
herramientas, personas y patrones de organización.

 Tecnologías: El proceso debe construir sobre tecnologías: Lenguajes de

programación, sistemas operativos, computadoras, estructuras de red, entornos de
desarrollo, etc.
 Herramientas: Los procesos y las herramientas deben desarrollar en paralelo, las
herramientas son esenciales en el proceso.
 Personas: Un creador del proceso debe limitar el conjunto de habilidades necesarias
para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen.
 Patrones de Organización: El creador del proceso debe adaptar el proceso de las
realidades del momento, tal como Empresas Virtuales: trabajo a distancia a través
de líneas de alta velocidad.

Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias en el
presente y para el futuro también. Un proceso debe ser estable, sin este equilibrio de
tecnologías, herramientas, personas y organización, el uso del presente sería bastante
arriesgado.

El proceso de desarrollo debe estar presente en las tareas de todos los participantes en el
desarrollo del sistema, así tenemos: los analistas y usuarios finales son los encargados de
especificar la estructura y comportamiento requerido por el sistema, los desarrolladores de
aplicaciones diseñan los sistemas que satisfacen esos requisitos, programadores convierten
esos diseños en códigos ejecutables los ingenieros de prueba validan la estructura y
comportamiento del sistema.

Ing. Consuelo Del Castillo Castro 6

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

1.2 HISTORIA DEL PROCESO UNIFICADO

El proceso Unificado es el producto final de tres décadas de desarrollo y uso práctico. A

continuación vamos a revisar como ha sido el proceso de evolución del RUP a través del
tiempo:

1. EL método Ericsson (1967): Ericsson modelaba el sistema entero como un conjunto de

bloques interconectados (subsistemas implementados en componentes según UML),
después ensamblaba los bloques de más bajo nivel en subsistemas de más alto nivel
haciendo el sistema más manejable. Identificaban los bloques estudiando los casos de
negocio (hoy casos de uso). Para cada caso de uso identificaban los bloques que debían
cooperar para realizarlos, preparaban sus especificaciones. Sus actividades de diseño
producían un conjunto de diagramas de bloques estáticos con interfaces agrupados en
subsistemas. Estos diagramas de bloques corresponden directamente a diagramas de
clases o paquetes de UML.
El primer producto de las actividades de diseño era una descripción de la arquitectura
software. La descripción de la arquitectura software y la biblioteca de mensajes eran los
documentos fundamentales que guiaban el trabajo de desarrollo. Para cada caso de uso
los ingenieros preparaban un diagrama de secuencia o u diagrama de colaboración.

2. Lenguaje de descripción y Especificación (1976): El organismo internacional para la

estandarización en el área de las telecomunicaciones publicó en 1976 El Lenguaje de
Descripción y Especificación (Specification and Description Language, SDL) para el
comportamiento funcional de los subsistemas de telecomunicaciones. Cada bloque
poseía un conjunto de procesos para designar las clases activas. Un proceso poseía
instancias, las cuales interactuaban mediante mensajes. SDL proponía diagramas que
eran especializaciones de lo que hoy UML llama diagrama de clases, diagrama de
actividad, diagrama de colaboración y diagramas de secuencia.

3. Objectory (1987): Ivar Jacobson dejó Ericsson y fundó Objectory AB en Estocolmo.

Desarrollaron un proceso denominado Objectory (Fábrica de objetos). El concepto de
caso de uso, presente en el trabajo de Ericsson, ahora se le había dado nombre, se había
desarrollado una técnica de representación y la idea se había ampliado abarcando una
variedad de aplicaciones. Los flujos de trabajo sucesivos se representaron en una serie

Ing. Consuelo Del Castillo Castro 7

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

de modelos: requisitos-casos de uso, análisis, diseño, implementación y prueba. Un

modelo es una perspectiva del sistema.

4. El método Rational (1995): Rational Software Coorporation compró Objecory AB a

finales de 1995 y la tarea de unificar los principios básicos subyacentes en los procesos
de desarrollo existentes adquirió urgencia especial. Las dos contribuciones más
importantes al proceso fueron los énfasis en la arquitectura y en el desarrollo iterativo.
El método de cuatro fases se diseño para estructurar mejor y controlar el proceso durante
las iteraciones. En la planificación detallada de las fases y la ordenación de las
iteraciones participó Grady Booch y tros investigadores.

5. El proceso Objectory de Rational (1995 - 1997): En el momento de la fusión, Objectory

había demostrado que se puede crear y modelar un proceso de desarrollo de software
como si fuese un producto. Se añadieron la experiencia y práctica de Rational para
formar el Proceso Objectory de Racional 4.1. Se añadió las fases y la aproximación
iterativa. La arquitectura se hizo explícita en forma de una descripción de la
arquitectura, Biblia de la organización de desarrollo de software. Se desarrollo una
definición precisa de la arquitectura, la arquitectura se representaba como vistas
arquitectónicas de los modelos.
UML estaba en fase de desarrollo y se incorporó como el lenguaje de modelado del
proceso Objectory de Rational (ROP).

6. El Lenguaje Unificado de Modelado: Grady Booch autor del método Booch y James
Rumbaugh desarrollador principal de OMT (Centro de Investigación y Desarrollo de
General Electric) comenzaron el trabajo de unificar métodos publicando una versión del
Método Unificado en Octubre de 1995, tiempo en el que Ivar Jacobson se incorpora a
Rational. Los tres, trabajando juntos, publicando la versión 0.9 del Lenguaje Unificado
de Modelado. En 1997, después de pasar por el proceso de estandarización, el OMG –
Object Management Group publicó como estándar la versión 1.1 de UML.
El proceso Objectory de Racional utilizó UML en todos sus modelos.

7. El Proceso Unificado de Rational: Rational se fusionó a otras empresas fabricantes de

herramientas, cada una aportó su experiencia en áreas del proceso que ampliaron más

Ing. Consuelo Del Castillo Castro 8

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

aún el proceso Objectory de Rational. Utiliza el modelo de negocio para obtener los
requisitos a partir de los procesos de negocios que el software va a cubrir, también se
extendió con diseño de interfaces de usuario dirigido por los casos de uso (basado en
Objectory AB).
En Junio de 1998, Rational publicó una nueva versión del producto, El Proceso
Unificado de Rational 5.0. El cambio de nombre refleja el hecho de que la unificación
ha tenido lugar en muchas dimensiones: unificación de técnicas de desarrollo y
unificación del trabajo de muchos metodologistas.

Ing. Consuelo Del Castillo Castro 9

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Proceso Unificado de Rational 5.0

Otras Fuentes

Proceso Objectory de Rational 4.1

1996-1997

El método Rational UML

Proceso Objectory 1.0 – 3.8

1987-1995

Método Ericsson
1967

Figura 1: El desarrollo del Proceso Unificado

Ing. Consuelo Del Castillo Castro 10

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

RESUMEN HISTORIA DEL PROCESO UNIFICADO

MÉTODOS INFLUYENTES CARACTERÍSTICAS PRINCIPALES

- Modela el sistema entero como un conjunto de bloques interconectados.

(subsistemas en UML implementadas mediante componentes)
- Ensambla los bloques de más bajo nivel en subsistemas de más alto nivel.
- Utilizaban casos de negocio para identificar los bloques.
- Preparaban especificaciones en base al conocimiento de responsabilidades.
- Sus actividades de diseño producían un conjunto de diagramas de bloques
estáticos, los cuales se corresponden directamente a los diagramas de clases
o paquetes de UML.
- La descripción de la arquitectura software se basaba en la comprensión de los
El método Ericson
requisitos más críticos.
- Los mensajes (interconexiones, que son un tipo de mensajes, usados en los
diagramas de bloques) quedaban descritos en una biblioteca de mensajes.
- Los documentos que guiaban el trabajo de desarrollo eran la descripción de
la arquitectura software y la biblioteca de mensajes.
- Para cada caso de uso se preparaban un diagrama de secuencia o bien un
diagrama de colaboración.
- El método que utilizaban era el que hoy conocemos como desarrollo basado
en componentes.
- Estándar para el comportamiento funcional de los sistemas de
telecomunicación publicado en 1976.
- Especifica un sistema como un conjunto de bloques interconectados que se
comunicaban unos con otros a través de mensajes (señales).
- Cada boque poseía un conjunto de procesos, término para designar clases
activas.
Lenguaje de descripción y  Clase activa: Una clase cuyas instancias son objetos activos.
Especificación  Objetos activos: un objeto que posee un proceso o hilo y puede iniciar
SDL actividad de control.
- Un proceso poseía instancias (parecido a clases en términos de orientación a
objetos).
- Las instancias de los procesos interactuaban mediante mensajes.
- Proponía diagramas de clases, de actividad, de secuencia y colaboración
(especializaciones de lo que hoy conocemos como UML).
- SDL era un estándar de modelado de objetos especializado.
- Fundado por Ivar Jacobson en 1987 (Objectory AB).
Objectory
- Objectory = “Object Factory” – Fábrica de objetos.

Ing. Consuelo Del Castillo Castro 11

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE
- Se le da el nombre a los casos de uso, se había desarrollado una técnica de
representación abarcando la variedad de aplicaciones.
- Los casos de uso que dirigían el desarrollo se hicieron más claros.
- Comenzó a destacar la arquitectura.
- Los flujos de trabajo se representaron en una serie de modelos: requisitos de
casos uso, análisis, diseño, implementación y prueba.
- Un modelo es una perspectiva del sistema.
- El propio proceso de desarrollo de software Objectory era un producto de
ingeniería.
- La forma de describir un proceso era como un producto en forma de sistema.
- Aportó ideas de cómo diseñar los procesos generales sobre los cuales opera
un negocio.
- Rational Software Corporation compra Objectory AB a finales de 1995.
- Urgencia de unificar os principios básicos subyacentes en los procesos de
desarrollo existentes.
- Gran importancia al diseño orientado a objetos, la abstracción, la ocultación
de la información, la reutilización y el prototipado.
- El énfasis en la arquitectura y desarrollo iterativo fueron las dos
contribuciones mas importantes al proceso.
El método Rational - Se maneja la idea de tener un conjunto de vistas, en lugar de tratar de meter
todo en un único tipo de diagrama, representar la arquitectura con cuatro
vistas: lógica, de procesos, física y de desarrollo.
- Se diseña un método de cuatro fases (comienzo, elaboración, construcción y
transición) para estructurar mejor y controlar el proceso durante las
iteraciones.
- Booch mencionó dos principios fundamentales sobre la arquitectura y la
iteración.
- Objectory había demostrado que se puede crear y modelar un proceso de
desarrollo software como si fuese un producto.
- Le añadieron la experiencia y práctica de Rational para formar el proceso
Objectory de Rational. Se añadieron las fases y la aproximación iterativa
controlada.
El Proceso Objectory de
- Se desarrolla una descripción de la arquitectura: la “BIBLIA” de la
Rational 1995-1997
organización de desarrollo de software. Definición precisa de la arquitectura
representada como vistas arquitectónicas de los modelos.
- Se amplió el desarrollo iterativo.
- UML estaba en desarrollo y se incorporó como el lenguaje de modelado del
Proceso Objectory de Rational (ROP).
El Proceso Unificado de - Rational compró o se fusionó con otras empresas fabricantes de herramientas
Rational aportando, cada una de ellas su experiencia en áreas del proceso.

Ing. Consuelo Del Castillo Castro 12

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE
- Se amplió con un nuevo flujo de trabajo para el modelado de negocio basado
en Reingeniería de procesos de negocios con tecnología de objetos,
utilizada para obtener requisitos a partir de procesos de negocios que el SW
va a cubrir.
- Diseño de interfaces de usuarios dirigido por casos de uso.
- En Junio del 98 Rational publicó su versión: Proceso Unificado de Rational
5.0, puestos a disposición del público. El cambio de nombre se dió por la
unificación de técnicas de desarrollo, a través de UML, y unificación del
trabajo de muchos metodologistas.

Tabla 1: Resumen de la Historia del RUP

Ing. Consuelo Del Castillo Castro 13

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

1.3 EL PROCESO UNIFICADO

“Dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental”

La tendencia actual en el software lleva a la construcción de sistemas mas grandes y mas

complejos, esta tendencia se ha visto afectada por el uso creciente de Internet para el
intercambio de todo tipo de información y la aspiración de un software mas sofisticado
como resultado de mejoras de productos.

El problema del software se reduce a la dificultad que afrontan los desarrolladores para
coordinar las múltiples cadenas de trabajo de un gran proyecto de software. Los
desarrolladores necesitan un proceso que integre las múltiples facetas de desarrollo, se
necesita un proceso que:

 Proporcione una guía para ordenar las actividades de un equipo.

 Dirija las tareas de cada desarrollador por separado y del equipo como un todo.
 Especifique los artefactos que deben desarrollarse.
 Ofrezca criterios para el control y la medición de los productos y actividades de los
proyectos.

La presencia de un proyecto bien definido y bien gestionado es una diferencia esencial entre
proyectos hiperproductivos y otros que fracasan, el proceso de desarrollo de software es una
solución al problema del software como producto de más de 30 años de experiencia.

El proceso unificado es un proceso de desarrollo de software. Un proceso de desarrollo de

software es el conjunto de actividades necesarias para transformar los requisitos de un
usuario en un sistema software, es más que un simple proceso, es un marco de trabajo
genérico que puede especializarse para una gran variedad de sistemas software de diferentes
áreas de aplicación, tipos, niveles y tamaños de proyectos.

1. El proceso unificado está basado en componentes, es decir, el software de

construcción está basado en componentes software interconectados a través de
interfaces bien definidas.

Ing. Consuelo Del Castillo Castro 14

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

2. El proceso unificado utiliza el Lenguaje Unificado de modelado – UML para

preparar todos los esquemas de un sistema software.

Los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres fases clave:

1. Dirigido por casos de uso.

2. Centrado en la arquitectura.
3. Iterativo e Incremental.

Proceso de Desarrollo de
Software

Requisitos de Usuario Sistema Software

Figura 2: Un proceso de desarrollo de software

1.3.1 Proceso Unificado dirigido por casos de uso

Para construir un sistema con éxito debemos conocer lo que sus futuros usuarios
necesitan y desean. El término usurario hace referencia a usuarios humanos y otros
sistemas (representa algo o alguien que interactúa con el sistema que estamos
desarrollando). Las interacciones de los usuarios con el sistema constituyen casos de
uso.

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario

un resultado importante. Los casos de uso representan los requisitos funcionales. Todos
los casos de uso forman el modelo de casos de uso.

Los casos de uso no son solo una herramienta para especificar los requisitos del sistema,
también guían su diseño, implementación y prueba, es decir guían el proceso de
desarrollo.

Ing. Consuelo Del Castillo Castro 15

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un
hilo que los conduce. Dirigido por casos de uso quiere decir que el proceso de desarrollo
sigue un hilo, avanzando a través de una serie de flujos de trabajo que parten de los
casos de uso.

Los casos de uso guían la arquitectura del sistema y la arquitectura del sistema influye
en la selección de los casos de uso. La arquitectura del sistema como los casos de uso
madura según avanza el ciclo de desarrollo.

1.3.2 Proceso Unificado está centrado en la arquitectura

La arquitectura en un sistema software se describe mediante diferentes vistas del sistema

en construcción, permitiendo ver una imagen completa antes de comenzar la
construcción del sistema software.

El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más

significativos del sistema, surge de las necesidades de la empresa y se refleja en los
casos de uso. Se ve influida por muchos factores como: plataforma en la que tiene que
funcionar el software (hardware, sistema operativo, gestor de base de datos, protocolos
de red, etc.), los bloques de construcción de trabajos reutilizables, consideraciones de
implantación, sistemas heredados y requisitos no funcionales.

La arquitectura es una vista del diseño completo con las características más importantes
resaltadas, dejando detalles de lado.

Los casos de uso se encargan de las funciones y la arquitectura de la forma. Debe haber
interacción entre los casos de uso y la arquitectura, asimismo los casos de uso deben
encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el
desarrollo de todos los casos de uso requeridos.

Los arquitectos moldean un sistema para darle forma, la misma que debe diseñarse para
permitir que el sistema evolucione, no solo en su desarrollo, sino también a lo largo de
las futuras generaciones, para ello los arquitectos deben de trabajar en los casos de uso
claves del sistema (5-10 % de todos los casos de uso del sistema).

Ing. Consuelo Del Castillo Castro 16

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Las tareas que realiza el arquitecto son:

- Crea un esquema en borrador de la arquitectura, comenzando por la parte de la
arquitectura que no es específica de los casos de uso (ejm. plataforma).
- Luego el arquitecto trabaja con un subconjunto de los casos de uso especificados,
con aquellos que representen las funciones claves del sistema en desarrollo.
Cada caso de uso se especifica en detalle y se realiza en términos de subsistemas,
clases y componentes.
- A medida que los casos de uso se especifican y maduran, se descubre más la
arquitectura, llevando a la maduración de más casos de uso.
Este proceso continua hasta que se considere que la arquitectura es estable.

1.3.3 Proceso Unificado es iterativo e Incremental

Es práctico dividir el trabajo en partes mas pequeñas o miniproyectos, donde cada

miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen
referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto.
Las iteraciones deben estar controladas para una efectividad máxima, es decir, deben
seleccionarse y ejecutarse de una forma planificada.

Los desarrolladores basan la selección de lo que se implementará en una iteración en

dos factores:

1. La iteración trata de un grupo de casos de uso que juntos amplían la utilidad del
producto desarrollado.
2. La iteración trata los riesgos más importantes.

En cada iteración, los desarrolladores identifican y especifican los casos de uso

relevantes, crean un diseño utilizando la arquitectura seleccionada como guía,
implementan el diseño mediante componentes, y verifican que los componentes
satisfacen a los casos de uso.

Entre los beneficios de un proceso iterativo controlado tenemos:

Ing. Consuelo Del Castillo Castro 17

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- La iteración controlada reduce el riesgo a los costes de un solo incremento.

- La iteración controlada reduce el riesgo de no sacar al mercado el producto en
el calendario previsto.
- La iteración controlada acelera el ritmo del esfuerzo de desarrollo en su
totalidad.
- La iteración controlada reconoce una realidad que a medida se ignoran: las
necesidades del usuario y sus correspondientes requisitos no pueden definirse
completamente al principio.

1.4 LA VIDA DEL PROCESO UNIFICADO

El proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de
un sistema. Cada ciclo concluye con una versión del producto para los clientes.
Cada ciclo consta de cuatro fases: Inicio, Colaboración, Construcción y Transición.

El Producto: Cada ciclo produce una nueva versión del sistema y cada versión es un
producto preparado para su entrega. El producto terminado no solo debe ajustarse a las
necesidades de los usuarios, sino también a la de todos los interesados.

El producto terminado incluye los requisitos, casos de uso, especificaciones nos funcionales
y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual.

Aunque los componentes ejecutables sean los artefactos mas importantes, no son suficientes
por si solos debido a los cambios del entorno.

Inicio Elaboración Construcción Transición

Iterac.1 Iterac. 2 …. ….. ….. ….. Iterac. n-1 Iterac. n

VERSIONES

Figura 3: Vista de un proceso: consta de ciclos desde su nacimiento hasta su muerte

Ing. Consuelo Del Castillo Castro 18

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Para llevar a cabo el siguiente ciclo de forma eficiente, los desarrolladores necesitan las
siguientes representaciones del producto software:

 Un modelo de casos de uso.

 Un modelo de análisis.
 Un modelo de diseño que defina la estructura estática del sistema y los casos de uso
reflejado como colaboraciones entre subsistemas, clases e interfaces.
 Un modelo de implementación que incluya componentes y la correspondencia de
las clases con los componentes.
 Un modelo de despliegue que defina los nodos físicos y correspondencia entre
nodos.
 Un modelo de prueba que describa los casos de prueba que verifican los casos de
uso.
 Una representación de la arquitectura.

Fases dentro de un ciclo: Cada ciclo se desarrolla a lo largo del tiempo, el cual se divide
en cuatro fases. Dentro de cada fase los desarrolladores pueden descomponer el trabajo en
iteraciones con sus incrementos resultantes. Cada fase se termina con un hito.

Cada fase se divide normalmente en iteraciones o miniproyectos. Una iteración normal para
por los cinco flujos de trabajo.

Ing. Consuelo Del Castillo Castro 19

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Fases
Flujos de Trabajo Inicio Elaboración Construcción Transición
Fundamentales

Requisitos
Una Iteración
en la fase de elaboración
Análisis

Diseño

Implementación

Prueba

Iter. Iter. … … …. … … Iter. Iter.

#1 #2 #n-1 #n

Figura 4: Los cinco flujos de trabajo sobre las cuatro fases

 Fase de Inicio: se desarrolla una descripción del producto final en base a una idea y se
presenta el análisis de negocio para el producto.
 Fase de Elaboración: se especifican en detalle la mayoría de los casos de uso del
producto y se diseña la arquitectura del sistema. El resultado de esta fase es la línea base
de la arquitectura. Al final de esta fase el director del proyecto está en disposición de
planificar las actividades y estimar los recursos necesarios para terminar el proyecto.
 Fase de Construcción: se añade el software terminado a la arquitectura. La línea base
de la arquitectura crece hasta convertirse en el sistema completo. Al final de esta fase,
el producto contiene todos los casos de uso que la dirección y el cliente han acordado
para el desarrollo de esta versión.
 Fase de Transición: cubre el período durante el cual el producto se convierte en versión
beta, el cual es probado por un número reducido de usuarios con experiencia los cuales
informan los defectos y deficiencias. Los desarrolladores corrigen los problemas e

Ing. Consuelo Del Castillo Castro 20

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

incorporan mejoras sugeridas. La fase de fabricación conlleva actividades como la

fabricación, formación del cliente, línea de ayuda y asistencia y corrección de los
defectos que se encuentren tras la entrega del producto.

Un proceso Integrado

El proceso Unificado está basado en componentes. Utiliza el Lenguaje Unificado de

Modelado (UML) y se sostiene en tres ideas: casos de uso, arquitectura y desarrollo iterativo
e incremental. Para que esto funcione se necesita de un proceso que tenga en cuenta ciclos,
fases, flujos de trabajo, gestión del riesgo, control de calidad, gestión de proyecto y control
de la configuración.

Ing. Consuelo Del Castillo Castro 21

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO II

Proceso Unificado Rational

Ing. Consuelo Del Castillo Castro 22

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

2.1 UN PROCESO DIRIGIDO POR CASOS DE USO

La captura de requisitos tiene dos objetivos:
- Encontrar los verdaderos requisitos
- Representarlos de un modo adecuado
Un verdadero requisito es aquel que cuando se implementa añadirá el valor esperado para
los usuarios.

¿Por qué casos de uso?

- Por que proporcionan un medio sistemático e intuitivo de capturar requisitos.
- Dirigen todo el proceso de desarrollo debido a que la mayoría de las actividades
(Análisis, diseño e implementación) se llevan a cabo partiendo de los casos de uso.

Ítems a considerar:
- Los usuarios y los clientes son los expertos en los requisitos.
- Los casos de uso enlazan los flujos de trabajo fundamentales.
- Los casos de uso ayudan a los jefes de proyecto a planificar, asignar y controlar
muchas de las tareas que los desarrolladores realizan.
- Los casos de uso ayudan a llevar a cabo el desarrollo iterativo. En cada iteración se
identifican e implementan unos cuantos casos de uso.
- Se utilizan diagramas de casos de uso, donde cada actor representa un usuario y
estos se comunican con el sistema mediante el envío y recepción de mensajes.

2.2 UN PROCESO CENTRADO EN LA ARQUITECTURA

La arquitectura nos da una clara perspectiva del sistema completo, es necesaria la

arquitectura para poder controlar el desarrollo.
Describe los elementos más importantes del modelo, estos elementos nos guían en nuestro
trabajo con el sistema.
Los elementos arquitectónicamente significativos son los siguientes:
- Algunos de los subsistemas.
- Dependencias.
- Interfaces.
- Colaboraciones.

Ing. Consuelo Del Castillo Castro 23

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Nodos y clases activas.

Estas ideas de arquitectura, es desarrollada por los arquitectos iterando repetidas veces
durante la fase de inicio y colaboración. El primer objetivo de la fase de elaboración es
establecer una arquitectura.

Recordar siempre que:

“La idea de la arquitectura es lo que se encuentra en la mente del autor”

La arquitectura abarca decisiones importantes sobre:

- La organización del sistema software.
- Los elementos estructurales que compondrían el sistema y sus interfaces.
- La composición de los elementos estructurales y del comportamiento en
subsistemas.
- El estilo de la arquitectura.
La arquitectura software está afectada por:
- Estructura.
- Comportamiento.
- Uso.
- Funcionalidad.
- Rendimiento.
- Flexibilidad
- Reutilización.
- Facilidad de comprensión.
- Restricciones.
- Compromisos económicos, tecnológicos y la estética.

La arquitectura se representa mediante vistas, las cuales se basan en los modelos

existentes, por ejemplo: modelo de casos de uso, modelos de análisis, etc.

Para una arquitectura se necesita:

- Comprender el sistema.
- Organizar el desarrollo.

Ing. Consuelo Del Castillo Castro 24

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Fomentar la reutilización.
- Hacer evolucionar el sistema.

Debemos crear una arquitectura que nos permita implementar los casos de uso de una
forma económica, ahora y en el futuro.

Casos de uso
- Software del sistema
- Capa intermedia (marcos de trabajo)
- Sistemas heredados
- Estándares y políticas corporativas
ARQUITECTURA (Lenguaje de definición de interfaces)
- Requisitos no funcionales
(disponibilidad, recuperación, memoria,
etc.)
- Necesidades de distribución

Experiencia:
- arquitecturas anteriores.
- Patrones de arquitectura.

CASOS DE USO

Guía Conduce

ARQUITECTURA

Capa intermedia (middleware): capa que ofrece bloques de construcción reutilizables

(paquetes o subsistemas) a marcos de trabajo o servicios independientes de la
plataforma, para cosas como computación con objetos distribuidos, o interoperabilidad

Ing. Consuelo Del Castillo Castro 25

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

en entornos heterogéneos. Cualquier producto que lleva a cabo mecanismos de diseño

genéricos. (Investigas capas de software del sistema)

La descripción de la arquitectura es un conjunto de vistas del sistema, incluyen elementos

arquitectónicamente significativos (que son parte de la línea base de la arquitectura). La
línea base de la arquitectura no solo se usa para desarrollar una arquitectura, sino que
especifica los requisitos del sistema en un nivel que permita el desarrollo de un plan
detallado.
La descripción de la arquitectura se debe mantener actualizada a lo largo de la vida del
sistema para reflejar los cambios y las adiciones que son relevantes para la arquitectura.
Vistas de arquitectura:

- Vista del modelo de casos de uso: define los actores y los casos de uso más importantes,
o escenarios de esos casos de uso.
- Vista del modelo de análisis: abarca clases, paquete y realizaciones de casos de uso de
análisis. Fundamentalmente aborda el refinamiento y estructuración de los requisitos
del sistema.
- Vista de modelo de diseño: presenta los clasificadores más importantes para la
arquitectura en el diseño: subsistemas e interfaces más importantes, y algunas pocas
clases muy importantes.
- Vista de modelo de despliegue: define la arquitectura física del sistema por medio de
nodos interconectados. Estos nodos son elementos hardware sobre los cuales pueden
ejecutarse elementos software. Nodos que forman la topología hardware sobre la que se
ejecuta el sistema.
- Vista del modelo de implementación: correspondencia directa de los modelos de diseño
y despliegue. Cada subsistema acaba sendo un componente por cada tipo de nodo en el
que deba instalarse, pudiéndose en algunos casos ejecutarse sobre varios nodos el
mismo componente.

2.3 UN PROCESO ITERATIVO E INCREMENTAL

Un proceso debe tener en cuenta una secuencia de hitos.
Las fases del proceso son:

Ing. Consuelo Del Castillo Castro 26

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Fase de inicio: identificación y reducción de riesgos. Idea inicial para el desarrollo

la cual se refina hasta quedar lo suficientemente bien establecida como para
garantizar la entrada en la fase de elaboración.
- Fase de elaboración: preparación del plan de proyecto. Se define la arquitectura
(Línea base de la arquitectura)
- Fase de construcción: incrementos y entregas periódicas. El software es desarrollado
a partir de una línea base de arquitectura ejecutable, hasta que esté lista para ser
transmitido a la comunidad de usuarios.
- Fase de transición: corrección de defectos. El software es puesto a la comunidad de
usuarios.

El desarrollo iterativo se hace teniendo en cuenta un desarrollo en pequeños pasos:

- Planificar un poco.
- Especificar, diseñar e implementar un poco.
- Integrar, probar y ejecutar un poco en cada iteración.

En las primeras fases vamos reduciendo gradualmente los riesgos e implementando los
componentes.
El ciclo de vida iterativo produce resultados tangibles en forma de versiones internas y
cada una de ellas aporta un incremento y reduce riesgos.

Ing. Consuelo Del Castillo Castro 27

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO III

Captura de Requisitos: Visión de los

requisitos

Ing. Consuelo Del Castillo Castro 28

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Captura de requisitos es el acto de descubrimiento, proceso de averiguar lo que se debe

construir.
La captura de requisitos es un proceso complicado y difícil.
La captura de requisitos empieza por obtener una lista de requisitos de cada usuario con la
esperanza de tener una visión de conjunto y comprender una especificación de requisitos
completo.
Es importante que los sistemas den soporte a la misión para lo cual se construyen.

3.1 PROPÓSITO DEL FLUJO DE TRABAJO DE LOS REQUISITOS

El propósito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo hacia
el sistema correcto, lo cual es posible conseguir mediante una buena descripción de los
requisitos del sistema (condiciones o capacidades que el sistema debe cumplir) en acuerdo
entre los clientes y los desarrolladores, acerca de lo que debe y no debe hacer el sistema.
Un reto fundamental para conseguirlo es que el cliente (especialista no informático) sea
capaz de leer y comprender el resultado de la captura de requisitos. Para alcanzar este
objetivo debemos utilizar el lenguaje de cliente.
Los resultados del flujo de trabajo de los requisitos ayudan al jefe de proyecto a planificar
las iteraciones y las versiones del cliente.

3.2 VISIÓN GENERAL

Opcionalmente se puede empezar realizando un modelo de negocios, en otros casos se
utiliza un software empotrado (no da soporte directo al negocio) teniendo como entrada un
modelo de objetos sencillo, como un modelo de dominio, y en otros casos el cliente puede
haber desarrollado ya una especificación de requisitos a partir del cual se puede comenzar
y negociar los cambios.
Este flujo de trabajo incluye los siguientes pasos:
- Enumerar los requisitos candidatos: muchas buenas ideas para convertirse en
verdaderos requisitos. Los requisitos candidatos pueden ser implementados mas
adelante. Se elabora una lista de características, la cual se utiliza solo para planificar el
trabajo. Cada característica tiene un nombre corto y una definición, además tiene:
o ESTADO: presupuesto, aprobado, incluido o validado
o COSTE ESTIMADO DE IMPLEMENTACIÓN: tipos de recursos y hora de
personal.

Ing. Consuelo Del Castillo Castro 29

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

o PRIORIDAD: crítico, importante o secundario.

o NIVEL DE RIESGO: tiene relación con la implementación de la característica.
- Comprender el contexto del sistema: Obtener un firme conocimiento del contexto en
el que se va a desarrollar el sistema. Existen dos formas de expresar el contexto del
sistema:
o MODELADO DE DOMINIO: describe los conceptos importantes del contexto
como objetos del dominio enlazando estos objetos unos con otros. Nos ayuda a
desarrollar el glosario de términos.
o MODELADO DE NEGOCIO: es describir los procesos con el objetivo de
comprenderlos. Parte de la ingeniería de negocios.
- Capturar los requisitos funcionales: la técnica para identificar los requisitos del
sistema en base a los casos de uso. Se obtiene el modelo de casos de uso.
- Capturar requisitos NO funcionales: los requisitos no funcionales especifican las
propiedades del sistema, como restricciones del entorno o de la implementación,
rendimiento, dependencias de la plataforma, mantenimiento, extensibilidad y fiabilidad,
etc. Se obtiene una lista de requisitos adicionales: requisito de carácter general que no
puede ser asociado a un caso de uso en concreto o una clase concreta del mundo real.

3.3 MODELO DE DOMINIO

Un modelo de dominio captura los tipos más importantes de objetos en el contexto del
sistema. Los objetos de dominio representan las “cosas” que existen o los “eventos” que
suceden en el entorno en que trabaje el sistema.
Las clases de dominio aparecen de tres formas típicas:
- Objetos del negocio: representan cosas que se manipulan en el negocio, ejm.
Pedidos, cuentas, contratos, etc. (misiles y trayectorias)
- Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento.
- Sucesos que ocurrirán o han ocurrido (llegada o salida de un avión).
El modelo de dominio se describe mediante diagramas de UML: diagrama de clases.
El objetivo del modelo de dominio es comprender y describir las clases más importantes
dentro del contexto del sistema.

3.4 MODELO DE NEGOCIO

Ing. Consuelo Del Castillo Castro 30

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Es una técnica para comprender los procesos de negocio de la organización. El objetivo es

identificar los casos de uso del software y las entidades de negocio relevantes que el
software debe soportar. Participa en casos de uso de más alto nivel.
El modelado del negocio está soportado por dos tipos de modelos de UML: modelos de
casos de uso y modelos de objetos.

Un modelo de casos de uso de negocio: describe los procesos de negocio de una empresa
en términos de casos de uso y actores del negocio que se corresponden con los procesos
del negocio y los clientes respectivamente.

Casos de uso del negocio Procesos del negocio

Actores del negocio Clientes

El modelo de casos de uso de negocio presenta un sistema al igual que un modelo de casos
de uso para un sistema software.
Un modelo de objetos del negocio es un modelo interno a un negocio, describe como cada
caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores que
utilizan un conjunto de entidades del negocio (representa algo que los trabajadores utilizan
en un caso de uso de negocio) y de unidades de trabajo (conjunto de entidades que
conforma un todo reconocible para un usuario final).
Cada trabajador, entidad del negocio y unidad de trabajo puede participar en la realización
de más de un caso de uso de negocio.
Ejemplo: Modelado de negocio para la descripción del proceso unificado
- Trabajadores: analista y especificadotes de casos de uso.
- Entidades del negocio: artefactos como casos de uso y casos de prueba.

- Unidades de trabajo: artefactos como el modelo de casos de uso y la descripción de la

arquitectura.

Ing. Consuelo Del Castillo Castro 31

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO IV

Captura de Requisitos: Casos de uso

Ing. Consuelo Del Castillo Castro 32

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Los requisitos funcionales se estructuran de forma natural mediante casos de uso, la mayoría
de los otros requisitos no funcionales son especificados en un solo caso de uso.
Los requisitos un funcionales restantes (comunes para muchos otros) se mantiene aparte y se
denominan Requisitos adicionales.
Los casos de usos proporcionan un medio intuitivo y sistemático para capturar los requisitos
funcionales.
El flujo de trabajo de los requisitos se describe en tres pasos:
- Artefactos.
- Trabajadores.
- Actividades detalladas en el flujo de trabajo de captura de requisitos.

Trabajadores y artefactos implicados:

Analista de sistema Modelo de casos de uso

Actor

Glosario

Ing. Consuelo Del Castillo Castro 33

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Especificador de casos de uso Caso de uso

Diseñador de interfaz de usuario Prototipo de interfaz de usuario

Arquitecto Descripción de arquitectura

4.1 ARTEFACTOS
El artefacto fundamental es el modelo de casos de uso (casos de uso y actores).
Modelo de casos de uso:
- Permite que desarrolladores y clientes lleguen a un acuerdo sobre los requisitos
(condiciones y posibilidades que debe cumplir el sistema).
- Contiene actores, casos de uso y relaciones.
Puede ser útil introducir paquetes para tratar su tamaño.

Modelo de casos de uso Sistema de casos de uso

Actor Caso de uso

Actor:
- El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario.
- Los sistemas externos se representan como actores, dispositivos externos.
- Representan terceros fuera del sistema que colaboran con el sistema.

Ing. Consuelo Del Castillo Castro 34

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Identificados todos los actores se habrá identificado el entorno externo al sistema.

- Suele corresponderse con trabajadores (o actores de negocio) en un negocio.

Casos de uso:
- Forma en que los actores usan el sistema.
- Fragmentos de la funcionalidad del sistema.
- Especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando
con sus actores.
- Un caso de uso es un clasificador (tiene atributos y operaciones)
- Una descripción de un caso de uso puede incluir un diagrama de estados., un diagrama
de actividad, colaboraciones y secuencias.
- Una instancia de un caso de uso es la realización de un caso de uso.
- Se realiza:
o Un flujo de sucesos: descripción textual de la secuencia de acciones del caso de
uso.
o Requisitos especiales: requisitos no funcionales relacionados con el caso de uso
y que deben tratarse en flujos de trabajo posteriores como análisis, diseño, etc.

Descripción de la arquitectura:(Vista del modelo de casos de uso)

Representa los casos de uso significativos para la arquitectura. Incluye los casos de uso que
describan alguna funcionalidad importante y crítica, o que implique algún requisito importante
que deba desarrollarse pronto dentro del ciclo de vida del software.

Glosario:
Define términos comunes importantes que los analistas utilizan para describir el sistema.
Consenso entre desarrolladores relativo a la definición de los diversos conceptos y nociones.
Reduce el riesgo de confusiones. Habitualmente lo podemos obtener de un modelo de negocios
o de un modelo de dominio.

Prototipo de interfaz de usuario:

Nos ayudan a comprender y especificar las interacciones entre actores humanos y el sistema
durante la captura de requisitos. Nos ayuda a desarrollar una interfaz grafica mejor y
comprender mejor los casos de uso.

Ing. Consuelo Del Castillo Castro 35

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

4.2 TRABAJADORES

Analista de sistemas: Responsable del conjunto de requisitos que están modelados en los casos
de uso, incluye todos los requisitos funcionales y no funcionales que son casos de uso
específicos. Delimita el sistema encontrando los actores y casos de uso y asegurando que el
modelo es completo y consistente. Puede utilizar el glosario. Dirige el modelado y coordina
con el especificador de casos de uso la captura de requisitos.

Especificador de casos de uso: Descripciones detalladas de uno o mas casos de uso. Trabaja
estrechamente con los usuarios reales de sus casos de uso.

Diseñador de interfaz de usuario: Dan forma visual a las interfaces de usuario. Puede implicar
el desarrollo de prototipos de interfaces para algunos casos de uso. No es la implementación
real de la interfaz de usuario. La implementación real la hacen los desarrolladores durante los
flujos de trabajo de diseño e implementación.

Arquitecto: Describe la vista de la arquitectura del modelo de casos de uso, entrada importante
para la planificación de las iteraciones (Priorizar casos de uso).

4.3 FLUJO DE TRABAJO

Analista de sistemas Encontrar actores y Estructurar el modelo

casos de uso de casos de uso

Arquitecto: Priorizar los casos de uso

Especificador de casos de uso: Detallar un caso de uso

Diseñador de interfaces de usuario: Prototipar la interfaz de

usuario

Encontrar actores y casos de uso

Ing. Consuelo Del Castillo Castro 36

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Delimita el sistema de su entorno

- Esboza quién y qué actores interactúan con el sistema y que funcionalidad se espera del
sistema.
- Captura y define un glosario de términos.
Esta actividad consta de 4 pasos:
1. Encontrar actores
2. Encontrar casos de uso
3. Describir brevemente cada caso de uso
4. Describir el modelo de caos de uso completo (incluye la preparación de un glosario de
términos)
Priorizar casos de uso
Proporciona entradas a la priorización de los casos de uso para determinar cuales son necesarios
para el desarrollo en las primeras iteraciones y cuáles pueden dejarse para más tarde. Los
resultados se recogen de la vista de la arquitectura del modelo de casos de uso.

Detallar un caso de uso

Describe su flujo de sucesos en detalle de cada caso de uso incluyendo como comienza, termina
e interactúa con los actores. Cada especificador de casos de uso debe trabajar estrechamente
con los usuarios reales de los casos de uso, para ello necesita entrevistarse con los usuarios,
anotar su comprensión y discutir propuestas con ellos y solicitar que revisen la descripción de
los casos de uso.
¿Qué incluir en una descripción de caso de uso?
- Estado inicia como precondición.
- Cómo y cuándo comienza el caso de uso.
- Orden requerido en que las acciones deben ejecutarse.
- Cómo y cuándo terminan los casos de uso.
- Los caminos de ejecución que no están permitidos.
- Las descripciones de caminos alternativos incluidos en las descripciones del camino
básico.
- Las descripciones de caminos alternativos que han sido extraídos de la descripción del
camino básico.
- La interacción del sistema con los actores y que cambios producen.
- La utilización de objetos, valores y recursos del sistema.

Ing. Consuelo Del Castillo Castro 37

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Describir explícitamente que hace el sistema (acciones que ejecuta).

Los atributos de los casos de uso pueden utilizarse como inspiración para encontrar clases y
atributos en el análisis y diseño.

Pueden utilizarse:
- Diagramas de estado. Para describir estados de los casos de uso y transiciones entre sus
estados.
- Diagramas de actividad: describe transiciones entre estados con más detalles como
secuencias de acciones.
- Diagramas de interacción: para describir como interactúa una instancia de caso de uso
con la instancia de un actor.

Prototipar la interfaz de usuario

Consiste en construir un prototipo de interfaz de usuario. Hacemos un diseño lógico de la
interfaz de usuario, después se crea el diseño físico y desarrollan los prototipos que ilustren
como pueden utilizar el sistema los usuarios para ejecutar los casos de uso.
Los actores interactúan con el sistema, utilizarán y manipularán elementos de interfaces de
usuario que representan atributos de los casos de uso. El diseñador de interfaces de usuario
identifica y especifica estos elementos actor por actor, recorriendo todos los casos de uso a los
que el actor pude acceder.
Estos prototipos pueden construirse con una herramienta de prototipazo rápido. Puede haber
varios prototipos, quizá uno para cada actor, para verificar que cada actor puede ejecutar el
caso de uso que necesita. Desarrollamos prototipos ejecutables de IGU cuando tenemos mucho
que ganar en facilidad de uso y utilizamos bocetos en papel cuando no tengamos tanto que
ganar. Se debe verificar que cada interfaz de usuario permita:
- que el actor navegue en forma adecuada.
- Proporcionar una apariencia agradable y una forma consistente de trabajo.
- Cumplir con estándares relevantes de diseño.

Estructurar el modelo de casos de uso

El modelo de casos de uso se estructura para:
- Extraer descripciones de la funcionalidad general y compartida que pueden ser
utilizados por descripciones. Ir buscando acciones o partes de acciones comunes o

Ing. Consuelo Del Castillo Castro 38

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

compartidas por varios casos de uso con el fin de reducir la redundancia. Se muestra la
relación de reutilización mediante una generalización llamada Relación de Uso.
- Extraer descripciones de la funcionalidad adicional u opcional que pueden extraer
descripciones. Relación de extensión. Modela la adición de una secuencia de acciones
a un caso de uso. Algo que se añade a la descripción original de un caso de uso.
* Existen otras relaciones entre casos de uso que son las relaciones de incluye, relación
inversa a la de extensión. Extensión explícita e incondicional a un caso de uso. La secuencia
de comportamiento y los atributos de casos de uso se encapsulan y no pueden modificarse
o accederse, solamente puede utilizarse el resultado de un caso de uso incluido. Diferencia
en comparación con la utilización de relaciones de generalización.

Ing. Consuelo Del Castillo Castro 39

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO V

Análisis

Ing. Consuelo Del Castillo Castro 40

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

En la etapa de análisis nos encargamos de analizar los requisitos que se descubrieron en la

captura de requisitos, refinándolos estructurándolos. Su objetivo es obtener una comprensión
más precisa de los requisitos y una descripción de los mismos, que sea fácil de mantener y
ayude a estructurar el sistema entero.

En la captura de requisitos se utiliza lenguaje de cliente, es probable que queden aspectos sin
resolver relativos a los requisitos del sistema, debido al uso del lenguaje intuitivo pero
impreciso del cliente durante la captura de requisitos.

Para comunicar de manera eficiente las funciones del sistema al cliente:

- Los casos de uso deben mantenerse tan independientes unos de otros como sea posible.
- Los casos de uso deben describirse utilizando el lenguaje de cliente.
- Debe estructurarse cada caso de uso para que forme una especificación de funcionalidad
completa e intuitiva. Estructurar los casos de uso de manera que reflejen intuitivamente
los casos de uso.

El propósito fundamental del análisis es resolverlos analizando los requisitos con mayor
profundidad pero utilizando el lenguaje de desarrolladores para describir los resultados. En el
análisis podemos razonar más sobre los aspectos internos del sistema y resolver aspectos
relativos a la interferencia de casos de uso. En el análisis podemos estructurar los requisitos
facilitando su comprensión, preparación, modificación y su mantenimiento en general. Esta
estructurada (basada en clases de análisis y paquetes) es independiente de la estructura que se
dio a los requisitos (basada en casos de uso).

Comparación del modelo de casos de uso con el modelo de análisis:

Modelo de casos de uso Modelo de análisis

- Descrito en lenguaje de cliente - Descrito en lenguaje de desarrolladores
- Vista externa del sistema - Vista interna del sistema
- Estructurado por casos de uso - Estructurado por clases y paquetes
estereotipadas

Ing. Consuelo Del Castillo Castro 41

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Contrato entre el cliente y desarrolladores - Utilizado para comprender como debería

de Que debería y que no debería hacer el darse forma al sistema, como debería ser
sistema diseñado e implementado
- No debería contener redundancias e
- Puede contener redundancias e inconsistencias entre requisitos
inconsistencias entre requisitos - Esboza como llevar a cabo la funcionalidad
- Captura la funcionalidad del sistema dentro del sistema
significativa para la arquitectura - Define realizaciones de casos de uso que
- Define casos de uso que se analizarán con representan el análisis de un caso de uso del
mas profundidad en el modelo de análisis modelo de casos de uso

El lenguaje que utilizamos en el análisis se basa en un modelo de objetos conceptual (modelo

de análisis). El modelo de análisis nos ayuda a refinar los requisitos y nos permite razonar sobre
aspectos internos del sistema (incluidos los recursos internos del sistema representados como
objetos en el modelo de análisis). El modelo de análisis nos ayuda a estructurar los requisitos
proporcionando una estructura centrada en el mantenimiento, flexibilidad ante los cambios y la
reutilización. Esta estructura se utiliza como entrada en las actividades de diseño e
implementación.
El modelo de análisis hace abstracciones y evita resolver algunos problemas y tratar algunos
requisitos que pensamos que es mejor posponer al diseño y a la implementación. Puede
conseguirse una mejor arquitectura mediante la modificación de la estructura del modelo de
análisis durante la transición al modelo de diseño, al ir dando la forma al sistema.

El diseño y la implementación son mucho más que el análisis. El análisis es el refinamiento y

estructuración de los requisitos. En el diseño debemos moldear el sistema y encontrar su forma,
incluyendo su arquitectura, de forma que de vida a todos los requisitos incorporados. El diseño
y la implementación se preocupan en realidad de dar forma al sistema de manera que dé vida
a todos los requisitos, incluidos todos los requisitos no funcionales, que incorpora.

Trabajadores y artefactos implicados:

Ing. Consuelo Del Castillo Castro 42

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Arquitecto Modelo de análisis

-------
-------
-------

Desc. de arquitectura

Ingeniero de casos de uso Realización de casos de uso - análisis

Ingeniero de componentes Clases de análisis

Paquetes de análisis

Importancia del modelo de análisis:

- Ofrece una especificación mas precisa.
- Se describe utilizando el lenguaje de los desarrolladores.
- Estructura los requisitos de modo que facilita su comprensión.

Ing. Consuelo Del Castillo Castro 43

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Puede considerarse como una primera aproximación al modelo de diseño -> entrada
fundamental cuando se da forma al sistema en el diseño y en la implementación.

Cuándo utilizar el análisis y cómo explotar su resultado:

- Realización separada del análisis, en lugar de llevarlo a cabo como parte integrado en
el diseño y la implementación.
- Proporciona una visión general del sistema (contiene demasiados detalles), que puede
ser mas difícil de obtener mediante el estudio de los resultados del diseño y la
implementación.
- Algunas partes del sistema tienen diseños y/o implementaciones alternativas. Ejm.
Sistemas críticos pueden constar de varios programas distintos.
- El sistema se construye utilizando un sistema heredado complejo. La reingeniería puede
hacerse en términos del modelo de análisis de manera que los desarrolladores pueden
comprender el sistema heredado sin tener que profundizar en detalles de diseño e
implementación.

El análisis y el ciclo de vida:

Las iteraciones iniciales de la elaboración se centran en el análisis obteniendo una arquitectura
estable y sólida, facilitando una comprensión en profundidad de los requisitos.

5.1 ARTEFACTOS

Modelo de análisis:
El modelo de análisis se representa mediante un sistema de análisis que denota el paquete de
más alto nivel del modelo. Para organizar el modelo de análisis en partes manejables podemos
utilizar paquetes de análisis que representan abstracciones de subsistemas y posiblemente capas
completas de diseño del sistema. Las clases de análisis representan abstracciones de clases y
posiblemente de subsistemas del diseño del sistema.

Ing. Consuelo Del Castillo Castro 44

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

1 *

Modelo de Análisis Sistema de análisis Paquete del análisis

* * * *

Clase del análisis Realizaciones de casos

de uso-análisis

Clase del análisis:

Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del
diseño del sistema. Características:
- Se centra en el tratamiento de los requisitos funcionales y pospone los no funcionales.
- Es más evidente en el contexto del dominio del problema.
- Raramente define u ofrece un interfaz en términos de operaciones y de sus signaturas.
Su comportamiento se define mediante responsabilidades (descripción textual de un
conjunto cohesivo del comportamiento de una clase) en un nivel más alto y menos
formal.
- Define atributos de nivel bastante alto. Los tipos de estos atributos son conceptuales y
reconocibles en el dominio del problema.
- Participa en relaciones (más conceptuales). Ejm. La navegabilidad no es muy
importante en el análisis.
- Siempre encajan en uno de tres estereotipos básicos:
o De interfaz
o De control
o De entidad

Clases de Interfaz:
Se utilizan para modelar la interacción entre el sistema y sus actores (usuarios y sistemas
externos). Implica recibir y presentar información y peticiones de y hacia los usuarios
y los sistemas externos. Modelan las partes del sistema que dependen de sus actores.
Representan a menudo abstracciones de ventanas, formularios, paneles, interfaces de

Ing. Consuelo Del Castillo Castro 45

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

comunicaciones, interfaces de impresoras, sensores, terminales y API. Deberían

mantener un nivel alto y conceptual. No es necesario describir como se ejecuta
físicamente la interacción. Cada clase Interfaz debe asociarse al menos con al menos
una actor y viceversa.

Clase Interfaz Clase Interfaz

Ejemplo:

Clases de entidad:
Se utilizan para modelar información que posee una vida larga y que es a menudo
persistente. Modelan la información y el comportamiento asociado de algún fenómeno
o concepto, ejm. Una persona, un objeto del mundo real o un suceso del mundo real.
Las clases de entidad se derivan directamente de una clase de entidad de negocio (o de
una clase del dominio) correspondiente tomada del modelo de objetos de negocio.
Una diferencia entre las clases de entidad y las clases de entidad del negocio es que las
primeras representan objetos manejados por el sistema, mientras que las otras
representan objetos presentes en el negocio en general.
Suelen mostrar una estructura de datos lógica y contribuyen a comprender de qué
información depende el sistema.

Clase Entidad Clase Entidad

Ing. Consuelo Del Castillo Castro 46

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Clases de control:
Representan coordinación, secuencia, transacciones y control de otros objetos. Se usan
con frecuencia para encapsular el control de un caso de uso concreto. Se utilizan para
representar derivaciones y cálculos complejos como la lógica de negocio que no puede
asociarse a ninguna información concreta, de larga duración, almacenada por el sistema.
Los aspectos dinámicos del sistema se modelan con clases de control (manejan y
coordinan acciones y flujos de control principales).
Las clases control no encapsulan aspectos relacionados con las interacciones, con los
actores, ni aspectos relacionados con información de larga vida. Las clases de control
encapsulan los cambios de control, la coordinación, la secuencia, las transacciones y a
veces la lógica del negocio compleja que implica a varios objetos.

Clase Control Clase Control

Ing. Consuelo Del Castillo Castro 47

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Realización de casos de uso de análisis:

Es una colaboración dentro del modelo de análisis que describe como se lleva a cabo y se ejecuta
un caso de uso en términos de las clases del análisis y de sus objetos del análisis en interacción.

Una realización de casos de uso de análisis posee una descripción textual del flujo de sucesos,
diagramas de clases que muestran sus clases del análisis participante y diagramas de interacción
que muestran la realización de un flujo o escenario particular de casos de uso en términos de
interacciones de objetos de análisis. Se centra de manera natura en los requisitos funcionales.

En el análisis es preferible mostrar las realizaciones con diagramas de colaboración, ya que el

objetivo fundamental es identificar requisitos y responsabilidades sobre los objetos, y no
identificar secuencias de interacción detalladas y ordenadas cronológicamente.

Los requisitos especiales son descripciones textuales que recogen todos los requisitos no
funcionales sobre una realización de casos de uso.

Paquete de análisis:
Proporcionan un medio para organizar los artefactos del modelo de análisis en piezas
manejables. Puede constar de clases de análisis, de realizaciones de casos de uso de análisis y
otros paquetes de análisis recursivamente.
Características de los paquetes de análisis:
- Pueden representar una separación de interese de análisis.

Ing. Consuelo Del Castillo Castro 48

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Deberían crearse basándonos en los requisitos funcionales y en el dominio del problema,

reconocibles por las personas. No debería basarse en requisitos no funcionales o en el
dominio de la solución.
- Probablemente se convertirán en subsistemas posteriormente.

Paquete de servicio
Todo sistema debe proporcionar un conjunto de servicios a sus clientes además de casos de
uso a sus actores. Un caso de uso representa una secuencia de acciones, un servicio
representa un conjunto coherente de acciones relacionadas funcionalmente que se utiliza en
varios casos de uso. Un servicio es indivisible: el sistema necesita ofrecerlo o todo entero o
nada en absoluto. Los casos de uso son para los usuarios, los servicios son para los clientes.
Los casos de uso atraviesan los servicios, es decir, un caso de uso requiere acciones de
varios servicios.

Un paquete de servicio: contiene un conjunto de clases relacionadas funcionalmente. Se

utilizan en un nivel mas bajo de la jerarquía de paquetes de análisis. Es indivisible. Depende
a menudo de otro paquete de servicio. Pueden ser mutuamente excluyentes. Constituyen
una entrada fundamental para las actividades de diseño e implementación subsiguientes.
Son reutilizables.

Descripción de la arquitectura:
Vista de arquitectura del modelo de análisis, que muestra artefactos significativos para la
arquitectura:
- La descomposición del modelo de análisis en paquetes de análisis y sus dependencias.
- Las clases fundamentales de análisis: Clases de análisis (encapsulan un fenómeno
importante del dominio del problema), Clase de interfaz (encapsula interfaces de
comunicación importante y mecanismos de interfaz de usuarios) y Clase de control
(encapsulan importantes secuencias con una amplia cobertura). Suele ser suficiente
considerar una clase abstracta pero no sus subclases.
- Realizaciones de casos de uso que describen cierta funcionalidad importante y crítica.

Ing. Consuelo Del Castillo Castro 49

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

5.2 TRABAJADORES

Arquitecto: responsable de la integridad del modelo de análisis (correcto, consistente y legible).

No es responsable del desarrollo y mantenimiento continuo de los diferentes artefactos del
modelo de análisis.

Ingeniero de casos de uso: responsable de la integridad de una o más realizaciones de casos de

uso, garantizando que se cumplan los requisitos.

Ingeniero de componentes: define y mantiene las responsabilidades, atributos, relaciones y

requisitos especiales de una o varias clases del análisis.

5.3 FLUJOS DE TRABAJO

Arquitecto Análisis de la arquitectura

Ing. Casos de uso Analizar un caso de uso

Ing. Componentes Analizar una clase Analizar un paquete

Análisis de la arquitectura:
Su propósito es esbozar el modelo de análisis y la arquitectura mediante la identificación de
paquetes de análisis, clases de análisis evidentes y requisitos especiales comunes.
- Identificación de paquetes de análisis: se hace basándose en los requisitos funcionales
y en el dominio del problema.
- Identificación de clases de entidad obvias: las mas importantes basado en clases del
dominio o entidades de negocio.
- Identificación de requisitos especiales comunes: requisito que aparece durante el
análisis y que es importante anotar de forma que pueda ser tratado adecuadamente en
las actividades subsiguientes de diseño e implementación.

Ing. Consuelo Del Castillo Castro 50

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Analizar un caso de uso:

También llamado: refinamiento de casos de uso. Se analiza un caso de uso para:
- Identificar las clases del análisis cuyos objetos son necesarios para llevar a cabo el flujo
de sucesos del caso de uso.
- Distribuir el comportamiento del caso de uso entre los objetos del análisis que
interactúan.
- Capturar requisitos especiales sobre las realizaciones del caso de uso.

Analizar una clase:

Los objetivos son:
- Identificar y mantener las responsabilidades de una clase del análisis (considerando las
realizaciones de caso de uso)
- Identificar y mantener los atributos y relaciones de la clase del análisis.
- Capturar requisitos especiales sobre la realización de la clase del análisis.

Analizar un paquete:
Los objetivos de analizar un paquete son:
- Garantizar que el paquete del análisis es tan independiente de otros paquetes.
- Garantizar que el paquete del análisis cumple su objetivo de realizar algunas clases del
dominio o casos de uso.
- Describir las dependencias de forma que pueda estimarse el efecto de cambios futuros.

Ing. Consuelo Del Castillo Castro 51

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO VI

Diseño

Ing. Consuelo Del Castillo Castro 52

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

En el diseño: Modelamos el sistema y encontramos su forma de manera que soporte todos los
requisitos (incluidos los no funcionales y restricciones). El resultado del análisis es una entrada
fundamental al diseño.
Se dice que el modelo de análisis proporciona una comprensión detallada de los requisitos e
impone una estructura del sistema que debemos esbozar lo mas fielmente posible cuando le
damos forma al sistema.
Los propósitos del diseño son:
- Adquirir una comprensión en profundidad de los aspectos relacionados con los
requisitos no funcionales y restricciones relacionados con los lenguajes de
programación.
- Crear una entrada apropiada y un punto de partido para actividades de implementación
subsiguientes, capturando los requisitos o subsistemas individuales, interfaces y clases.
- Descomponer los trabajos de implementación en parte mas manejables que puedan ser
llevadas a cabo por diferentes equipos de desarrollo.

Comparación entre el modelo de análisis y el modelo de diseño:

Modelo de análisis Modelo de diseño

- Modelo conceptual (abstracción del - Modelo físico (es un plano de la
sistema, permite aspectos de implementación).
implementación). - No genérico, específico para una
- Genérico respecto al diseño. implementación.
- Cualquier número de estereotipos (físicos)
- Tres estereotipos conceptuales sobre las sobre las clases.
clases: Control, Entidad e Interfaz - Más formal.
- Menos formal. - Más caro.
- Menos caro. - Más capas.
- Menos capas. - Dinámico: muy centrado en las secuencias.
- Dinámico: no muy centrado en la - Manifiesto del diseño del sistema.
secuencia. - “Programación visual”
- Bosquejo del diseño del sistema. - Debe ser mantenido durante todo el ciclo de
- “Trabajo de a pie”. vida del software.

Ing. Consuelo Del Castillo Castro 53

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Puede no estar mantenido durante todo el - Da forma al sistema (al momento de

ciclo de vida del software. preservar la estructura definida en el
- Define una estructura que en una entrada modelo de análisis).
esencial para modelar el sistema.

Trabajadores y artefactos implicados:

Arquitecto Modelo de diseño

-------
-------
-------

Desc. de la arquitectura

Modelo de desarrollo

Ingeniero de casos de uso Realización de casos de uso - diseño

Ing. Consuelo Del Castillo Castro 54

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Ingeniero de componentes Clases del diseño

Subsistema de diseño

Interfaz

El diseño se ubica al final de la fase de elaboración y comienzo de las iteraciones de

construcción, contribuyendo a una arquitectura estable, sólida y crear un plano del modelo de
implementación.
El modelo de diseño está muy cercano al de la implementación, especialmente en la ingeniería
de ida y vuelta, donde el modelo de diseño puede utilizarse para visualizar la implementación
y para soportar las técnicas de programación gráfica.

6.1 ARTEFACTOS

Modelo de diseño: es un modelo de objetos que describe la realización física de los casos de
uso centrándose en como los requisitos funcionales y no funcionales junto a las restricciones
tienen impacto en el sistema a considerar. El modelo de diseño sirve de abstracción de la
implementación del sistema.
Los subsistemas de diseño y clases del diseño representan abstracciones del subsistema y
componentes de la implementación del sistema. En el modelo de diseño los casos de uso son
realizados por las clases de diseño y sus objetos. La realización de casos de uso de diseño es
diferente a la realización de casos de uso de análisis, en la de diseño se describe como se realiza

Ing. Consuelo Del Castillo Castro 55

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

un caso de uso en términos de interacciones entre objetos del diseño, y el la de análisis se

describe como se realiza un caso de uso en términos de interacción entre objetos del análisis.

1 * *

Modelo de Diseño Sistema de diseño Subsistema de diseño

*
* * * * *

Clases del diseño Realizaciones de casos Interfaz

de uso-diseño

Clase del diseño: Es una abstracción sin costuras de una clase o construcción similar en l
implementación del sistema. Nos referimos al término “sin costuras” por:
 El lenguaje utilizado para especificar una clase del diseño es lo mismo que el lenguaje de
programación.
 Se especifica con frecuencia la visibilidad de los atributos y las operaciones de una clase de
diseño.
 Las relaciones de las clases de diseño implicadas con otras clases tienen un significado directo
cuando la clase es implementada. Ejm. La generalización (Herencia al momento de
programar).
 Los métodos o realizaciones de operaciones de una clase del diseño corresponden
directamente al método en las implementaciones de las clases (código).
 Una clase de diseño puede posponer el manejo de algunos requisitos para subsiguientes
actividades de implementación, para ello se indican como requisitos de implementación de
la clase.
 Una clase de diseño aparece como un estereotipo sin costuras correspondiéndose con una
construcción en el lenguaje de programación.
 Una clase de diseño puede realizar interfaces si tiene sentido hacerlo en el lenguaje de
programación.
 Una clase de diseño puede activarse, implicando que objetos de la clase mantengan su propio
hilo de control y se ejecuten concurrentemente con otros objetos activos.

Ing. Consuelo Del Castillo Castro 56

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Realización de caso de uso – diseño: Es una colaboración en el modelo de diseño que describe
como se realiza un caso de uso específico y como se ejecuta en términos de clases de diseño y
sus objetos. Proporciona una traza directa a una realización de caso de uso – análisis en el
modelo de análisis.

Modelo de análisis Modelo de diseño

<< trace >>

Realización caso Realización caso

de uso – análisis de uso - diseño

Una realización de caso de uso – diseño tiene:

- Una descripción de flujo de eventos textual. Descripción textual que explica y
complementa a los diagramas y a sus etiquetas. El texto debe redactarse en términos de
objetos o en términos de os subsistemas que participan en él.
- Diagramas de clases que muestran sus clases de diseño participantes.
- Diagramas de interacción que muestran la realización de un flujo o escenario concreto
de un caso de uso en términos de interacción entre objetos del diseño.
- Si fuera necesario: mostrar los subsistemas e interfaces implicados en la realización de
casos de uso.
Una realización de casos de uso – diseño proporciona una realización física de la realización de
caso de uso – análisis para la que es trazado. Gestiona muchos requisitos no funcionales
(requisitos especiales) capturados en las realizaciones de casos de uso – análisis.

Los requisitos de implementación son una descripción textual que recoge requisitos, tales como
los requisitos no funcionales sobre una realización de caso de uso. Son requisitos capturados en
la fase de diseño pero que es mejor tratar en la implementación.

Subsistema de diseño: son una forma de organizar los artefactos del modelo de diseño en
piezas más manejables. Puede constar de clases del diseño, realizaciones de casos de uso,

Ing. Consuelo Del Castillo Castro 57

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

interfaces y otros subsistemas. Un subsistema puede proporcionar interfaces que representan la

funcionalidad que exportan en términos de operaciones.
Un subsistema debería ser cohesivo (contenidos fuertemente asociados), débilmente acoplados
(sus dependencias deberían ser mínimas).
Características de un subsistema de diseño:
 Pueden representar una separación de aspectos del diseño.
 Las dos capas de aplicación de más alto nivel y sus subsistemas dentro del modelo de
diseño suelen tener trazas directas hacia paquetes y/o clases del análisis.
 Pueden representar componentes de grano grueso en la implementación.
 Pueden representar productos software reutilizados que han sido encapsulados en ellos.
 Pueden representar sistemas heredados (o parte de ellos) encapsulados.

Subsistemas de servicio: se utilizan en un nivel inferior en la jerarquía de subsistemas de

diseño para prepararnos para los cambios en servicios individuales. La identificación de
subsistemas de servicio se basa en los paquetes de servicio del modelo de análisis. Son más
comunes en las dos capas superiores (capa específica y general de la aplicación).

Interfaz: se utilizan para especificar las operaciones que proporcionan las clases y los
subsistemas del diseño. Constituye una forma de separar la especificación de la funcionalidad.

* realiza
Clase de diseño

* realiza
Interfaz
Subsistema de diseño

Descripción de la arquitectura: (Vista del modelo de diseño) contiene una vista de la

arquitectura del modelo de diseño que muestra sus artefactos relevantes para la arquitectura. Se
consideran significativos para la arquitectura:
- La descomposición del modelo de diseño en subsistemas, sus interfaces y las
dependencias entre ellos.
- Clases del diseño fundamentales.

Ing. Consuelo Del Castillo Castro 58

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

- Realizaciones de caso de uso – diseño que describan alguna funcionalidad importante y

crítica que debe desarrollarse dentro del ciclo de vida de software.

Modelo de despliegue: es un modelo de objetos que describe la distribución física del sistema
en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo. Este modelo
se utiliza como entrada fundamental en las actividades de diseño e implementación debido a
que la distribución del sistema tiene una influencia principal en su diseño. Considerar:
- Cada nodo representa un recurso de cómputo (un procesador o dispositivo hardware
similar).
- Los nodos poseen relaciones que representan medios de comunicación entre ellos:
Internet, intranet, bus y similares.
- El modelo de despliegue puede describir diferentes configuraciones de red.
- La funcionalidad de un nodo se define por los componentes distribuidos en el nodo.
- El modelo de despliegue representa una correspondencia entre la arquitectura software
y la arquitectura del sistema.

Descripción de la arquitectura: (Vista del modelo de despliegue) Deberían mostrarse todos

los aspectos del modelo de despliegue en la vista arquitectónica, incluyendo la correspondencia
de los componentes sobre los nodos. Abarca los nodos que forman la topología hardware sobre
la que se ejecuta el sistema, aborda la distribución, entrega e instalación de las partes que
constituyen el sistema físico.

6.2 TRABAJADORES

Arquitecto: responsable de la integridad de los modelos de diseño y de despliegue, garantizando

los modelos correctos consistentes y legibles en su totalidad. También es responsable de la
arquitectura de los modelos de diseño y despliegue (existencias de las partes significativas). No
es responsable del desarrollo y mantenimiento.

Ingeniero de casos de uso: es responsable de la integridad de una o más realizaciones de casos

de uso – diseño y garantizar que cumplan los requisitos que se esperan de ellos. No es
responsable de las clases, subsistemas, interfaces y relaciones de diseño.

Ing. Consuelo Del Castillo Castro 59

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Ingeniero de componentes: define y mantiene las operaciones, métodos, atributos, relaciones

y requisitos de implementación de una o más clases del diseño, garantizando que cada clase de
diseño cumpla con los requisitos. Puede mantener la integridad de uno o más subsistemas.

6.3 FLUJOS DE TRABAJO

Arquitecto Diseño de la arquitectura

Ing. Casos de uso Diseñar un caso de uso

Ing. Componentes Diseñar una clase Diseñar un subsistema

Diseño de la arquitectura:
El objetivo es esbozar los modelos de diseño y despliegue y su arquitectura mediante la
identificación de los siguientes elementos:
- Nodos y sus configuraciones de red.
- Subsistemas y sus interfaces.
- Clases del diseño significativas para la arquitectura, como las clases activas.
- Mecanismos de diseño genéricos que tratan requisitos comunes (requisitos especiales
como: persistencias, distribución, rendimiento y otros).

Diseñar un caso de uso:

Los objetivos del diseño de n caso de uso son:
- Identificar las clases del diseño y/o subsistemas cuyas instancias son necesarias para
llevar a cabo el flujo de sucesos del caso de uso.
- Distribuir el comportamiento del caso de uso entre los objetos del diseño que interactúan
y/o entre os subsistemas participantes.
- Definir los requisitos sobre las operaciones de las clases del diseño y/o sobre los
subsistemas y sus interfaces.
- Capturar los requisitos de implementación de los casos de uso.

Ing. Consuelo Del Castillo Castro 60

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Diseñar una clase:

El propósito es crear una clase del diseño que cumpla su papel en las realizaciones de los casos
de uso y los requisitos no funcionales que se aplican a estos. Incluye el mantenimiento del
diseño de clases y aspectos como:
- Sus operaciones.
- Sus atributos.
- Las relaciones en las que participa.
- Sus métodos (que realizan sus operaciones).
- Los estados impuestos.
- Sus dependencias con cualquier mecanismo del diseño genérico.
- Los requisitos relevantes a su implementación.
- La correcta realización de cualquier interfaz requerida.

Diseñar un subsistema:
Los objetivos del diseño del subsistema son:
- Garantizar que el subsistema es tan independiente como sea posible de otros
subsistemas y/o de sus interfaces.
- Garantizar que el subsistema proporcione las interfaces correctas.
- Garantizar que el subsistema cumpla su propósito de ofrecer una realización correcta
de las operaciones tal y como se definen en las interfaces que proporciona.

Ing. Consuelo Del Castillo Castro 61

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO VII

Implementación

Ing. Consuelo Del Castillo Castro 62

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Recibe como entrada el resultado del diseño e implementamos el sistema en términos de

componentes, esto quiere decir ficheros de códigos fuente, scripts, ficheros de código binario,
eyectables, etc.

La mayor parte de la arquitectura del sistema es capturada durante el diseño, siendo el propósito
fundamental el desarrollar la arquitectura y el sistema como un todo. Los propósitos de la
implementación son:
- Planificar las integraciones del sistema.
- Distribuir el sistema asignando componentes ejecutables.
- Implementar las clases y subsistemas encontrados durante el diseño.
- Probar los componentes individualmente y luego integrarlos compilándolos y
enlazándolos en uno o mas ejecutables.

Trabajadores y artefactos implicados:

Arquitecto Modelo de implementación

-------
-------
-------

Desc. de la arquitectura

Modelo de despliegue

Ing. Consuelo Del Castillo Castro 63

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

-------
-------
-------

Integrador de sistema Integración del sistema

Ingeniero de componentes Componentes Implementación de

Subsistema

Interfaz

La implementación es el centro durante las iteraciones de construcción, aunque también se lleva

a cabo trabajo de implementación durante las fases de elaboración, para crear la línea base
ejecutable de la arquitectura y durante la fase de transición, para tratar defectos tardíos como
los encontrados con distribuciones beta del sistema.

Ing. Consuelo Del Castillo Castro 64

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

7.1 ARTEFACTOS

Modelo de Implementación: Describe como los elementos de diseño, como las clases, se
implementan en términos de componentes, como ficheros de código fuente, ejecutables, etc.
Describe como se organizan los componentes de acuerdo con los mecanismos de construcción
proporcionados por el lenguaje de programación utilizado.

Ing. Consuelo Del Castillo Castro 65

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

1 * *

Modelo de Implementación Sistema de implementación Subsistema de implementación

*
* * *

Componentes Interfaz

Componente: Un componente es el empaquetamiento físico de los elementos de un modelo

(clase de diseño). Algunos estereotipos estándar de componentes son los siguientes:
- <<executable>>: programa que pueda ser ejecutada de un nodo.
- <<file>>: fichero que contiene código fuente o datos.
- <<library>>: librería estática o dinámica.
- <<table>>: tabla de base de datos.
- <<document>>: documento.

Características:
- Los componentes tienen relaciones de traza con los elementos de modelo que
implementan.
- Es normal que un componente implemente varios elementos (varias clases).
- Los componentes proporcionan las mismas interfaces que los elementos de modelo que
implementan.
- Puede haber dependencias de compilación entre componentes, denotando que
componentes son necesarios para compilar un componente determinado.

Un componente sigue una traza de una clase de diseño.

Un STUBS es un componente con una implementación esquelética o de propósito especial que

puede ser utilizada para desarrollar o probar otro componente que depende del stub. Pueden ser

Ing. Consuelo Del Castillo Castro 66

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

utilizados para minimizar el número de componentes nuevos necesarios en cada versión

intermedia del sistema, simplificando problemas de integración y pruebas de integración.
Subsistema de implementación: Puede estar formado por componentes, interfaces y otros
subsistemas. Un subsistema puede implementar las interfaces que representan la funcionalidad
que exportan e forma de operaciones.
Un subsistema de implementación se manifiesta a través de un mecanismo de
empaquetamiento, tales como:
- Un paquete en java.
- Un proyecto en Visual Basic.
- Un directorio de ficheros en un proyecto de C++.
- Un subsistema en un entorno de desarrollo integrado como Rational Apex.
- Un paquete en una herramienta de modelado visual como Rational Rose.

Los subsistemas de implementación están muy relacionados con los subsistemas de diseño en
el modelo de diseño.
Es importante recordar lo que define un subsistema de diseño que se corresponde con los
subsistemas de implementación por las siguientes razones:
- El subsistema de implementación debería definir dependencias análogas hacia otros
subsistemas de implementación o interfaces.
- El subsistema de implementación debería proporcionar las mismas interfaces.
- El subsistema de implementación debería definir que componentes o que otros
subsistemas de implementación dentro del subsistema deberían proporcionar las
interfaces proporcionadas por el sistema. Además estos componentes deben seguir la
traza de las clases.

Ing. Consuelo Del Castillo Castro 67

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Interfaz: Las interfaces se han descrito en la etapa de diseño, sin embargo estas mismas
interfaces pueden ser utilizadas en el modelo de implementación para especificar las
operaciones implementadas por componentes y subsistemas de implementación.
Un componente que implementa un interfaz ha de implementar correctamente todas las
operaciones definidas por la interfaz. Un subsistema de implementación que proporciona una
interfaz tiene también que contener componentes que proporcionen la interfaz u otros
subsistemas que proporcionen la interfaz.

Descripción de la arquitectura (vista del modelo de implementación): Los artefactos

arquitectónicamente significativos en el modelo de implementación son los siguientes:
- La descomposición del modelo de implementación en subsistemas, sus interfaces y las
dependencias entre ellos.
- Componentes clave, como los componentes que siguen la traza de las clases de diseño
significativas arquitectónicamente, los componentes ejecutables y los componentes que
son generales, centrales, que implementan mecanismos de diseño genéricos de los que
dependen muchos otros componentes.

Plan de Integración de construcciones: Es importante construir un software incrementando

en pasos manejables de forma que cada paso de lugar a pequeños problemas de integración o
prueba. El resultado de cada paso enllamado construcción que es una versión ejecutable del
sistema. Para prepararse ante el fallo de una construcción se lleva un control de versiones de
forma que se pueda volver atrás a una construcción anterior.
Los beneficios de este enfoque incremental son los siguientes:
- Se puede crear una versión ejecutable del sistema muy pronto.
- Es más fácil localizar defectos durante las pruebas de integración.
- Las pruebas de integración tienden a ser más minuciosas que las pruebas del sistema
completo porque se centran en partes más pequeñas y más manejables.
La integración incremental es para la integración del sistema lo que el desarrollo iterativo
controlado es para el desarrollo de software general. Ambos se centran en un incremento
bastante pequeño y manejable de la funcionalidad.

Ing. Consuelo Del Castillo Castro 68

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Un plan de integración de construcciones describe la secuencia de construcciones necesarias en

una iteración. Describe lo siguiente para cada construcción:
- La funcionalidad que se espera que sea implementada en dicha construcción.
- Las partes del modelo de implementación que están afectadas por la construcción.

7.2 TRABAJADORES

Arquitecto: es responsable de la integridad del modelo de implementación y asegura que el

modelo como un todo es correcto, completo y legible. El modelo es correcto cuando implementa
la funcionalidad descrita en el modelo de diseño y en los requisitos adicionales.
Es responsable de la arquitectura del modelo de implementación, es decir de la existencias de
sus partes significativas arquitectónicamente. Es responsable de la asignación de componentes
ejecutables a nodos. No es responsable del desarrollo en marcha ni del mantenimiento de los
diversos artefactos en el modelo de implementación.

Ingeniero de componentes: define y mantiene el código fuente de uno o varios componentes

garantizando que cada componente implementa la funcionalidad correcta. También mantiene
la integridad de uno o varios subsistemas de implementación. Necesita garantizar que los
contenidos de los subsistemas de implementación son correctos, que sus dependencias con otros
subsistemas o interfaces son correctas y que implementan correctamente las interfaces que
proporcionan.

Integrador de sistemas: La integración del sistema está más allá del ámbito de cada ingeniero
de componentes individual. Su responsabilidad es planificar la secuencia de construcciones
necesarias en cada integración y la integración de cada construcción cuando sus partes han sido
implementadas. La planificación da lugar a un plan de integración de construcciones.

Ing. Consuelo Del Castillo Castro 69

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

7.3 FLUJOS DE TRABAJO

Arquitecto Implementación de la Arquitectura

Integrador de Sistemas Integrar sistemas

Ing. Componentes Implementar una clase

Implementar un Subsistema Realizar Prueba Unidad

[Link]ón de la Arquitectura:
El propósito es esbozar el modelo de Implementación y su arquitectura mediante:
 La identificación de componentes significativos arquitectónicamente, tales como
componentes ejecutables.
 Asignación de componentes a los nodos en las configuraciones de redes relevantes.
Durante el diseño de la arquitectura se esbozan los subsistemas de diseño, sus contenidos
e interfaces. Durante la implementación de la arquitectura utilizamos subsistemas de
implementación que siguen uno a uno las trazas a estos subsistemas de diseño y
proporcionan las mismas interfaces. El reto de la implementación es crear dentro de los
subsistemas de implementación los componentes que implementan los subsistemas de
diseño correspondientes.
Durante esta actividad el arquitecto refina y actualiza la descripción de la arquitectura y las
vistas de la arquitectura de los modelos de implementación y despliegue.
Durante esta actividad realizamos las siguientes tareas:
 Identificación de los componentes significativos arquitectónicamente: no identificar
demasiados componentes en esta etapa ni ahondar en demasiados detalles, de lo
contrarios gran parte del trabajo habrá de volverse a hacer cuando se implementen
las clases. Componentes de ficheros son casi triviales. Se deberá:
 Identificar componentes ejecutables y asignación de estos a nodos: considerar
clases activas encontradas durante el diseño y asignar un componente ejecutable
para cada clase activa. Identificación de otros componentes ficheros o código
binario necesarios para crear componentes ejecutables.

Ing. Consuelo Del Castillo Castro 70

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

[Link] el Sistema:
Los objetivos de la integración del sistema son los siguientes:
 Crear un plan de integración de construcciones que describa las construcciones necesarias
en una iteración y los requisitos de cada construcción.
 Integrar cada construcción antes de que sea sometida a pruebas de integración.
 Planificación de una construcción: Planificar los contenidos de una construcción,
independiente de una construcción previa o ninguna construcción. Suponemos que
tenemos casos de uso o escenarios necesarios y otros requisitos que han de ser
implementados en la iteración actual. Considerar los siguientes criterios:
 Una construcción debe añadir funcionalidad a la construcción previa
implementando casos de uso completo o escenarios con estos.
 No debería incluir demasiados componentes nuevos o refinados, de lo contrario
puede ser muy difícil integrar la construcción.
 Una construcción debería estar basada en la construcción anterior y debería
expandirse hacia arriba y hacia los lados en la jerarquía de subsistemas. La
construcción inicial debería empezar en las capas inferiores, las construcciones
subsiguientes se expanden hacia arriba a la capa general de aplicación.
 Integración de una construcción: Se recopila las versiones correctas de los
subsistemas de implementación y de los componentes, compilándolos y
enlazándolos para generar una construcción. De existir dependencias de
compilación entre capas es necesario que la compilación se realice de abajo hacia
arriba en la jerarquía de capas.

[Link] un subsistema:
Asegurar que un subsistema cumpla su papel en cada construcción, tal como se especifica
en el plan de construcción, asegurar que los requisitos implementados en la construcción y
aquellos que afectan al subsistema sean implementados correctamente por componentes o
por otros subsistemas dentro del subsistema. Para ello habrá que hacer:
 Mantenimientos de los contenidos de los subsistemas

[Link] una clase:

Ing. Consuelo Del Castillo Castro 71

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Implementar una clase de diseño en un componente fichero. Incluye:

 Esbozo de un componente fichero que contendrá el código fuente.
 Generación de código fuente a partir de la clase de diseño y de las relaciones en las que
participa.
 Implementación de las operaciones de la clase de diseño en forma de métodos.
 Comprobación de que el componente proporciona las mismas interfaces que la clase de
diseño.

[Link] prueba de unidad

Probar los componentes implementados como unidades individuales. Se lleva a cabo los
siguientes tipos de prueba de unidad:
 La prueba de especificación o prueba de caja negra: verifica el comportamiento de la
unidad observable externamente.
 Prueba de estructura o prueba de caja blanca: verifica la implementación interna de la
unidad.

Ing. Consuelo Del Castillo Castro 72

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO VIII

Prueba del Sistema

Ing. Consuelo Del Castillo Castro 73

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

En este flujo verificamos el resultado de la implementación probando cada construcción,

incluyendo construcciones intermedias e internas y versiones finales del sistema antes de ser
entregados al usuario. Los objetivos que perseguimos en esta etapa son:

 Planificar las pruebas necesarias en cada iteración, incluidas las pruebas de integración
(necesarias en cada construcción dentro de la iteración) y pruebas del sistema (solo al
final de la iteración).
 Diseñar e implementar las pruebas creando los casos de prueba que especifican que
probar, creando los procedimientos de prueba, las cuales especifican con realizar las
pruebas, y componentes de prueba ejecutables para automatizar las pruebas.
 Realizar las diferentes pruebas y manejar los resultados de cada prueba
sistemáticamente.

Trabajadores y artefactos implicados:

Ingeniero de pruebas Modelo de pruebas

Caso de prueba

Procedimiento de Prueba

-------
-------
-------

Ing. Consuelo Del Castillo Castro 74

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Evaluación de prueba

-------
-------
-------

Plan de Prueba

Ingeniero de componentes Componentes de prueba

X
Ingeniero de pruebas de Integración Defecto

Ingeniero de pruebas de Sistema

Durante la fase de inicio puede hacerse parte de la planificación inicial de pruebas cuando se
define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo principalmente cuando
una construcción es sometida a pruebas de integración y de sistema. Por lo tanto, las

Ing. Consuelo Del Castillo Castro 75

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

realizaciones de prueba se centran en las iteraciones de elaboración, cuando probamos la línea

base ejecutable de la arquitectura, y de la fase de construcción, cuando el sistema está
implementado, en su mayoría. Durante la fase de transición el trabajo se centra hacia la
corrección de defectos en los primeros usos y a las pruebas de regresión. Las pruebas de
regresión crecen de forma estable a lo largo de las iteraciones, por lo tanto, en las últimas
iteraciones se requiere de gran esfuerzo en las pruebas de regresión.

El modelo de pruebas se puede mantener constante durante todo el ciclo de vida del software,
aunque cambia constantemente debido a:
- La eliminación de casos de prueba obsoletos.
- El refinamiento de algunos casos de prueba en casos de prueba de regresión.
- La creación de nuevos casos de uso para cada nueva construcción.

8.1 ARTEFACTOS

Modelo de Pruebas: Describe principalmente como se prueban los componentes ejecutables

en el modelo de implementación con pruebas de integración y de sistema. Puede describir
también como han de ser probados aspectos específicos del sistema como la consistencia de la
interfaz de usuario o si el manual de usuario cumple con su función, etc.
A continuación mostramos el modelo de pruebas y los elementos que lo conforman:

Modelo de Pruebas Sistema de pruebas Subsistema de implementación

* * *

X X
Componente Procedimiento Caso de Prueba
de prueba de prueba

Caso de Prueba: Especifica una forma de probar el sistema, incluyendo la entrada o resultado
con la que ha de probar y las condiciones bajo las que ha de probarse. Si lo llevamos a la

Ing. Consuelo Del Castillo Castro 76

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

práctica, podemos probar un requisito o colección de requisitos del sistema cuya

implementación justifica una prueba que es posible realizar y no es demasiado cara de realizar.
Por ejemplo, son casos de pruebas comunes:
- Un caso de prueba que especifique como probar un caso de uso o un escenario específico
de un caso de uso.
- Un caso de prueba que especifique como probar una realización de caso de uso - diseño
o un escenario específico para la realización.

<<trace>>
X

Caso de Uso Caso de Prueba

Se pueden especificar otros casos de prueba para probar el sistema como un todo. Por ejemplo
podemos trabajar con:
 Pruebas de Instalación: par verificar que el sistema pueda ser instalado en la plataforma
del cliente y que el sistema funcione correctamente cuando sea instalado.
 Pruebas de configuración: para verificar que el sistema funcione correctamente en
diferentes configuraciones.
 Pruebas negativas: provocar que el sistema falle para poder así revelar sus debilidades.
 Pruebas de tensión o de estrés: identifican problemas con el sistema cuando hay recursos
suficientes o cuando hay competencia por los recursos.

Procedimiento de Prueba: Especifica como realizar uno o varios casos de prueba o parte de
éstos. Por ejemplo podría ser una instrucción sobre cómo realizar un caso de prueba
manualmente o una especificación de cómo interaccionar manualmente con una herramienta de
automatización de pruebas para crear componentes ejecutables de prueba.

1..* 1..* X
X

Procedimiento de Prueba Caso de Prueba

Ing. Consuelo Del Castillo Castro 77

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Componente de Prueba: Automatiza uno o varios procedimientos de prueba o partes de ellos.

Pueden ser desarrollados utilizando un lenguaje de guiones o un lenguaje de programación o
grabados como herramientas de automatización de pruebas.

1..* 1..*
X
Componente de Prueba Procedimiento de Prueba

Plan de Prueba: Describe las estrategias, recursos y planificación de la prueba. La estrategia

de prueba incluye l definición del tipo de pruebas a realizar para cada iteración y sus objetivos,
teniendo en cuenta la cobertura de la prueba, el código necesario y el porcentaje de pruebas que
deberían ejecutarse con un resultado específico.

Defecto: Es una anomalía del sistema, como puede ser un síntoma de fallo de software o un
problema descubierto en una revisión. Un defecto puede ser utilizado para localizar cualquier
cosa que los desarrolladores necesitan registrar como síntoma de un problema en el sistema que
ellos necesitan controlar y resolver.

Evaluación de Prueba: Es una evaluación de los resultados de los esfuerzos de prueba, tales
como la cobertura del caso de prueba, cobertura del código y el estado de los defectos.

8.2 TRABAJADORES

Diseñador de Pruebas: Es el responsable de la integridad del modelo de pruebas, asegurando

que el modelo cumpla con su propósito. También planean las pruebas, lo cual significa que
deciden los objetivos de pruebas apropiados y la planificación de las pruebas. También
seleccionan y describen los casos de prueba y procedimientos de prueba correspondientes que
se necesiten y son los responsables de la evaluación de las pruebas y de sistema cuando éstas
se ejecutan.

Ing. Consuelo Del Castillo Castro 78

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Ingeniero de Componentes: Responsable de los componentes de prueba que automatizan

algunos de los procedimientos de prueba, aunque no todos pueden ser autorizados, esto debido
a que la creación de dichos componentes puede necesitar de habilidades especiales como
programador.

Ingeniero de Pruebas de Integración: Son los responsables de realizar las pruebas de

integración que se necesitan para cada construcción producida en el flujo de trabajo de la
implementación. Las pruebas de integración se realizan para verificar que los componentes
integrados en una construcción funcionan correctamente juntos, por esto, las pruebas de
integración se derivan a menudo de los casos de prueba que especifican cómo probar
realizaciones de casos de uso – diseño.
El ingeniero de pruebas de integración se encarga de documentar los defectos en los resultados
de las pruebas de integración. También prueba el resultado, es decir, una construcción, creado
por el integrador de sistemas en el flujo de trabajo de la implementación. Por esto que en
algunos proyectos se decide que estos trabajadores sean el mismo individuo o grupo de
individuos, para minimizar el solapamiento en el conocimiento necesario.

Ingeniero de Pruebas de Sistema: Responsable de realizar las pruebas de sistema necesarias

sobre una construcción que muestra el resultado de una iteración completa.
Las pruebas de sistema se llevan a cabo principalmente para verificar las interacciones sobre
los actores y el sistema, por esto, las pruebas de sistema se derivan de los casos de prueba que
especifican cómo probar los casos de uso, aplicando también otro tipo de pruebas al sistema
como un todo.
Se encarga de documentar los defectos en los resultados de las pruebas de sistema.
Debido a la naturaleza de la prueba del sistema, los individuos que actúan como ingenieros de
prueba de sistema necesitan saber mucho sobre el funcionamiento interno del sistema teniendo
familiaridad con el comportamiento observable externamente del sistema. Por tanto, algunas
pruebas pueden ser realizadas por otros miembros del proyecto, como especificadotes de casos
de uso, o incluso por personas externas del proyecto, como usuarios de versiones beta.

Ing. Consuelo Del Castillo Castro 79

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

8.3 FLUJOS DE TRABAJO

Ing. de Pruebas Planificar prueba Diseñar Prueba Evaluar Prueba

Ing. de Pruebas de Integración Realizar pruebas de integración

Ing. de Pruebas de Sistema Realizar pruebas de sistema

Ing. de Componentes Implementar Pruebas

1. Planificar Prueba:
Planificar los esfuerzos de prueba en una iteración llevando a cabo las siguientes tareas:
 Describir una estrategia de prueba
 Estimar los requisitos para el esfuerzo de la prueba: recursos humanos y sistemas
necesarios.
 Planificar el esfuerzo de la prueba
El modelo de casos de uso y los requisitos funcionales ayudan a decidir por un tipo
adecuado de prueba y estimación de esfuerzos para la realización de la prueba.

2. Diseñar Prueba: Los propósitos son los siguientes:

 Identificar y describir los casos de prueba para la construcción.
 Identificar y estructurar los procedimientos de prueba especificando cómo realizar los
casos de prueba.
Para cumplir estos propósitos se realizan las siguientes actividades:
 Diseño de los casos de prueba de integración: Los casos de prueba de integración se
utilizan para verificar que los componentes interaccionan entre si de la forma
apropiada después de haber sido integrados en la construcción. Pueden ser derivados
de la realización de los casos de uso de diseño(describen como se interaccionan las
clases y los objetos)
 Diseño de los casos de prueba del sistema: Las pruebas del sistema se usan para
probar que el sistema funcione correctamente como un todo. Cada una prueba
principalmente combinaciones de casos de uso instanciados bajo condiciones

Ing. Consuelo Del Castillo Castro 80

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

diferentes (configuraciones de hardware, niveles de carga del sistema, número de

actores y diferentes tamaños de bases de datos). Se debe dar prioridad a las
combinaciones de casos de uso que:
 Se necesite que funcione en paralelo
 Posiblemente funcionen en paralelo
 Posiblemente se influencien mutuamente si se ejecutan en paralelo
 Involucran varios procesadores
 Usan frecuentemente recursos del sistema: procesadores, procesos, base de
datos, software de comunicaciones, etc.
 Diseño de los casos de prueba de regresión: Consiste en utilizar pruebas de regresión
en construcciones subsiguientes usando algunos caos de uso de pruebas de
construcciones anteriores. No todos los casos de uso de prueba son adecuados para
pruebas de regresión. Los casos de uso seleccionados han de ser flexibles, para ser
resistentes a cambios en el software contribuyendo a la calidad del sistema.
 Identificación y estructuración de los procedimientos de prueba: Los
procedimientos de prueba deberían especificar como probar clases de un único
subsistema de servicios. La idea está en utilizar procedimientos de prueba por cada
caso de uso de prueba que se vaya a verificar. Se intenta reutilizar procedimientos
de prueba y reducir el número de estos, permitiendo a los diseñadores usar un
conjunto reducido de procedimientos de prueba con rapidez y precisión para muchos
casos de prueba.

3. Implementar Prueba:
Su propósito es automatizar los procedimientos de prueba creando componentes de prueba,
si esto es posible, ya que no todos los procedimientos de prueba pueden ser automatizados.
Los componentes de prueba son creados utilizando los procedimientos de prueba como
entrada. Los componentes de prueba usan a menudo grandes cantidades de datos de entrada
para ser probados y producen grandes cantidades de datos de salida como resultados de
prueba.

4. Realizar Pruebas de Integración:

Ing. Consuelo Del Castillo Castro 81

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Se realizan las pruebas de integración necesarias para cada una de las construcciones
creadas en una iteración y se recopilan los resultados de las pruebas. Se llevan a cabo en los
siguientes pasos:
 Realizar pruebas de integración relevantes a la construcción realizando los
procedimientos de prueba manualmente para cada caso de prueba o ejecutando
cualquier componente de prueba que automatice los procedimientos de prueba.
 Comparar los resultados de las pruebas con los resultados esperados e investigar los
resultados que no coinciden con los esperados.
 Informar de los defectos a ing. Componentes responsables de los componentes que
se creen tiene fallas.
 Informar de los defectos a los diseñadores de pruebas, los cuales usarán los defectos
para evaluar los resultados del esfuerzo de prueba.

5. Realizar Prueba del Sistema

El propósito es realizar las pruebas del sistema necesarias en cada iteración y recopilar los
resultados de las pruebas. La prueba de sistema puede empezar cuando las pruebas de
integración indican que el sistema satisface los objetivos de calidad de integración fijados
en el plan de prueba de iteración actual. Se realiza de firma análoga a la forma en que se
realiza la prueba de integración.

6. Evaluar Prueba
El propósito es evaluar los esfuerzos de prueba en una iteración. Los diseñadores de prueba
evalúan los resultados de la prueba comparando los resultados obtenidos con los objetivos
esbozados en el plan de prueba, preparando métricas que permitan determinar la calidad del
software y que cantidad de pruebas es necesarios realizar.

Ing. Consuelo Del Castillo Castro 82

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

CAPITULO IX

Aplicación del RUP

Ing. Consuelo Del Castillo Castro 83

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

Visto todo el marco teórico referente al proceso unificado de desarrollo de software – RUP y
revisando todos los artefactos, trabajadores y flujos de trabajo, en cada una de las etapas, en los
cuales debemos guiarnos para el desarrollo de sistemas, presentamos un resumen de artefactos
entregables que deberíamos elaborar y presentar como parte de cada una de las iteraciones, para
ellos hemos considerado una propuesta que abarca hasta el modelo de implementación,
planificando solo 6 iteraciones en las fases que propone el RUP. Es importante que
mencionemos que esto va a variar de acuerdo a la complejidad del sistema que estemos
desarrollando, esto incluye variar los productos entregables y la cantidad de iteraciones
planificadas.

A continuación detallamos las iteraciones y los artefactos que generaríamos como parte de cada
entregable, producto de cada iteración:

9.1 Iteración #1: Planificación del Proyecto

1. Participantes del proyecto

a. Coordinador
b. Integrantes
2. Descripción General de la Empresa
a. Descripción
b. Misión
c. Visión
3. Organización de la Empresa
a. Organigrama
b. Funciones principales de cada área
4. Análisis de Situación Tecnológica
a. Sistemas Existentes
b. Aplicativos utilizados
c. Equipos (HW)
5. Plan del Sistema propuesto
a. Problemática del área
b. Descripción del Sistema propuesto
c. Objetivos del Sistema propuesto

Ing. Consuelo Del Castillo Castro 84

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

d. Asignación de prioridades (en función a los objetivos)

e. Cronograma de desarrollo (en función de las etapas del RUP)
6. Factibilidad para el desarrollo del Proyecto
7. Glosario de Términos
8. Anexos

9.2 Iteración #2: Análisis Preliminar de Requerimientos – Modelado de Negocio

2.1) Modelado de Negocio

a) Diagrama de casos de uso de negocio
b) Por cada proceso de negocio (caso de uso de negocio) modelar:
i) Un diagrama de actividad de negocio
ii) Un diagrama de objetos de negocio
c) Modelo de dominio

9.3 Iteración #3: Análisis Preliminar de Requerimientos

3.1) Modelado de Negocio

a) Diagrama de casos de uso de negocio
b) Por cada proceso de negocio (caso de uso de negocio) modelar:
i) Un diagrama de actividad de negocio
ii) Un diagrama de objetos de negocio
c) Modelo de dominio
3.2) Modelo de Casos de Uso (Modelo de requerimientos)
a) Diagrama de casos de uso (Diagrama de casos de uso de requerimientos)
b) Por cada caso de uso modelar:
i) Plantilla de casos de uso de requerimientos
ii) Diagrama de actividad
c) Modelo de objetos (Diagrama de clases con entidades que vienen del modelo de
dominio)
3.3) Descripción de la arquitectura: Consiste en describir textualmente los casos de uso
o las funcionalidades más importantes.
3.4) Glosario

Ing. Consuelo Del Castillo Castro 85

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

9.4 Iteración #4: Análisis

4.1) Paquete de Análisis

4.2) Diagrama de Realizaciones de casos de uso análisis
4.3) Por cada Realización de casos de uso de análisis
a) Diagrama de clases de análisis
b) Diagrama de Colaboración
c) Descripción textual (plantilla de realización de casos de uso de análisis)
d) Diagrama de clases parciales
4.4) Diagrama de clases (General)
4.5) Descripción de la arquitectura: Consiste en describir textualmente las clases de
análisis más importantes.
4.6) Glosario

9.5 Iteración #5: Diseño

5.1) Subsistema de Diseño (En función a paquetes)

5.2) Diseño de Interfaces
5.3) Diagrama de Realizaciones de casos de uso diseño
5.4) Por cada Realización de casos de uso de diseño
a) Diagrama de clases de diseño
b) Diagrama de Secuencia
c) Descripción textual (plantilla de realización de casos de uso de diseño)
5.5) Diagrama de clases (General)
5.6) Diagramas de estados
5.7) Diagrama de Navegabilidad
5.8) Diagrama de Despliegue
5.9) Descripción de la arquitectura: Consiste en describir textualmente las clases de
diseño más importantes.
5.10) Diseño de la Base de datos
5.11) Glosario

Ing. Consuelo Del Castillo Castro 86

USAT – Ingeniería De Sistemas y Computación
DISEÑO DE SOFTWARE

9.6 Iteración #6: Implementación

6.1) Subsistemas de implementación

6.2) Diagrama de componentes
6.3) Descripción de la arquitectura ( implementación )
6.4) Levantamiento de Base de Datos (script de generación de base de datos)
6.5) Código de las clases del Sistema (definición y operaciones)
6.6) Código de los procedimientos principales
6.7) Código de conexión a base de datos

Ing. Consuelo Del Castillo Castro 87