el proceso unificado de desarrollo de software - jacobson

7/24/2019 El Proceso Unificado de Desarrollo de Software - Jacobson

1/41

Ingeniera del Software

Antonio Navarro

1

13. El proceso unificado dedesarrollo de software


Antonio Navarro

2

ndice

Introduccin Anlisis y diseo orientado a objetos

Requisitos

Captura de requisitos.

Papel de los requisitos.

Modelo del dominio. Modelo del negocio.

Requisitos adicionales.


Antonio Navarro

3

ndice

Captura de requisitos como casos de uso.

Normas.

Anlisis

Introduccin.

El papel del anlisis.

Artefactos


Antonio Navarro

4

ndice

Diseo

Introduccin. El papel de diseo.

Artefactos.

Implementacin

Introduccin.

El papel de la implementacin

Artefactos


2/41


Antonio Navarro

5

ndice

Prueba Introduccin.

El papel de la implementacin.

Artefactos.

Conclusiones


Antonio Navarro

6

Proceso de Jacobson, Booch y Rumbaugh

Los autores de UML

- Booch: mtodo Booch.

- Rumbaugh: OMT.

- Jacobson: proceso Objectory.

Tambin conocido por RUP:RationalUnified Process

Introduccin


Antonio Navarro

7

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.

Introduccin


Antonio Navarro

8

- Componente: Una parte fsica y reemplazable de

un sistema que se ajusta a, y proporciona larealizacin de un conjunto de interfaces.

Muy ligado a UML

Discusin: cmo diramos esto en trminos

de las capas de IS?

Introduccin


3/41


Antonio Navarro

9

Caractersticas:- Dirigido por casos de uso.

- Centrado en la arquitectura.

- Iterativo e incremental.

Introduccin

Proceso de

desarrollo de

softwareRequisitos

usuario

Sistema

software

Un proceso de desarrollo de softwareIngeniera del Software

Antonio Navarro

10

Discusin: todo modelo iterativo esincremental? Y todo incremental es

iterativo?

Introduccin


Antonio Navarro

11

Est formado por cincoflujos de trabajo

(i.e. AEs) que se iteran: Requisitos.

Anlisis.

Diseo.

Implementacin.

Prueba.

Introduccin


Antonio Navarro

12

Introduccin

Anlisis

Requisitos

Implementacin

Diseo

Prueba

El proceso unificado de desarrollo


4/41


Antonio Navarro

13

Cada vuelta en la espiral se denominaiteracin

La agrupacin de iteraciones se denominafase

- Inicio.

- Elaboracin.

- Construccin.

- Transicin.

Introduccin


Antonio Navarro

14

Fase de inicio Se desarrolla una descripcin del producto

final.

Fase de elaboracin:

Se especifican los casos de uso.

Se disea la arquitectura del sistema.

Introduccin


Antonio Navarro

15

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

Introduccin


Antonio Navarro

16

Introduccin

Relacin entre flujos de trabajo y fases en RUP


5/41


Antonio Navarro

17

Las agrupaciones de fases se denominanciclo

Cada ciclo concluye con una versin del

producto

Discusin: es lo mismo un ciclo RUP que

un ciclo del modelo en espiral?

Introduccin


Antonio Navarro

18

Introduccin

Ciclos en RUP


Antonio Navarro

19

Ventajas

Modelo de proceso racional.

Tecnologas de componentes.

Inconvenientes

Muy ligado al mtodo.

No incluye explcitamente actividades de

gestin.

Introduccin


Antonio Navarro

20

Anlisis y diseo OO

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


6/41


Antonio Navarro

21

Anlisis y diseo OO

Anlisis es la etapa de un sistema quecaptura 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

22

Anlisis y diseo OO

- El resultado de esta etapa se representa mediantemodelos del nivel de anlisis, especialmente lavista de casos de uso y la vista esttica.

Diseo es la etapa de un sistema quedescribe cmo se implementar el sistemaen un nivel lgico sobre cdigo real.

- En el diseo, las decisiones estratgicas ytcticas se toman para resolver los requisitosfuncionales y de calidad requeridos de un sistema.


Antonio Navarro

23

Anlisis y diseo OO

- Los resultados de esta etapa son representados

por los modelos a nivel de diseo, especialmentela vista esttica, vista de mquina de estados yvista de interaccin.

Sin embargo, en el modelo de procesounificado, la salida del anlisis es laespecificacin de los diagramas de casos deuso a diagramas de interaccin entre clasesde anlisis


Antonio Navarro

24

Anlisis y diseo OO

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 modeloOO del dominio de la aplicacin. Los objetos

identificados reflejan las entidades y operacionesasociadas con el problema a resolver.


7/41


Antonio Navarro

25

Anlisis y diseo OO

-Diseo OO: centrado en desarrollar un modeloOO del sistema software para implementar los

requisitos identificados. Los objetos en el diseo

estn relacionados con la solucin al problema que

se est resolviendo.

Con independencia de lo que digan los

libros nosotros debemos generar:


Antonio Navarro

26

Anlisis y diseo OO

Especificacin

de requisitos

Casos de

uso Actividades

Clases

Interaccin

Estados

Componentes

DespliegueCdigo

ANLISIS

DISEO


Antonio Navarro

27

Anlisis y diseo OO

Relacin entre flujos de trabajo y fases en RUP


Antonio Navarro

28

RequisitosCaptura de requisitos

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 formaseparada:

- Enumerar los requisitos candidatos.

- Comprender el contexto del sistema.

- Capturar los requisitos funcionales.- Capturar los requisitos no funcionales.


8/41


Antonio Navarro

29


Enumerar los requisitos candidatos consisteen identificar todos los posibles requisitos queson susceptibles de ser implementados por elsistema

- Estos requisitos forman la lista de caractersticas,en la cual, adems del requisito (caracterstica)incluye:

-Estado (propuesto, aprobado, incluido o validado).

- Coste estimado de implementacin (tipos de recursos yesfuerzo).


Antonio Navarro

30


- 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


Antonio Navarro

31


Comprender el contexto del sistema, es

decir, el dominio de la aplicacin- Con este fin se proporcionar un:

-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 decomprenderlos.


Antonio Navarro

32


Capturar requisitos funcionales identifica

los requisitos funcionales utilizando loscasos de uso

- Adems de los casos de uso, los analistas deben

especificar la apariencia de la interfaz de usuario.

Capturar requisitos no funcionales identifica

propiedades del sistema:- Restricciones del entorno.


9/41


Antonio Navarro

33


- Restricciones de implementacin.- Rendimiento.

- Dependencias de la plataforma.

- Facilidad de mantenimiento.

- Extensibilidad.

- Fiabilidad.

- Otros.


Antonio Navarro

34

RequisitosEl papel de los requisitos

El papel de los requisitos depende de la fasede 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%)


Antonio Navarro

35


Durante la fase de elaboracin, los analistas

capturan la mayora de los requisitosrestantes para que los desarrolladores

puedan estimar el tamao del esfuerzo de

desarrollo que se requerir

- El objetivo es haber capturado un 80% de los

requisitos y haber descrito la mayora de los casos

de uso.


Antonio Navarro

36


Los requisitos restantes se capturan e

implementan durante la fase deconstruccin

Casi no hay captura de requisitos en la fase

de transicin, a menos que haya requisitos

que cambien


10/41


Antonio Navarro

37


El papel de los requisitos en el proceso de desarrolloIngeniera del Software

Antonio Navarro

38

RequisitosModelo del dominio

Un modelo del dominio captura los tiposms 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


Antonio Navarro

39


Muchos de los objetos del dominio o clases

pueden obtenerse de una especificacin derequisitos o mediante la entrevista con losexpertos del dominio

Las clases del dominio aparecen en tresformas tpicas:

- Objetos del negocio, que representan cosas que

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


Antonio Navarro

40


- Objetos del mundo real y conceptos de los que el

sistema debe hacer un seguimiento, como laaviacin 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)


11/41


Antonio Navarro

41


Ejemplo:

Modelo del dominioIngeniera del Software

Antonio Navarro

42


El modelado del dominio se realizahabitualmente 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


Antonio Navarro

43


Los dominios de tamao moderado

normalmente requieren entre 10 y 50 deestas clases

Las restantes clases candidatas que los

analistas pueden extraer del dominio se

guardan como definiciones en un glosario

de trminos


Antonio Navarro

44


En dominios muy pequeos, no es necesario

desarrollar un modelo de objetos para eldominio; en su lugar puede ser suficiente un

glosario de trminos

El modelo del dominio proporciona un

vocabulario comn a clientes y

desarrolladores


12/41


Antonio Navarro

45


El objetivo del modelado del dominio escontribuir 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 delproblema que el

sistema resuelve en relacin a su contexto


Antonio Navarro

46


El modo interno por el cual el sistemaresuelve este problema se tratar en losflujos de trabajo de anlisis, diseo eimplementacin

Las clases del dominio y el glosario detrminos se utilizan en el desarrollo de los

modelos de casos de uso y anlisis:- Al describir los casos de uso y al disear lainterfaz de usuario.


Antonio Navarro

47


- Para sugerir clases internas al sistema de

desarrollo durante el anlisis. Tambin podemos concebir al modelo del

dominio como un caso especial de un

modelo del negocio ms completo


Antonio Navarro

48

RequisitosModelo del negocio

El modelado del negocio es una tcnica para

comprender los procesos de negocio de laorganizacin

Se debe modelar el sistema del

negocio/entidad que rodea al sistema software

a desarrollar


13/41


Antonio Navarro

49


El modelado del negocio est soportado pordos tipos de modelos UML: modelos de casosde uso y modelos de objetos

El modelo de casos de uso del negociodescribe los procesos de negocio de unaempresa en trminos de casos de uso del

negocio y actores del negocio que secorresponden con los procesos del negocio ylos clientes, respectivamente.


Antonio Navarro

50


El modelo de casos de uso del negociopresenta 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

51


- 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

52


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.


14/41


Antonio Navarro

53


Cada realizacin de un caso de uso delnegocio 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

54


Un unidad de trabajo es un conjunto deesas 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 Pedi do, Ar t i cul o,

Fact ur a y Cuent a


Antonio Navarro

55


Por tanto, podemos confeccionar un

diagrama de las entidades del negocio, muyparecido 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


Antonio Navarro

56


Ejemplo:

Interacciones en el modelo del negocio


15/41


Antonio Navarro

57


Cada trabajador, entidad del negocio, yunidad de trabajo pueden participar en larealizacin de ms de un caso de uso delnegocio

El modelo del negocio se desarrolla en dospasos:

1. Desarrollar un modelo de casos de uso delnegocio que identifique a los actores del negocio ylos casos de uso.


Antonio Navarro

58


2. Desarrollar un modelo de objetos del negociocompuesto por trabajadores, entidades del negocio yunidades de trabajo que juntos realizan los casos deuso del negocio.

Ntese que el modelo del dominio se puedever como una variante simplificad del modelodel negocio, en la cual nos centramos slo enlas cosas, es decir, en las clases del deldominio o entidades del negocio


Antonio Navarro

59


Por tanto, las clases del dominio y las

entidades del negocio son conceptos muyparecidos, y utilizamos ambos trminosindistintamente

Sin embargo existen algunas diferenciasimportantes entre el modelado del negocio yel modelado del dominio que hacen mucho

ms recomendable realizar el modelado delnegocio


Antonio Navarro

60


- Las clases del dominio se obtienen del

conocimiento de expertos del dominio o delconocimiento 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.


16/41


Antonio Navarro

61


- Las clases del dominio tienen atributos peronormalmente 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

62


- Los trabajadores identificados en el modeladodel 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

63

RequisitosRequisitos adicionales

Los requisitos adicionales son

fundamentalmente requisitos no funcionalesque 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


Antonio Navarro

64


Los requisitos adicionales podemos

clasificarlos en:-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.


17/41


Antonio Navarro

65


-Requisitos fsicos. Especifican una caractersticafsica 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

66


-Restricciones de implementacin. Especifican olimitan 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


Antonio Navarro

67

RequisitosCaptura de los requisitos ...

Los casos de uso proporcionan un medio

intuitivo y sistemtico para capturar losrequisitos 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

68


Ej.:

Casos de uso

en un sistema

de Pagos y

Facturacin


18/41


Antonio Navarro

69


Como ya hemos comentado, los diagramasde 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


Antonio Navarro

70


Ejemplo:

Caracterizacin de la IGU


Antonio Navarro

71


EL artefactos utilizado para capturar los

casos de uso es el modelo de casos de uso,formado por:

- Actores UML.

- Casos de uso UML.


Antonio Navarro

72

RequisitosNormas

Podemos considerar las siguientes normas:

- Los casos de uso deben mantenerse tanindependientes 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.


19/41


Antonio Navarro

73

AnlisisIntroduccin

Durante el anlisis se estudian losrequisitos, 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

74

AnlisisIntroduccin

Durante el anlisis, los casos de uso debenrepresentarse desde la perspectiva de los

desarrolladores

Adems, ahora la vista se centra en el

sistema, y no en el problema

Comparativamente:


Antonio Navarro

75

AnlisisIntroduccin

Comparacin entre requisitos y anlisis


Antonio Navarro

76

AnlisisIntroduccin

Analizar los requisitos en forma de un

modelo de anlisis es importante, ya que:- Un modelo de anlisis ofrece una especificacinms precisa de los requisitos que el modelo decasos de uso.

- Un modelo de anlisis se describe utilizando el ellenguaje de los desarrolladores, y puede por tantointroducir un mayor formalismo y ser utilizado

para razonar sobre el funcionamiento interno delsistema.


20/41


Antonio Navarro

77

AnlisisIntroduccin

Un modelo de anlisis estructura los requisitosde 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.


Antonio Navarro

78

AnlisisEl papel del anlisis

El papel del anlisis depende de la fase dedesarrollo del software en la que nosencontremos

Las iteraciones iniciales de elaboracin secentran en el anlisis

Ms adelante, al trmino de la fase de

elaboracin y durante la construccin elnfasis pasa a diseo e implementacin


Antonio Navarro

79


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

80


- 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


21/41


Antonio Navarro

81


El papel del anlisis en el procesoIngeniera del Software

Antonio Navarro

82

AnlisisArtefactos

El artefacto utilizado para capturar elanlisis es el modelo de anlisis, formado

por:

- Clases de anlisis.

- Realizaciones de casos de uso.

- Paquetes de anlisis.

- Vista arquitectnica del modelo de anlisis.


Antonio Navarro

83

AnlisisArtefactos

Una clase de anlisis representa una

abstraccin de una o varias clases y/osubsistemas 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

84

AnlisisArtefactos

- Esto hace que una clase de anlisis se msevidente en el contexto del dominio del problema,menos especfica que sus contrapartidas en diseoe implementacin.

- Una clase de anlisis raramente define u ofreceuna interfaz en trminos de operaciones y de sussignaturas. Su comportamiento se define medianteresponsabilidades en un nivel ms alto y menosformal. Una responsabilidad es una descripcintextual del comportamiento de una clase.


22/41


Antonio Navarro

85

AnlisisArtefactos

- Una clase de anlisis define atributos, aunqueesos 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

86

AnlisisArtefactos

- 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

87

AnlisisArtefactos

Los estereotipos de clases de anlisis

son: Clase de interfaz.

Clase de control.

Clase de entidad.

nombre

nombre

nombre

nombre

nombre

nombre


Antonio Navarro

88

AnlisisArtefactos

Las clases de interfaz se utilizan para

modelar la interaccin entre el sistema y susactores

Esta interaccin a menudo implica recibir

informacin y peticiones de y hacia los

usuarios y los sistemas externos


23/41


Antonio Navarro

89

AnlisisArtefactos

Las clases de interfaz modelan las partes delsistema 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.


Antonio Navarro

90

AnlisisArtefactos

No es necesario que describan cmo seejecuta fsicamente la interaccin,

actividades de diseo.

Ejemplo:

Una clase de interfaz


Antonio Navarro

91

AnlisisArtefactos

Las clases de entidadse utilizan para

modelar informacin que posee una vidalarga 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

92

AnlisisArtefactos

En la mayora de los casos, las clases de

entidad se derivan directamente de unaclase 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


24/41


Antonio Navarro

93

AnlisisArtefactos

Por lo tanto, las clases de entidad reflejan lainformacin 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


Antonio Navarro

94

AnlisisArtefactos

Las clases de entidad suelen mostrar unaestructura de datos lgica y contribuyen a

comprender de qu informacin depende el

sistema

Ejemplo:

Clase de entidad en un caso de uso


Antonio Navarro

95

AnlisisArtefactos

Las clases de control representan

coordinacin secuencia, transacciones ycontrol de otros objetos.

Se usan con frecuencia para encapsular elcontrol de un caso de uso en concreto

Tambin encapsulan procesamientoscomplejos que no pueden asociarse con una

clase entidad concreta


Antonio Navarro

96

AnlisisArtefactos

Los aspectos dinmicos del sistema se

modelan con clases de control, debido a queellas manejan y coordinan las acciones y los

flujos de control principales, y delegan

trabajo a otros objetos (de interfaz y/o

entidad)


25/41


Antonio Navarro

97

AnlisisArtefactos

Ejemplo:

Clase de control en un caso de uso


Antonio Navarro

98

AnlisisArtefactos

Una realizacin de caso de uso-anlisis esuna 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


Antonio Navarro

99

AnlisisArtefactos

Una realizacin de caso de uso-anlisis

contiene:- Descripcin textual del flujo de sucesos.

- Diagramas de clases.

- Diagramas de interaccin

Ejemplo:


Antonio Navarro

100

AnlisisArtefactos

Diagrama de clases de anlisis


26/41


Antonio Navarro

101

AnlisisArtefactos

Pagar factura


Antonio Navarro

102

AnlisisArtefactos

Lospaquetes de anlisisproporcionan unmedio 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.


Antonio Navarro

103

AnlisisArtefactos

Adems, sus caractersticas son:

- Pueden representar una separacin de interesesde anlisis.

- Deberan crearse en baso a los requisitos

funcionales y el dominio del problema.

- Probablemente se convertirn en subsistemas en

diseo.


Antonio Navarro

104

AnlisisArtefactos

La vista arquitectnica del modelo de

anlisis muestra los artefactos de anlisissignificativos 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.


27/41


Antonio Navarro

105

DiseoIntroduccin

En el diseo se modela el sistema y se leproporciona 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

106

DiseoIntroduccin

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.


Antonio Navarro

107

DiseoIntroduccin

- Ser capaces de descomponer los trabajos de

implementacin en partes ms manejables quepuedan ser llevadas a cabo por diferentes equipos

de desarrollo, teniendo en cuenta la posible

concurrencia.


Antonio Navarro

108

DiseoIntroduccin

Comparacin modelo anlisis y diseo


28/41


Antonio Navarro

109

DiseoEl papel del diseo

El diseo es el centro de atencin al final dela 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.


Antonio Navarro

110


Ms tarde, durante la fase de construccincuando 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 durantetodo el proceso de desarrollo


Antonio Navarro

111


El papel del diseo en el proceso de desarrolloIngeniera del Software

Antonio Navarro

112

DiseoArtefactos

El artefacto utilizado para capturar elanlisis es el modelo de diseo, formado

por:- Clases de diseo.

- Realizacin de caso de uso-diseo.

- Subsistema de diseo.

1 - Interfaz.

- Vista arquitectnica del modelo de diseo.

- Modelo de despliegue.- Vista arquitectnica del modelo de despliegue.


29/41


Antonio Navarro

113

DiseoArtefactos

El modelo de diseo es un modelo deobjetos 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


Antonio Navarro

114

DiseoArtefactos

Las caractersticas de las clases de diseoson:

- 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 traducendirectamente en implementacin.


Antonio Navarro

115

DiseoArtefactos

- 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.


Antonio Navarro

116

DiseoArtefactos

- Una clase de diseo puede realizar interfaces si

tiene sentido hacerlo en el lenguaje de

programacin.

- Una clase de diseo puede ser activa.

Ej.:

Clases de diseo


30/41


Antonio Navarro

117

DiseoArtefactos

Una realizacin de caso de uso-diseo esuna 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


Antonio Navarro

118

DiseoArtefactos

Una realizacin de caso de uso-diseo tiene:- 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 dediseo en piezas ms manejables


Antonio Navarro

119

DiseoArtefactos

Un subsistema puede constar de:

- Clases de diseo.- Realizaciones de caso de uso.

- Interfaces.

- Otros subsistemas.

Caractersticas de subsistemas:

- Deben ser cohesivos.

- Deben tener bajo acoplamiento.


Antonio Navarro

120

DiseoArtefactos

- 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.


31/41


Antonio Navarro

121

DiseoArtefactos

- 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 endiferentes nodos.


Antonio Navarro

122

DiseoArtefactos

Las interfaces se utilizan para especificarlas 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

123

DiseoArtefactos

Un subsistema que realice a un interfaz

debe contener tambin clases de diseo uotros 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


Antonio Navarro

124

DiseoArtefactos

Esta distincin hace independiente de la

implementacin de la interfaz a cualquiercliente 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

Di Di


32/41


Antonio Navarro

125

DiseoArtefactos

La vista arquitectnica del modelo dediseo muestra los artefactos relevantes

para la arquitectura de la aplicacin:

- Descomposicin del modelo en subsistemas, sus

interfaces y las dependencias entre ellos.

- Clases de diseo fundamentales.

- Realizaciones de casos de uso-diseo quedescriban alguna funcionalidad crtica


Antonio Navarro

126

DiseoArtefactos

Ejemplo:

Diagrama de clases de diseo


Antonio Navarro

127

DiseoArtefactos

Pagar factura Ingeniera del SoftwareAntonio Navarro

128

DiseoArtefactos

El modelo de despliegue es un modelo de

objetos que describe la distribucin fsicadel 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

Di Di


33/41


Antonio Navarro

129

DiseoArtefactos

Los nodos poseen relaciones querepresentan medios de comunicacin entre

ellos, tales comoInternet, intranet, bus y

similares

El modelo de despliegue puede describir

diferentes configuraciones de red, incluidas

las configuraciones para pruebas ysimulacin


Antonio Navarro

130

DiseoArtefactos

La funcionalidad (los procesos) de un nodose 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

131

DiseoArtefactos

La vista arquitectnica del modelo de

despliegue muestra los artefactos relevantesdel modelo de despliegue para su

arquitectura


Antonio Navarro

132

ImplementacinIntroduccin

En la implementacin empezamos con el

resultado del diseo e implementamos elsistema en trminos de componentes, es

decir, ficheros de cdigo fuente, scripts,

ficheros de cdigo binario, ejecutables y

similares

I l t i I l t i


34/41


Antonio Navarro

133

ImplementacinIntroduccin

Los propsitos de la implementacin son:

- Planificar las integraciones de sistema necesariasen cada iteracin.

- Distribuir el sistema asignando componentesejecutables a nodos en el diagrama de despliegue.

- Implementar las clases y subsistemasencontrados durante el diseo.

- Probar los componentes individualmente eintegrarlos.


Antonio Navarro

134

ImplementacinEl papel de la implementacin

La implementacin es el centro durante lasiteraciones de construccin.

Tambin se lleva a cabo trabajo deimplementacin durante la fase de elaboracin,para crear la lnea base ejecutable de laarquitectura

Durante la fase de transicin puede tratardefectos tardos


Antonio Navarro

135


Ya que el modelo de implementacin

denota la implementacin actual del sistemaen 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


Antonio Navarro

136


El papel de la implementacin en el proceso de desarrollo

Implementacin Implementacin


35/41


Antonio Navarro

137

ImplementacinArtefactos

El artefacto utilizado para capturar laimplementacin 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

138


El modelo de implementacin describecmo 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

139


Un componente es el empaquetamiento fsico delos elementos de un modelo, como son las

clases en el modelo de diseo Algunos estereotipos de componentes son:

-execut abl e es un programa ejecutable en un nodo.

-f i l e es un fichero que contiene cdigo fuente odatos.

-l i br ar y es una librera esttica o dinmica.

-t abl e es una tabla de una base de datos.-document es un documento.


Antonio Navarro

140


Los subsistemas de implementacinproporcionan una forma de organizar losartefactos del modelo de implementacin entrozos ms manejables

Un subsistema puede estar formado por:

- Componentes.

- Interfaces.

- Otros subsistemas.

Implementacin Implementacin


36/41


Antonio Navarro

141


Un subsistema de implementacin semanifiesta a travs de un mecanismo deempaquetamiento concreto en un entorno deimplementacin 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

142


Los subsistemas de implementacin estnmuy 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

143


- La descomposicin del modelo deimplementacin en subsistemas, sus interfaces ylas dependencias entre ellos.

- Componentes claves.

Elplan de integracin de construccionesdescribe la secuencia de construccionesnecesarias en una iteracin, es decir:

- La funcionalidad que se espera de laconstruccin.


Antonio Navarro

144


- Las partes del modelo de implementacin

afectadas por la construccin

Una construccin es una versin ejecutable

del sistema, usualmente, una parte

especfica del mismo.

En una iteracin puede haber una o ms

construcciones

Prueba Prueba


37/41


Antonio Navarro

145

PruebaIntroduccin

Durante la prueba se verifica el resultado dela implementacin probando cada

construccin, incluyendo tanto

construcciones internas como intermedias,

as como las versiones finales del sistema a

ser entregadas a terceros


Antonio Navarro

146

PruebaIntroduccin

Los objetivos de la prueba son:- 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.


Antonio Navarro

147

PruebaIntroduccin

- Realizar las diferentes pruebas y manejar los

resultados de cada prueba sistemticamente.


Antonio Navarro

148

PruebaEl papel de la prueba

Durante la fase de inicio puede hacerse

parte de la planificacin inicial de laspruebas 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

Prueba Prueba


38/41


Antonio Navarro

149


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.


Antonio Navarro

150


El papel de la prueba en el proceso de desarrollo


Antonio Navarro

151

PruebaArtefactos

El artefacto utilizado para capturar laprueba es el modelo de prueba, formadopor:

- Casos de prueba.

- Procedimientos de prueba.

- Componente de prueba.- Plan de prueba.

- Defecto.

- Evaluacin de prueba.


Antonio Navarro

152

PruebaArtefactos

Un caso de prueba especifica una forma de

probar el sistema, incluyendo la entrada oresultado 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

Prueba Prueba


39/41


Antonio Navarro

153

PruebaArtefactos

Casos de prueba comunes:

- Caso de prueba de un caso de uso.

- Caso de prueba de la realizacin de un caso deuso-diseo.

Un caso de prueba de caso de uso incluye:

- La verificacin del resultado de la interaccinentre los actores y el sistema.

- Que se satisfacen las pre y postcondiciones delcaso de uso.


Antonio Navarro

154

PruebaArtefactos

- Que se sigue la secuencia de acciones

especificadas por el caso de uso.

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

155

PruebaArtefactos

Un caso de prueba de la realizacin de uncaso de uso-diseo incluye:

- La verificacin de la interaccin entre loscomponentes que implementan dicho caso de uso.

Los casos de prueba basados en la larealizacin de un caso de uso tpicamenteespecifican una prueba del sistema como cajablanca, es decir, una prueba de la interaccininterna de los componentes del sistema


Antonio Navarro

156

PruebaArtefactos

Se pueden especificar otros casos de pruebapara probar el sistema como un todo:

- Pruebas de instalacin. Verifican que el sistemapuede ser instalado en la plataforma del cliente, yque el sistema funciona correctamente en dicha

plataforma.

- Pruebas de configuracin. Verifican que elsistema funciona correctamente en diferentes

configuraciones.

Prueba Prueba


40/41


Antonio Navarro

157

PruebaArtefactos

- 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

158

PruebaArtefactos

Elprocedimiento de prueba especificacmo realizar uno o varios casos de pruebao partes de stos

El componente de prueba automatiza uno ovarios procedimientos de prueba o partes dellos

Elplan de prueba describe las estrategias,recursos y planificacin


Antonio Navarro

159

PruebaArtefactos

La estrategia de prueba incluye:

- La definicin del tipo de pruebas a realizar paracada 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

160

PruebaArtefactos

Un defecto es una anomala del sistema.

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

C l i C l i


41/41


Antonio Navarro

161

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

162

Conclusiones

Requisitos

Anlisis

Diseo

Implementacin

Prueba

el proceso unificado de desarrollo de software - jacobson

Documents