El Proceso Unificado de Desarrollo de Software - Jacobson

ndice
Introduccin
Anlisis y diseo orientado a objetos
Requisitos
13. El proceso unificado de

desarrollo de software
Ingeniera del Software

Antonio Navarro
Captura de requisitos.
Papel de los requisitos.
Modelo del dominio.
Modelo del negocio.
Requisitos adicionales.

Antonio Navarro
ndice
ndice
Diseo
Captura de requisitos como casos de uso.

Normas.
Introduccin.
El papel de diseo.
Artefactos.
Anlisis
Introduccin.
El papel del anlisis.
Artefactos

Antonio Navarro
Implementacin
Introduccin.
El papel de la implementacin
Artefactos
3

Antonio Navarro
ndice
Introduccin
Prueba
Proceso de Jacobson, Booch y Rumbaugh

Los autores de UML
Introduccin.
El papel de la implementacin.
Artefactos.
- Booch: mtodo Booch.

- Rumbaugh: OMT.
- Jacobson: proceso Objectory.
Conclusiones
Tambin conocido por RUP: Rational

Unified Process
Antonio Navarro

Antonio Navarro
Introduccin
Introduccin
Modelo basado en componentes

- El sistema software est basado en componentes
software interconectados a travs de interfaces
bien definidas.
- Interfaz: coleccin de operaciones que son
utilizadas para especificar un servicio de una clase
o de un componente.

Antonio Navarro
- Componente: Una parte fsica y reemplazable de

un sistema que se ajusta a, y proporciona la
realizacin de un conjunto de interfaces.
Muy ligado a UML

Discusin: cmo diramos esto en trminos
de las capas de IS?

Antonio Navarro
Introduccin
Introduccin
Caractersticas:
Discusin: todo modelo iterativo es

incremental? Y todo incremental es
iterativo?
- Dirigido por casos de uso.

- Centrado en la arquitectura.
- Iterativo e incremental.
Requisitos
usuario
Proceso de
desarrollo de
software
Sistema
software
Un proceso de desarrollo de software

Antonio Navarro

Antonio Navarro
10
Introduccin
Introduccin
Est formado por cinco flujos de trabajo

(i.e. AEs) que se iteran:
Anlisis
Requisitos
Requisitos.
Anlisis.
Diseo.
Implementacin.
Prueba.
Prueba
Diseo
Implementacin
El proceso unificado de desarrollo

Antonio Navarro
11

Antonio Navarro
12
Introduccin
Introduccin
Cada vuelta en la espiral se denomina

iteracin
La agrupacin de iteraciones se denomina
fase
Fase de inicio
Se desarrolla una descripcin del producto
final.
Fase de elaboracin:
- Inicio.
- Elaboracin.
- Construccin.
- Transicin.
Antonio Navarro
Se especifican los casos de uso.

Se disea la arquitectura del sistema.
13

Antonio Navarro
Introduccin
14
Introduccin
Fase de construccin
Se crea el producto.
Fase de transicin
Periodo durante el cual el producto se convierte
en versin beta.
No todos los flujos de trabajo tienen el

mismo peso dentro de cada fase
Relacin entre flujos de trabajo y fases en RUP
Antonio Navarro
15

Antonio Navarro
16
Introduccin
Introduccin
Las agrupaciones de fases se denominan

ciclo
Cada ciclo concluye con una versin del
producto
Discusin: es lo mismo un ciclo RUP que
un ciclo del modelo en espiral?
Ciclos en RUP

Antonio Navarro
17
Introduccin
18
Anlisis y diseo OO
Ventajas
Exactamente, en qu consiste el anlisis y

diseo orientado a objetos?
Aunque vimos algunas definiciones,
veamos que definiciones proporciona el
Manual de Referencia de UML
Modelo de proceso racional.

Tecnologas de componentes.
Inconvenientes
Muy ligado al mtodo.
No incluye explcitamente actividades de
gestin.
Antonio Navarro

Antonio Navarro
19

Antonio Navarro
20
Anlisis y diseo OO
Anlisis y diseo OO
Anlisis es la etapa de un sistema que

captura los requisitos y el dominio del
problema. El anlisis se centra en lo qu hay
que hacer, mientras que el diseo se centra
en cmo hacerlo.
- En un proceso iterativo estas etapas no tiene
porque realizarse de forma secuencial.

Antonio Navarro
Diseo es la etapa de un sistema que

describe cmo se implementar el sistema
en un nivel lgico sobre cdigo real.
- En el diseo, las decisiones estratgicas y
tcticas se toman para resolver los requisitos
funcionales y de calidad requeridos de un sistema.
21
Anlisis y diseo OO

Antonio Navarro
22
Anlisis y diseo OO
- Los resultados de esta etapa son representados

por los modelos a nivel de diseo, especialmente
la vista esttica, vista de mquina de estados y
vista de interaccin.
Sin embargo, en el modelo de proceso

unificado, la salida del anlisis es la
especificacin de los diagramas de casos de
uso a diagramas de interaccin entre clases
de anlisis
Antonio Navarro
- El resultado de esta etapa se representa mediante

modelos del nivel de anlisis, especialmente la
vista de casos de uso y la vista esttica.
23
En Booch original, por ejemplo, en diseo

proporciona cdigo.
Pressman en diseo da la representacin a
nivel de mdulos de las clases
Sommerville identifica:
- Anlisis OO: centrado en desarrollar un modelo
OO del dominio de la aplicacin. Los objetos
identificados reflejan las entidades y operaciones
asociadas con el problema a resolver.
Antonio Navarro
24
Anlisis y diseo OO
Anlisis y diseo OO
ANLISIS
- Diseo OO: centrado en desarrollar un modelo

OO del sistema software para implementar los
requisitos identificados. Los objetos en el diseo
estn relacionados con la solucin al problema que
se est resolviendo.
Clases
Especificacin
de requisitos
Actividades
Estados
Interaccin
DISEO
Componentes
Con independencia de lo que digan los

libros nosotros debemos generar:

Antonio Navarro
Casos de
uso
Cdigo
25
Despliegue

Antonio Navarro
26
Requisitos
Captura de requisitos
Anlisis y diseo OO
Ya hemos hablado en esta asignatura del

proceso de captura de requisitos
El PUD identifica cuatro pasos que no
tienen porque llevarse a cabo de forma
separada:
- Enumerar los requisitos candidatos.
- Comprender el contexto del sistema.
- Capturar los requisitos funcionales.
- Capturar los requisitos no funcionales.
Relacin entre flujos de trabajo y fases en RUP

Antonio Navarro
27

Antonio Navarro
28
Requisitos
Requisitos
Enumerar los requisitos candidatos consiste

en identificar todos los posibles requisitos que
son susceptibles de ser implementados por el
sistema
- Estos requisitos forman la lista de caractersticas,
en la cual, adems del requisito (caracterstica)
incluye:
- Prioridad (crtico, importante o secundario).

- Nivel de riesgo asociado a la implementacin de la
caracterstica (crtico, significativo u ordinario).
- Esta informacin sirve para:

- Estimar el tamao del proyecto.
- Decidir cmo dividir el proyecto en una secuencia de
iteraciones
- Estado (propuesto, aprobado, incluido o validado).

- Coste estimado de implementacin (tipos de recursos y
esfuerzo).
Antonio Navarro
29
Requisitos
30
Requisitos
Comprender el contexto del sistema, es

decir, el dominio de la aplicacin
Capturar requisitos funcionales identifica

los requisitos funcionales utilizando los
casos de uso
- Con este fin se proporcionar un:
- Adems de los casos de uso, los analistas deben

especificar la apariencia de la interfaz de usuario.
- Modelo del dominio, que describe los conceptos

importantes del contexto como objetos del dominio y
enlaza estos objetos entre si.
- Modelo del negocio, que describe los procesos
(existentes u observados) con el objetivo de
comprenderlos.
Antonio Navarro

Antonio Navarro
Capturar requisitos no funcionales identifica

propiedades del sistema:
- Restricciones del entorno.
31

Antonio Navarro
32
Requisitos
Requisitos
El papel de los requisitos
- Restricciones de implementacin.
- Rendimiento.
- Dependencias de la plataforma.
- Facilidad de mantenimiento.
- Extensibilidad.
- Fiabilidad.
- Otros.
Antonio Navarro
El papel de los requisitos depende de la fase

de desarrollo del software en la que nos
encontremos
Durante la fase de inicio, los analistas
identifican la mayora de los casos de uso
para delimitar el sistema y el alcance del
proyecto y para detallar los ms importantes
(menos del 10%)
33

Antonio Navarro
Requisitos
Requisitos
Durante la fase de elaboracin, los analistas

capturan la mayora de los requisitos
restantes para que los desarrolladores
puedan estimar el tamao del esfuerzo de
desarrollo que se requerir
Los requisitos restantes se capturan e

implementan durante la fase de
construccin
Casi no hay captura de requisitos en la fase
de transicin, a menos que haya requisitos
que cambien
- El objetivo es haber capturado un 80% de los

requisitos y haber descrito la mayora de los casos
de uso.
Antonio Navarro
35

Antonio Navarro
34
36
Requisitos
Requisitos
Modelo del dominio
Un modelo del dominio captura los tipos
ms importantes de objetos en el contexto
del sistema
Los objetos del dominio representan las
cosas que existen o los eventos que
suceden en el entrono en el que trabaja el
sistema
El papel de los requisitos en el proceso de desarrollo

Antonio Navarro
37
Requisitos
Modelo del dominio
38
Requisitos
Modelo del dominio
Muchos de los objetos del dominio o clases

pueden obtenerse de una especificacin de
requisitos o mediante la entrevista con los
expertos del dominio
Las clases del dominio aparecen en tres
formas tpicas:
- Objetos del mundo real y conceptos de los que el

sistema debe hacer un seguimiento, como la
aviacin enemiga, misiles y trayectorias.
- Sucesos que ocurrirn o han ocurrido, como la
llegada de un avin, su salida y la hora de la
comida.
El modelo del dominio se describe mediante

diagramas UML (especialmente de clases)
- Objetos del negocio, que representan cosas que

se manipulan en el negocio, como pedidos,
cuentas, contratos, etc.
Antonio Navarro

Antonio Navarro
39

Antonio Navarro
40
Requisitos
Modelo del dominio
Requisitos
Modelo del dominio
Ejemplo:

Antonio Navarro
El modelado del dominio se realiza

habitualmente en reuniones organizadas por
los analistas del dominio
El objetivo del modelado del dominio es
comprender y describir las clases ms
importantes dentro del contexto del sistema
Modelo del dominio
41
Requisitos
Modelo del dominio
42
Requisitos
Modelo del dominio
Los dominios de tamao moderado

normalmente requieren entre 10 y 50 de
estas clases
Las restantes clases candidatas que los
analistas pueden extraer del dominio se
guardan como definiciones en un glosario
de trminos
Antonio Navarro

Antonio Navarro
En dominios muy pequeos, no es necesario

desarrollar un modelo de objetos para el
dominio; en su lugar puede ser suficiente un
glosario de trminos
El modelo del dominio proporciona un
vocabulario comn a clientes y
desarrolladores
43

Antonio Navarro
44
Requisitos
Modelo del dominio
Requisitos
Modelo del dominio
El objetivo del modelado del dominio es

contribuir a la comprensin del contexto del
sistema, y por extensin de los requisitos
que se desprenden de este contexto
Es decir, el modelo del dominio contribuye
a una comprensin del problema que el
sistema resuelve en relacin a su contexto
El modo interno por el cual el sistema

resuelve este problema se tratar en los
flujos de trabajo de anlisis, diseo e
implementacin
Las clases del dominio y el glosario de
trminos se utilizan en el desarrollo de los
modelos de casos de uso y anlisis:

Antonio Navarro

Antonio Navarro
45
Requisitos
Modelo del dominio
46
Requisitos
Modelo del negocio
- Para sugerir clases internas al sistema de

desarrollo durante el anlisis.
El modelado del negocio es una tcnica para

comprender los procesos de negocio de la
organizacin
Se debe modelar el sistema del
negocio/entidad que rodea al sistema software
a desarrollar
Tambin podemos concebir al modelo del

dominio como un caso especial de un
modelo del negocio ms completo

Antonio Navarro
- Al describir los casos de uso y al disear la

interfaz de usuario.
47

Antonio Navarro
48
Requisitos
Modelo del negocio
Requisitos
Modelo del negocio
El modelado del negocio est soportado por

dos tipos de modelos UML: modelos de casos
de uso y modelos de objetos
El modelo de casos de uso del negocio
describe los procesos de negocio de una
empresa en trminos de casos de uso del
negocio y actores del negocio que se
corresponden con los procesos del negocio y
los clientes, respectivamente.
El modelo de casos de uso del negocio

presenta un sistema desde la perspectiva de
su uso, y esquematiza cmo proporciona
valor a sus usuarios
Por ejemplo, en el contexto de un consorcio
de compras y ventas, podemos considerar
un caso de uso del negocio que comprende
la venta desde el pedido a la entrega

Antonio Navarro

Antonio Navarro
49
Requisitos
Modelo del negocio
Requisitos
Modelo del negocio
- El proceso de venta es el siguiente:

1. El comprador hace el pedido de bienes o servicios.
2. El vendedor entrega los bienes o servicios.
3. El vendedor enva la factura al comprador.
4. El comprador paga.
- En este contexto, el comprador y el vendedor son

los actores del negocio, y utilizan el caso de uso de
negocio que la entidad les proporciona.
Antonio Navarro
50
51
El modelo de casos de uso del negocio se describe

mediante diagramas de casos de uso.
Un modelo de objetos del negocio es un modelo
interno a un negocio
Describe cmo 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 y unidades de trabajo.
Antonio Navarro
52
Requisitos
Modelo del negocio
Requisitos
Modelo del negocio
Cada realizacin de un caso de uso del

negocio puede mostrase en diagramas de
interaccin y diagramas de actividad
Una entidad del negocio representa algo,
como una factura, que los trabajadores
toman, inspeccionan, manipulan, producen
o utilizan en un caso de uso del negocio
Antonio Navarro
Un unidad de trabajo es un conjunto de

esas entidades que conforma un todo
reconocible para un usuario final
Las entidades den negocio y las unidades de
trabajo se utilizan para representar los
mismos tipos de conceptos que las clases
del dominio como Pedido, Articulo,
Factura y Cuenta
53
Requisitos
Modelo del negocio

Antonio Navarro
54
Requisitos
Modelo del negocio
Por tanto, podemos confeccionar un

diagrama de las entidades del negocio, muy
parecido modelo del dominio
Tambin tendremos otros diagramas para
mostrar los trabajadores, sus interacciones,
y cmo utilizan las entidades de negocio y
las unidades de trabajo
Ejemplo:
Interacciones en el modelo del negocio

Antonio Navarro
55

Antonio Navarro
56
Requisitos
Modelo del negocio
Requisitos
Modelo del negocio
Cada trabajador, entidad del negocio, y

unidad de trabajo pueden participar en la
realizacin de ms de un caso de uso del
negocio
El modelo del negocio se desarrolla en dos
pasos:
2. Desarrollar un modelo de objetos del negocio

compuesto por trabajadores, entidades del negocio y
unidades de trabajo que juntos realizan los casos de
uso del negocio.
1. Desarrollar un modelo de casos de uso del

negocio que identifique a los actores del negocio y
los casos de uso.
Antonio Navarro
57
Requisitos
Modelo del negocio

Antonio Navarro
58
Requisitos
Modelo del negocio
Por tanto, las clases del dominio y las

entidades del negocio son conceptos muy
parecidos, y utilizamos ambos trminos
indistintamente
Sin embargo existen algunas diferencias
importantes entre el modelado del negocio y
el modelado del dominio que hacen mucho
ms recomendable realizar el modelado del
negocio
Antonio Navarro
Ntese que el modelo del dominio se puede

ver como una variante simplificad del modelo
del negocio, en la cual nos centramos slo en
las cosas, es decir, en las clases del del
dominio o entidades del negocio
59
- Las clases del dominio se obtienen del

conocimiento de expertos del dominio o del
conocimiento de sistemas similares. Las entidades
del negocio se derivan a partir de los clientes,
identificando los casos de uso del negocio y
buscando despus las entidades.

Antonio Navarro
60
Requisitos
Modelo del negocio
Requisitos
Modelo del negocio
- Las clases del dominio tienen atributos pero

normalmente ninguna o muy pocas operaciones.
Por el contrario, las entidades del negocio incluye
informacin de cmo utilizan estas entidades los
trabajadores que participan en la realizacin de los
casos de uso del negocio.

Antonio Navarro
61
Requisitos
Requisitos adicionales
- Los trabajadores identificados en el modelado

del negocio se utilizan como punto de partida para
derivar un primer conjunto de actores y casos de
uso para el sistema de informacin en
construccin.

Antonio Navarro
62
Requisitos
Los requisitos adicionales son

fundamentalmente requisitos no funcionales
que no pueden asociarse a ningn caso de
uso concreto, pero que s pueden a afectar a
varios o ningn caso de uso
Los requisitos adicionales se capturan
mediante una lista de requisitos, que se
tiene en cuenta durante anlisis y diseo
Los requisitos adicionales podemos

clasificarlos en:

Antonio Navarro

Antonio Navarro
63
- Requisitos de interfaz. Especifican la interfaz con

un elemento externo con el cual debe interactuar el
sistema, o establecen restricciones condicionantes
en formatos, tiempos u otros factores relevantes en
esa interaccin.
64
Requisitos
Requisitos
- Requisitos fsicos. Especifican una caracterstica

fsica que debe poseer un sistema, como su
material, forma, tamao o peso.
- Restricciones de diseo. Limitan el diseo de un
sistema, como lo hacen las restricciones de
extensibilidad y mantenibilidad, o las restricciones
relativas a la reutilizacin de sistemas heredados o
partes esenciales de los mismos.
Antonio Navarro
65
Requisitos
Captura de los requisitos ...

Antonio Navarro
66
Requisitos
Los casos de uso proporcionan un medio

intuitivo y sistemtico para capturar los
requisitos funcionales, con un nfasis
especial en el valor aadido para cada
usuario individual o para cada sistema
externo
Adems, sirven como gua para el proceso
de desarrollo
Antonio Navarro
- Restricciones de implementacin. Especifican o

limitan la codificacin o construccin de un
sistema, tales como estndares requeridos, normas
de codificacin, lenguajes de programacin, etc.
- Otros requisitos. Tales como los legales y las
normativas
Ej.:
Casos de uso
en un sistema
de Pagos y
Facturacin
67

Antonio Navarro
68
Requisitos
Requisitos
Como ya hemos comentado, los diagramas

de actividades o de interaccin pueden
especificar a los casos de uso
Adems, durante este proceso se
proporciona la caracterizacin de la interfaz
de usuario, bien mediante dibujos en papel,
bien mediante prototipos de dicha interfaz
Ejemplo:
Caracterizacin de la IGU
Antonio Navarro
69

Antonio Navarro
Requisitos
Requisitos
Normas
EL artefactos utilizado para capturar los

casos de uso es el modelo de casos de uso,
formado por:
Podemos considerar las siguientes normas:

- Los casos de uso deben mantenerse tan
independientes los unos de otros como sea posible.
- Los casos de uso deben describirse utilizando el
lenguaje del cliente.
- Cada caso de uso debe estructurarse para que
forme una especificacin de funcionalidad
completa e intuitiva.
- Actores UML.
- Casos de uso UML.

Antonio Navarro
70
71

Antonio Navarro
72
Anlisis
Introduccin
Anlisis
Introduccin
Durante el anlisis se estudian los

requisitos, refinndolos y estructurndolos
El objetivo es conseguir un comprensin
ms precisa de los requisitos y una
descripcin de los mismos que sea fcil de
mantener y que ayude a estructurar el
sistema
Antonio Navarro
Durante el anlisis, los casos de uso deben

representarse desde la perspectiva de los
desarrolladores
Adems, ahora la vista se centra en el
sistema, y no en el problema
Comparativamente:
73

Antonio Navarro
Anlisis
Introduccin
74
Anlisis
Introduccin
Analizar los requisitos en forma de un
modelo de anlisis es importante, ya que:
- Un modelo de anlisis ofrece una especificacin
ms precisa de los requisitos que el modelo de
casos de uso.
- Un modelo de anlisis se describe utilizando el el
lenguaje de los desarrolladores, y puede por tanto
introducir un mayor formalismo y ser utilizado
para razonar sobre el funcionamiento interno del
sistema.
Comparacin entre requisitos y anlisis

Antonio Navarro
75

Antonio Navarro
76
Anlisis
Introduccin
Anlisis
El papel del anlisis
Un modelo de anlisis estructura los requisitos

de un modo que facilita su comprensin, su
preparacin, su modificacin, y en general, su
mantenimiento
Un modelo de anlisis puede considerarse
como una primera aproximacin al modelo de
diseo, aunque es un modelo por s mismo.
El papel del anlisis depende de la fase de

desarrollo del software en la que nos
encontremos
Las iteraciones iniciales de elaboracin se
centran en el anlisis
Ms adelante, al trmino de la fase de
elaboracin y durante la construccin el
nfasis pasa a diseo e implementacin

Antonio Navarro

Antonio Navarro
77
Anlisis
Anlisis
Adems, hay tres formas diferentes de

considerar al modelo de anlisis:
- Para describir los resultados del anlisis y
mantener la consistencia de este modelo durante
todo el ciclo de vida del software.
- Para describir los resultados del anlisis,
considerando a este modelo como una herramienta
transitoria e intermedia hasta el diseo.
Antonio Navarro
78
79
- El proyecto no utiliza en absoluto el modelo de

anlisis para describir los resultados del anlisis.
El proyecto concibe los requisitos como parte
integrada de la captura de requisitos o en el
diseo. Suele aplicarse en el caso de tratarse de
sistemas simples

Antonio Navarro
80
Anlisis
Anlisis
Artefactos
El artefacto utilizado para capturar el
anlisis es el modelo de anlisis, formado
por:
- Clases de anlisis.
- Realizaciones de casos de uso.
- Paquetes de anlisis.
- Vista arquitectnica del modelo de anlisis.
El papel del anlisis en el proceso

Antonio Navarro
81

Antonio Navarro
Anlisis
Artefactos
Anlisis
Artefactos
- Esto hace que una clase de anlisis se ms
evidente en el contexto del dominio del problema,
menos especfica que sus contrapartidas en diseo
e implementacin.
- Una clase de anlisis raramente define u ofrece
una interfaz en trminos de operaciones y de sus
signaturas. Su comportamiento se define mediante
responsabilidades en un nivel ms alto y menos
formal. Una responsabilidad es una descripcin
textual del comportamiento de una clase.
Una clase de anlisis representa una

abstraccin de una o varias clases y/o
subsistemas del diseo del sistema. Posee
las siguientes caractersticas:
- Una clase de anlisis se centra en el tratamiento
de los requisitos funcionales y pospone los no
funcionales, hasta llegar a las actividades de
diseo e implementacin.
Antonio Navarro
82
83

Antonio Navarro
84
Anlisis
Artefactos
Anlisis
Artefactos
- Una clase de anlisis define atributos, aunque

esos atributos tambin son de un nivel bastante
alto. Normalmente los tipos de esos atributos son
conceptuales y reconocibles en el dominio del
problema, mientras que en diseo suelen ser tipos.
Con frecuencia, los atributos identificados durante
el anlisis pasan a ser clases durante el diseo.

Antonio Navarro
85
- Una clase de anlisis participa en relaciones,

aunque esas relaciones son ms conceptuales que
sus contrapartidas de diseo. Por ejemplo, la
navegabilidad de las asociaciones no es vital en
anlisis, pero s en diseo.
- Las clases de anlisis estn estereotipadas en tres
tipos, mientras que es ms difcil estereotipar las
clases de diseo.
Antonio Navarro
Anlisis
Artefactos
Anlisis
Artefactos
Los estereotipos de clases de anlisis

son:
nombre
Clase de control.
nombre
<<control>>
nombre
Clase de entidad.
nombre
<<entity>>
nombre

Antonio Navarro
Las clases de interfaz se utilizan para

modelar la interaccin entre el sistema y sus
actores
Esta interaccin a menudo implica recibir
informacin y peticiones de y hacia los
usuarios y los sistemas externos
<<boundary>>
Clase de interfaz.
86
nombre
87

Antonio Navarro
88
Anlisis
Artefactos
Anlisis
Artefactos
Las clases de interfaz modelan las partes del

sistema que dependen de sus actores, lo cual
implica que clarifican y renen los
requisitos en los lmites del sistema
A menudo representan abstracciones de
ventanas, formularios, paneles, interfaces de
comunicacin, etc.
No es necesario que describan cmo se

ejecuta fsicamente la interaccin,
actividades de diseo.
Ejemplo:
Una clase de interfaz

Antonio Navarro
89

Antonio Navarro
Anlisis
Artefactos
Anlisis
Artefactos
Las clases de entidad se utilizan para

modelar informacin que posee una vida
larga y que a menudo es persistente
Modelan la informacin y el
comportamiento asociado de algn
fenmeno o concepto, como una persona,
un objeto del mundo real, o un suceso del
mundo real
Antonio Navarro
90
En la mayora de los casos, las clases de

entidad se derivan directamente de una
clase de entidad del negocio (o de una clase
del dominio). Sin embargo, las clases
entidad representan objetos manejados por
el sistema en consideracin y no del
negocio
91

Antonio Navarro
92
Anlisis
Artefactos
Anlisis
Artefactos
Por lo tanto, las clases de entidad reflejan la

informacin de tal forma que indica como
disear el sistema, incluyendo el soporte de
persistencia
Un objeto de entidad no ha de ser
necesariamente pasivo y puede tener en
ocasiones un comportamiento relativo a la
informacin que representa
Las clases de entidad suelen mostrar una

estructura de datos lgica y contribuyen a
comprender de qu informacin depende el
sistema
Ejemplo:

Antonio Navarro

Antonio Navarro
93
Clase de entidad en un caso de uso
94
Anlisis
Artefactos
Anlisis
Artefactos
Las clases de control representan

coordinacin secuencia, transacciones y
control de otros objetos.
Se usan con frecuencia para encapsular el
control de un caso de uso en concreto
Tambin encapsulan procesamientos
complejos que no pueden asociarse con una
clase entidad concreta
Los aspectos dinmicos del sistema se

modelan con clases de control, debido a que
ellas manejan y coordinan las acciones y los
flujos de control principales, y delegan
trabajo a otros objetos (de interfaz y/o
entidad)

Antonio Navarro

Antonio Navarro
95
96
Anlisis
Artefactos
Anlisis
Artefactos
Ejemplo:
Una realizacin de caso de uso-anlisis es

una colaboracin dentro del modelo de
anlisis que describe cmo se lleva a cabo y
se ejecuta un caso de uso determinado en
trminos de las clases de anlisis y sus
objetos de anlisis en interaccin
Clase de control en un caso de uso

Antonio Navarro
97

Antonio Navarro
Anlisis
Artefactos
98
Anlisis
Artefactos
Una realizacin de caso de uso-anlisis

contiene:
- Descripcin textual del flujo de sucesos.
- Diagramas de clases.
- Diagramas de interaccin
Ejemplo:
Diagrama de clases de anlisis
Antonio Navarro
99

Antonio Navarro
100
Anlisis
Artefactos
Anlisis
Artefactos
Los paquetes de anlisis proporcionan un
medio para organizar los artefactos del
modelo de anlisis en piezas manejables
Pueden contener:
- Clases de anlisis.
- Realizaciones de casos de uso.
- Otros paquetes de anlisis.
Pagar factura
Antonio Navarro
101

Antonio Navarro
Anlisis
Artefactos
Anlisis
Artefactos
Adems, sus caractersticas son:

- Pueden representar una separacin de intereses
de anlisis.
- Deberan crearse en baso a los requisitos
funcionales y el dominio del problema.
- Probablemente se convertirn en subsistemas en
diseo.

Antonio Navarro
102
103
La vista arquitectnica del modelo de

anlisis muestra los artefactos de anlisis
significativos para la arquitectura:
- Descomposicin en paquetes de anlisis y sus
dependencias.
- Clases fundamentales de anlisis.
- Realizaciones de casos de uso que describen una
funcionalidad crtica o importante.
Antonio Navarro
104
Diseo
Introduccin
Diseo
Introduccin
En el diseo se modela el sistema y se le

proporciona su forma para que soporte
todos los requisitos
Una entrada fundamental del diseo es el
modelo de anlisis, que proporciona una
comprensin detallada de los requisitos e
impone una estructura al sistema
Antonio Navarro
Los objetivos del diseo son:

- Adquirir una comprensin en profundidad de los
aspectos relacionados con los requisitos no
funcionales y restricciones tcnicas.
- Crear una entrada apropiada y un punto de
partida para actividades de implementacin
subsiguientes.
105

Antonio Navarro
Diseo
Introduccin
106
Diseo
Introduccin
- Ser capaces de descomponer los trabajos de

implementacin en partes ms manejables que
puedan ser llevadas a cabo por diferentes equipos
de desarrollo, teniendo en cuenta la posible
concurrencia.

Antonio Navarro
107
Comparacin modelo anlisis y diseo

Antonio Navarro
108
Diseo
El papel del diseo
Diseo
El papel del diseo
El diseo es el centro de atencin al final de

la fase de elaboracin y el comienzo de las
iteraciones de construccin
Esto contribuye a una arquitectura estable y
slida y a crear un plano del modelo de
implementacin.
Ms tarde, durante la fase de construccin

cuando la arquitectura es estable y los
requisitos estn bien entendidos, el centro
de atencin se desplaza a implementacin
El modelo de diseo est muy ligado al de
implementacin, por lo que se suele
mantener actualizado al modelo durante
todo el proceso de desarrollo

Antonio Navarro

Antonio Navarro
109
Diseo
El papel del diseo
El papel del diseo en el proceso de desarrollo

Antonio Navarro
111
110
Diseo
Artefactos
El artefacto utilizado para capturar el

anlisis es el modelo de diseo, formado
por:
- Clases de diseo.
- Realizacin de caso de uso-diseo.
- Subsistema de diseo.
- Interfaz.
- Vista arquitectnica del modelo de diseo.
- Modelo de despliegue.
- Vista arquitectnica del modelo de despliegue.

Antonio Navarro
112
Diseo
Artefactos
Diseo
Artefactos
El modelo de diseo es un modelo de

objetos que describe la realizacin fsica de
los casos de uso centrndose en el impacto
en el sistema de los requisitos
La clase de diseo es una abstraccin de
una clase o construccin similar en la
implementacin
Las caractersticas de las clases de diseo

son:

Antonio Navarro

Antonio Navarro
113
- El lenguaje de especificacin de la clase coincide

con el de implementacin.
- Normalmente se especifica la visibilidad de los
atributos.
- Las relaciones entre clases de diseo se traducen
directamente en implementacin.
114
Diseo
Artefactos
Diseo
Artefactos
- Los mtodos de una clase de diseo tienen

correspondencia directa con el cdigo.
- Una clase de diseo puede posponer decisiones
que son inapropiadas de manejar en el modelo de
diseo.
- Una clase de diseo se puede corresponder con
clases existentes en el lenguaje de
implementacin.
- Una clase de diseo puede realizar interfaces si

tiene sentido hacerlo en el lenguaje de
programacin.
- Una clase de diseo puede ser activa.

Antonio Navarro
115
Ej.:

Antonio Navarro
Clases de diseo
116
Diseo
Artefactos
Diseo
Artefactos
Una realizacin de caso de uso-diseo es

una colaboracin en el modelo de diseo
que describe cmo se realiza un caso de uso
especfico, y cmo se ejecuta, en trminos
de clases de diseo y sus objetos
Se construyen sobre los casos de uso de
anlisis
Una realizacin de caso de uso-diseo tiene:

Antonio Navarro

Antonio Navarro
117
- Una descripcin del flujo de eventos textual.

- Diagramas de clases de diseo.
- Diagramas de interaccin entre objetos de
diseo.
Los subsistemas de diseo son una forma de

organizar los artefactos del modelo de
diseo en piezas ms manejables
Diseo
Artefactos
Diseo
Artefactos
Un subsistema puede constar de:
- Pueden representar una separacin de aspectos

del diseo.
- Suelen tener relaciones con las clases y/o
paquetes de anlisis.
- Pueden representar productos software
reutilizados que han sido encapsulados en ellos.
- Pueden representar sistemas heredados (o parte
de ellos) encapsulndolos.
- Clases de diseo.
- Realizaciones de caso de uso.
- Interfaces.
- Otros subsistemas.
Caractersticas de subsistemas:
- Deben ser cohesivos.
- Deben tener bajo acoplamiento.
Antonio Navarro
118
119

Antonio Navarro
120
Diseo
Artefactos
Diseo
Artefactos
- Los subsistemas pueden representar componentes

de grano grueso en la implementacin del sistema,
es decir, componentes que proporcionan varios
interfaces compuestos a partir de otros componentes
de grano ms fino, como los que especifican clases
de implementacin individuales, y que se convierten
ellos mismos en ejecutables, ficheros binarios o
entidades similares que pueden distribuirse en
diferentes nodos.
Antonio Navarro
121
Las interfaces se utilizan para especificar

las operaciones que proporcionan las clases
y los subsistemas de diseo
Una clase de diseo que realice una interfaz
debe proporcionar mtodos que realicen las
operaciones del interfaz

Antonio Navarro
122
Diseo
Artefactos
Diseo
Artefactos
Un subsistema que realice a un interfaz

debe contener tambin clases de diseo u
otros subsistemas que realicen la interfaz
Las interfaces constituyen una forma de
separar la especificacin de la funcionalidad
en trminos de operaciones de sus
implementaciones trminos de mtodos
Esta distincin hace independiente de la

implementacin de la interfaz a cualquier
cliente que dependa de ella
As, podemos sustituir una implementacin
concreta de una interfaz, como puede ser
una clase o un subsistema de diseo, por
otra implementacin sin tener que cambiar
los clientes

Antonio Navarro

Antonio Navarro
123
124
Diseo
Artefactos
Diseo
Artefactos

diseo muestra los artefactos relevantes
para la arquitectura de la aplicacin:
Ejemplo:
- Descomposicin del modelo en subsistemas, sus

interfaces y las dependencias entre ellos.
- Clases de diseo fundamentales.
- Realizaciones de casos de uso-diseo que
describan alguna funcionalidad crtica
Antonio Navarro
125

Antonio Navarro
Diseo
Artefactos
Diagrama de clases de diseo
126
Diseo
Artefactos
El modelo de despliegue es un modelo de
objetos que describe la distribucin fsica
del sistema en trminos de cmo se
distribuye la funcionalidad entre los nodos
de cmputo
Cada nodo representa un recurso de
cmputo, normalmente un procesador o
dispositivo hardware similar

Antonio Navarro
Pagar factura
127

Antonio Navarro
128
Diseo
Artefactos
Diseo
Artefactos
Los nodos poseen relaciones que

representan medios de comunicacin entre
ellos, tales como Internet, intranet, bus y
similares
El modelo de despliegue puede describir
diferentes configuraciones de red, incluidas
las configuraciones para pruebas y
simulacin
La funcionalidad (los procesos) de un nodo

se definen por los componentes que se
distribuyen sobre ese nodo
El modelo de despliegue en s mismo
representa una correspondencia entre la
arquitectura software y la arquitectura del
sistema (el hardware)

Antonio Navarro

Antonio Navarro
129
Diseo
Artefactos
130
Implementacin
Introduccin

despliegue muestra los artefactos relevantes
del modelo de despliegue para su
arquitectura
En la implementacin empezamos con el

resultado del diseo e implementamos el
sistema en trminos de componentes, es
decir, ficheros de cdigo fuente, scripts,
ficheros de cdigo binario, ejecutables y
similares

Antonio Navarro

Antonio Navarro
131
132
Implementacin
Introduccin
Implementacin
Los propsitos de la implementacin son:

- Planificar las integraciones de sistema necesarias
en cada iteracin.
- Distribuir el sistema asignando componentes
ejecutables a nodos en el diagrama de despliegue.
- Implementar las clases y subsistemas
encontrados durante el diseo.
- Probar los componentes individualmente e
integrarlos.
Antonio Navarro
133
Implementacin
La implementacin es el centro durante las

iteraciones de construccin.
Tambin se lleva a cabo trabajo de
implementacin durante la fase de elaboracin,
para crear la lnea base ejecutable de la
arquitectura
Durante la fase de transicin puede tratar
defectos tardos
Antonio Navarro
134
Implementacin
Ya que el modelo de implementacin

denota la implementacin actual del sistema
en trminos de componentes y subsistemas
de implementacin, es natural mantener el
modelo de implementacin a lo largo de
todo el ciclo de vida del software
El papel de la implementacin en el proceso de desarrollo
Antonio Navarro
135

Antonio Navarro
136
Implementacin
Artefactos
Implementacin
Artefactos
El artefacto utilizado para capturar la

implementacin es el modelo de
implementacin, formado por:
- Componentes.
- Subsistemas de implementacin.
- Interfaces.
- Visin arquitectnica del modelo de implementacin.
- Plan de integracin de construcciones.
Antonio Navarro
137
El modelo de implementacin describe

cmo los elementos del modelo de diseo,
como las clases, se implementan en
trminos de componentes, como ficheros de
cdigo fuente, ejecutables, etc.
Tambin describe cmo se organizan los
componentes y sus dependencias
Antonio Navarro
Implementacin
Artefactos
Un componente es el empaquetamiento fsico de

los elementos de un modelo, como son las
clases en el modelo de diseo
Algunos estereotipos de componentes son:
- executable es un programa ejecutable en un nodo.
- file es un fichero que contiene cdigo fuente o
datos.
- library es una librera esttica o dinmica.
- table es una tabla de una base de datos.
- document es un documento.
Antonio Navarro
139
138
Implementacin
Artefactos
Los subsistemas de implementacin
proporcionan una forma de organizar los
artefactos del modelo de implementacin en
trozos ms manejables
Un subsistema puede estar formado por:
- Componentes.
- Interfaces.
- Otros subsistemas.
Antonio Navarro
140
Implementacin
Artefactos
Implementacin
Artefactos
Un subsistema de implementacin se
manifiesta a travs de un mecanismo de
empaquetamiento concreto en un entorno de
implementacin determinado, tales como:
- Un paquete Java.
- Un proyecto Visual Basic.
- Un directorio de ficheros en un proyecto C++.
- Un paquete en una herramienta Rational Rose.
Antonio Navarro
141
Los subsistemas de implementacin estn

muy ligados a los subsistemas de diseo
Los interfaces de implementacin se
corresponden con los interfaces de diseo
La visin arquitectnica del modelo de
implementacin representa los artefactos
significativos arquitectnicamente:
Antonio Navarro
Implementacin
Artefactos
Implementacin
Artefactos
- Las partes del modelo de implementacin
afectadas por la construccin
- La descomposicin del modelo de

implementacin en subsistemas, sus interfaces y
las dependencias entre ellos.
- Componentes claves.
Una construccin es una versin ejecutable

del sistema, usualmente, una parte
especfica del mismo.
En una iteracin puede haber una o ms
construcciones
El plan de integracin de construcciones

describe la secuencia de construcciones
necesarias en una iteracin, es decir:
- La funcionalidad que se espera de la
construccin.
Antonio Navarro
142
143

Antonio Navarro
144
Prueba
Introduccin
Prueba
Introduccin
Durante la prueba se verifica el resultado de

la implementacin probando cada
construccin, incluyendo tanto
construcciones internas como intermedias,
as como las versiones finales del sistema a
ser entregadas a terceros
Los objetivos de la prueba son:

Antonio Navarro

Antonio Navarro
145
Prueba
Introduccin
146
Prueba
El papel de la prueba
- Realizar las diferentes pruebas y manejar los

resultados de cada prueba sistemticamente.

Antonio Navarro
- Planificar las pruebas necesarias en cada

iteracin, incluidas las de integracin y sistema.
Las pruebas de integracin son necesarias para
cada construccin dentro de la iteracin, mientras
que las pruebas de sistema son necesarias slo al
final de la iteracin.
- Disear e implementar las pruebas.
Durante la fase de inicio puede hacerse

parte de la planificacin inicial de las
pruebas cuando se define el mbito del
sistema.
Sin embargo, las pruebas se llevan a cabo
sobre todo cuando una construccin es
sometida a pruebas de integracin y de
sistema
147

Antonio Navarro
148
Prueba
Prueba
Por tanto, la realizacin de pruebas se

centra en las fases de elaboracin y
construccin.
Durante la fase de transicin la prueba sirve
para la correccin de defectos durante los
primeros usos.
El papel de la prueba en el proceso de desarrollo
Antonio Navarro
149

Antonio Navarro
Prueba
Artefactos
Prueba
Artefactos
El artefacto utilizado para capturar la

prueba es el modelo de prueba, formado
por:
Un caso de prueba especifica una forma de

probar el sistema, incluyendo la entrada o
resultado con la que se ha de probar y las
condiciones bajo las que ha de probarse
Lo que se prueba puede venir dado por un
requisito o coleccin de requisitos del
sistema
- Casos de prueba.
- Procedimientos de prueba.
- Componente de prueba.
- Plan de prueba.
- Defecto.
- Evaluacin de prueba.
Antonio Navarro
150
151

Antonio Navarro
152
Prueba
Artefactos
Prueba
Artefactos
Casos de prueba comunes:
- Que se sigue la secuencia de acciones

especificadas por el caso de uso.
- Caso de prueba de un caso de uso.

- Caso de prueba de la realizacin de un caso de
uso-diseo.
Un caso de prueba de caso de uso incluye:

- La verificacin del resultado de la interaccin
entre los actores y el sistema.
- Que se satisfacen las pre y postcondiciones del
caso de uso.
Antonio Navarro
153
Un caso de prueba basado en un caso de uso

especifica tpicamente una prueba del
sistema como caja negra, es decir, una
prueba del comportamiento observable
externamente del sistema
Antonio Navarro
Prueba
Artefactos
Prueba
Artefactos
Un caso de prueba de la realizacin de un

caso de uso-diseo incluye:
Se pueden especificar otros casos de prueba

para probar el sistema como un todo:
- La verificacin de la interaccin entre los

componentes que implementan dicho caso de uso.
Los casos de prueba basados en la la

realizacin de un caso de uso tpicamente
especifican una prueba del sistema como caja
blanca, es decir, una prueba de la interaccin
interna de los componentes del sistema
Antonio Navarro
154
155
- Pruebas de instalacin. Verifican que el sistema

puede ser instalado en la plataforma del cliente, y
que el sistema funciona correctamente en dicha
plataforma.
- Pruebas de configuracin. Verifican que el
sistema funciona correctamente en diferentes
configuraciones.
Antonio Navarro
156
Prueba
Artefactos
Prueba
Artefactos
- Pruebas negativas. Intentan provocar que el

sistema falle para poder as revelar sus
debilidades. Se intenta probar el sistema en formas
para los que no ha sido diseado.
- Pruebas de tensin o estrs. Identifican
problemas con el sistema cuando hay recursos
insuficientes o cuando hay competencia por los
recursos
Antonio Navarro
157
El procedimiento de prueba especifica

cmo realizar uno o varios casos de prueba
o partes de stos
El componente de prueba automatiza uno o
varios procedimientos de prueba o partes d
ellos
El plan de prueba describe las estrategias,
recursos y planificacin
Antonio Navarro
Prueba
Artefactos
Prueba
Artefactos
La estrategia de prueba incluye:

- La definicin del tipo de pruebas a realizar para
cada iteracin y sus objetivos.
- El nivel de cobertura de prueba y de cdigo
necesario.
- El porcentaje de pruebas que deberan ejecutarse
con un resultado especfico.

Antonio Navarro
158
159
Un defecto es una anomala del sistema.

Una evaluacin de prueba es una evaluacin
de los resultados de los esfuerzos de prueba

Antonio Navarro
160
Conclusiones
Conclusiones
Proceso unificado de desarrollo

Ventaja: especifica los diagramas UML que
hay que generar en cada actividad
estructural
Inconveniente: muy ligada al mtodo
Anlisis y diseo OO

Antonio Navarro

Antonio Navarro
161
Requisitos
Anlisis
Diseo
Implementacin
Prueba
162

El Proceso Unificado de Desarrollo de Software - Jacobson

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

El Proceso Unificado de Desarrollo de Software - Jacobson

Uploaded by

Copyright:

Available Formats

ndice

13. El proceso unificado de

Ingeniera del Software

Ingeniera del Software

Captura de requisitos como casos de uso.

Ingeniera del Software

Ingeniera del Software

Proceso de Jacobson, Booch y Rumbaugh

- Booch: mtodo Booch.

Tambin conocido por RUP: Rational

Ingeniera del Software

Modelo basado en componentes

Ingeniera del Software

- Componente: Una parte fsica y reemplazable de

Muy ligado a UML

Ingeniera del Software

Discusin: todo modelo iterativo es

- Dirigido por casos de uso.

Un proceso de desarrollo de software

Ingeniera del Software

Est formado por cinco flujos de trabajo