El - Proceso - Unificado - de - Desarrollo - de - Software - Jacobson PDF

Índice
• Introducción
13. El proceso unificado de • Análisis y diseño orientado a objetos
desarrollo de software • Requisitos
– Captura de requisitos.
– Papel de los requisitos.
– Modelo del dominio.
– Modelo del negocio.
– Requisitos adicionales.
Ingeniería del Software 1 Ingeniería del Software 2
Antonio Navarro Antonio Navarro
Índice Índice
– Captura de requisitos como casos de uso. • Diseño
– Normas. – Introducción.
• Análisis – El papel de diseño.
– Artefactos.
– Introducción.
– El papel del análisis. • Implementación
– Introducción.
– Artefactos
– El papel de la implementación
– Artefactos

Índice Introducción
• Prueba • Proceso de Jacobson, Booch y Rumbaugh
– Introducción. • Los autores de UML
– El papel de la implementación. - Booch: método Booch.
– Artefactos. - Rumbaugh: OMT.
• Conclusiones - Jacobson: proceso Objectory.
• También conocido por RUP: Rational
Unified Process
Introducción Introducción
• Modelo basado en componentes - Componente: Una parte física y reemplazable de
- El sistema software está basado en componentes un sistema que se ajusta a, y proporciona la
software interconectados a través de interfaces realización de un conjunto de interfaces.
bien definidas. • Muy ligado a UML
- Interfaz: colección de operaciones que son • Discusión: ¿cómo diríamos esto en términos
utilizadas para especificar un servicio de una clase de las capas de IS?
o de un componente.

• Características: • Discusión: ¿todo modelo iterativo es
- Dirigido por casos de uso. incremental? ¿Y todo incremental es
- Centrado en la arquitectura. iterativo?
- Iterativo e incremental.
Proceso de
desarrollo de
Requisitos Sistema
software
usuario software
Un proceso de desarrollo de software

• Está formado por cinco flujos de trabajo Análisis
(i.e. AEs) que se iteran:
Requisitos
– Requisitos. Diseño
– Análisis.
– Diseño.
Prueba Implementación
– Implementación.
– Prueba.
El proceso unificado de desarrollo

• Cada vuelta en la espiral se denomina • Fase de inicio
iteración – Se desarrolla una descripción del producto
• La agrupación de iteraciones se denomina final.
fase • Fase de elaboración:
- Inicio.
– Se especifican los casos de uso.
- Elaboración.
– Se diseña la arquitectura del sistema.
- Construcción.
- Transición.

• Fase de construcción
– Se crea el producto.
• Fase de transición
– Periodo durante el cual el producto se convierte
en versión beta.
• No todos los flujos de trabajo tienen el
mismo peso dentro de cada fase
Relación entre flujos de trabajo y fases en RUP
• Las agrupaciones de fases se denominan
ciclo
• Cada ciclo concluye con una versión del
producto
• Discusión: ¿es lo mismo un ciclo RUP que
un ciclo del modelo en espiral?
Ciclos en RUP

Introducción Análisis y diseño OO

• Ventajas • Exactamente, ¿en qué consiste el análisis y
– Modelo de proceso racional. diseño orientado a objetos?
– Tecnologías de componentes. • Aunque vimos algunas definiciones,
• Inconvenientes veamos que definiciones proporciona el
– Muy ligado al método. Manual de Referencia de UML
– No incluye explícitamente actividades de
gestión.

Análisis y diseño OO Análisis y diseño OO
• Análisis es la etapa de un sistema que - El resultado de esta etapa se representa mediante
modelos del nivel de análisis, especialmente la
captura los requisitos y el dominio del vista de casos de uso y la vista estática.
problema. El análisis se centra en lo qué hay
• Diseño es la etapa de un sistema que
que hacer, mientras que el diseño se centra describe cómo se implementará el sistema
en cómo hacerlo. en un nivel lógico sobre código real.
- En un proceso iterativo estas etapas no tiene - En el diseño, las decisiones estratégicas y
porque realizarse de forma secuencial. tácticas se toman para resolver los requisitos
funcionales y de calidad requeridos de un sistema.


- Los resultados de esta etapa son representados • En Booch original, por ejemplo, en diseño
por los modelos a nivel de diseño, especialmente proporciona código.
la vista estática, vista de máquina de estados y
vista de interacción. • Pressman en diseño da la representación a
nivel de módulos de las clases
• Sin embargo, en el modelo de proceso
unificado, la salida del análisis es la • Sommerville identifica:
especificación de los diagramas de casos de - Análisis OO: centrado en desarrollar un modelo
uso a diagramas de interacción entre clases OO del dominio de la aplicación. Los objetos
identificados reflejan las entidades y operaciones
de análisis asociadas con el problema a resolver.
ANÁLISIS
- Diseño OO: centrado en desarrollar un modelo

OO del sistema software para implementar los Clases
requisitos identificados. Los objetos en el diseño Especificación
de requisitos
Casos de
uso Actividades Estados
están relacionados con la solución al problema que Interacción
se está resolviendo. DISEÑO

Componentes
• Con independencia de lo que digan los

Código Despliegue
libros nosotros debemos generar:

Requisitos
Análisis y diseño OO
Captura 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 forma
separada:
- Enumerar los requisitos candidatos.
- Comprender el contexto del sistema.
Relación entre flujos de trabajo y fases en RUP
- Capturar los requisitos funcionales.
- Capturar los requisitos no funcionales.
Requisitos Requisitos
Captura de requisitos Captura de requisitos
• Enumerar los requisitos candidatos consiste - Prioridad (crítico, importante o secundario).
en identificar todos los posibles requisitos que - Nivel de riesgo asociado a la implementación de la
son susceptibles de ser implementados por el característica (crítico, significativo u ordinario).
sistema - Esta información sirve para:
- Estos requisitos forman la lista de características, - Estimar el tamaño del proyecto.
en la cual, además del requisito (característica) - Decidir cómo dividir el proyecto en una secuencia de
incluye: iteraciones
- Estado (propuesto, aprobado, incluido o validado).
- Coste estimado de implementación (tipos de recursos y
esfuerzo).
Captura de requisitos Captura de requisitos
• Comprender el contexto del sistema, es • Capturar requisitos funcionales identifica
decir, el dominio de la aplicación los requisitos funcionales utilizando los
- Con este fin se proporcionará un: casos de uso
- Modelo del dominio, que describe los conceptos - Además de los casos de uso, los analistas deben
importantes del contexto como objetos del dominio y especificar la apariencia de la interfaz de usuario.
enlaza estos objetos entre si.
• Capturar requisitos no funcionales identifica
- Modelo del negocio, que describe los procesos
(existentes u observados) con el objetivo de propiedades del sistema:
comprenderlos. - Restricciones del entorno.
Captura de requisitos El papel de los requisitos
- Restricciones de implementación. • El papel de los requisitos depende de la fase
- Rendimiento. de desarrollo del software en la que nos
- Dependencias de la plataforma. encontremos
- Facilidad de mantenimiento. • Durante la fase de inicio, los analistas
- Extensibilidad. identifican la mayoría de los casos de uso
- Fiabilidad. para delimitar el sistema y el alcance del
- Otros. proyecto y para detallar los más importantes
(menos del 10%)
El papel de los requisitos El papel de los requisitos
• Durante la fase de elaboración, los analistas • Los requisitos restantes se capturan e
capturan la mayoría de los requisitos implementan durante la fase de
restantes para que los desarrolladores construcción
puedan estimar el tamaño del esfuerzo de • Casi no hay captura de requisitos en la fase
desarrollo que se requerirá de transición, a menos que haya requisitos
- El objetivo es haber capturado un 80% de los que cambien
requisitos y haber descrito la mayoría de los casos
de uso.

El papel de los requisitos Modelo del dominio
• Un modelo del dominio captura los tipos
más 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
Modelo del dominio Modelo del dominio
• Muchos de los objetos del dominio o clases - Objetos del mundo real y conceptos de los que el
pueden obtenerse de una especificación de sistema debe hacer un seguimiento, como la
requisitos o mediante la entrevista con los aviación enemiga, misiles y trayectorias.
expertos del dominio - Sucesos que ocurrirán o han ocurrido, como la
• Las clases del dominio aparecen en tres llegada de un avión, su salida y la hora de la
formas típicas: comida.
- Objetos del negocio, que representan cosas que • El modelo del dominio se describe mediante
se manipulan en el negocio, como pedidos, diagramas UML (especialmente de clases)
cuentas, contratos, etc.
• Ejemplo: • 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 más
importantes dentro del contexto del sistema
Modelo del dominio

• Los dominios de tamaño moderado • En dominios muy pequeños, no es necesario
normalmente requieren entre 10 y 50 de desarrollar un modelo de objetos para el
estas clases dominio; en su lugar puede ser suficiente un
• Las restantes clases candidatas que los glosario de términos
analistas pueden extraer del dominio se • El modelo del dominio proporciona un
guardan como definiciones en un glosario vocabulario común a clientes y
de términos desarrolladores

• El objetivo del modelado del dominio es • El modo interno por el cual el sistema
contribuir a la comprensión del contexto del resuelve este problema se tratará en los
sistema, y por extensión de los requisitos flujos de trabajo de análisis, diseño e
que se desprenden de este contexto implementación
• Las clases del dominio y el glosario de
• Es decir, el modelo del dominio contribuye términos se utilizan en el desarrollo de los
a una comprensión del problema que el modelos de casos de uso y análisis:
sistema resuelve en relación a su contexto - Al describir los casos de uso y al diseñar la
interfaz de usuario.
Modelo del dominio Modelo del negocio
- Para sugerir clases internas al sistema de • El modelado del negocio es una técnica para
desarrollo durante el análisis. comprender los procesos de negocio de la
• También podemos concebir al modelo del organización
dominio como un caso especial de un • Se debe modelar el sistema del
modelo del negocio más completo negocio/entidad que rodea al sistema software
a desarrollar

Modelo del negocio Modelo del negocio
• El modelado del negocio está soportado por • El modelo de casos de uso del negocio
dos tipos de modelos UML: modelos de casos presenta un sistema desde la perspectiva de
de uso y modelos de objetos su uso, y esquematiza cómo proporciona
• El modelo de casos de uso del negocio valor a sus usuarios
describe los procesos de negocio de una
• Por ejemplo, en el contexto de un consorcio
empresa en términos de casos de uso del
negocio y actores del negocio que se de compras y ventas, podemos considerar
corresponden con los procesos del negocio y un caso de uso del negocio que comprende
los clientes, respectivamente. la venta desde el pedido a la entrega
- El proceso de venta es el siguiente: • El modelo de casos de uso del negocio se describe
1. El comprador hace el pedido de bienes o servicios. mediante diagramas de casos de uso.
2. El vendedor entrega los bienes o servicios. • Un modelo de objetos del negocio es un modelo
3. El vendedor envía la factura al comprador. interno a un negocio
4. El comprador paga. • Describe cómo cada caso de uso de negocio es
- En este contexto, el comprador y el vendedor son llevado a cabo por parte de un conjunto de
los actores del negocio, y utilizan el caso de uso de trabajadores que utilizan un conjunto de entidades
negocio que la entidad les proporciona. del negocio y unidades de trabajo.

• Cada realización de un caso de uso del • Un unidad de trabajo es un conjunto de
negocio puede mostrase en diagramas de esas entidades que conforma un todo
interacción y diagramas de actividad reconocible para un usuario final
• Una entidad del negocio representa algo, • Las entidades den negocio y las unidades de
como una factura, que los trabajadores trabajo se utilizan para representar los
toman, inspeccionan, manipulan, producen mismos tipos de conceptos que las clases
o utilizan en un caso de uso del negocio del dominio como Pedido, Articulo,
Factura y Cuenta
• Por tanto, podemos confeccionar un • Ejemplo:
diagrama de las entidades del negocio, muy
parecido modelo del dominio
• También tendremos otros diagramas para
mostrar los trabajadores, sus interacciones,
y cómo utilizan las entidades de negocio y
las unidades de trabajo
Interacciones en el modelo del negocio
• Cada trabajador, entidad del negocio, y 2. Desarrollar un modelo de objetos del negocio
unidad de trabajo pueden participar en la compuesto por trabajadores, entidades del negocio y
realización de más de un caso de uso del unidades de trabajo que juntos realizan los casos de
negocio uso del negocio.
• El modelo del negocio se desarrolla en dos • Nótese que el modelo del dominio se puede
pasos: ver como una variante simplificad del modelo
del negocio, en la cual nos centramos sólo en
1. Desarrollar un modelo de casos de uso del
negocio que identifique a los actores del negocio y las “cosas”, es decir, en las clases del del
los casos de uso. dominio o entidades del negocio
• Por tanto, las clases del dominio y las - Las clases del dominio se obtienen del
entidades del negocio son conceptos muy conocimiento de expertos del dominio o del
parecidos, y utilizamos ambos términos conocimiento de sistemas similares. Las entidades
indistintamente del negocio se derivan a partir de los clientes,
• Sin embargo existen algunas diferencias identificando los casos de uso del negocio y
importantes entre el modelado del negocio y buscando después las entidades.
el modelado del dominio que hacen mucho
más recomendable realizar el modelado del
negocio
- Las clases del dominio tienen atributos pero - Los trabajadores identificados en el modelado
normalmente ninguna o muy pocas operaciones. del negocio se utilizan como punto de partida para
Por el contrario, las entidades del negocio incluye derivar un primer conjunto de actores y casos de
información de cómo utilizan estas entidades los uso para el sistema de información en
trabajadores que participan en la realización de los construcción.
casos de uso del negocio.

Requisitos adicionales Requisitos adicionales
• Los requisitos adicionales son • Los requisitos adicionales podemos
fundamentalmente requisitos no funcionales clasificarlos en:
que no pueden asociarse a ningún caso de - Requisitos de interfaz. Especifican la interfaz con
uso concreto, pero que sí pueden a afectar a un elemento externo con el cual debe interactuar el
varios o ningún caso de uso sistema, o establecen restricciones condicionantes
en formatos, tiempos u otros factores relevantes en
• Los requisitos adicionales se capturan esa interacción.
mediante una lista de requisitos, que se
tiene en cuenta durante análisis y diseño
Requisitos adicionales Requisitos adicionales
- Requisitos físicos. Especifican una característica - Restricciones de implementación. Especifican o
física que debe poseer un sistema, como su limitan la codificación o construcción de un
material, forma, tamaño o peso. sistema, tales como estándares requeridos, normas
- Restricciones de diseño. Limitan el diseño de un de codificación, lenguajes de programación, etc.
sistema, como lo hacen las restricciones de - Otros requisitos. Tales como los legales y las
extensibilidad y mantenibilidad, o las restricciones normativas
relativas a la reutilización de sistemas heredados o
partes esenciales de los mismos.

Captura de los requisitos ... Captura de los requisitos ...
• Los casos de uso proporcionan un medio • Ej.:
intuitivo y sistemático para capturar los
Casos de uso
requisitos funcionales, con un énfasis
en un sistema
especial en el valor añadido para cada de Pagos y
usuario individual o para cada sistema Facturación
externo
• Además, sirven como guía para el proceso
de desarrollo
Captura de los requisitos ... Captura de los requisitos ...
• Como ya hemos comentado, los diagramas • Ejemplo:
de actividades o de interacción pueden
especificar a los casos de uso
• Además, durante este proceso se
proporciona la caracterización de la interfaz
de usuario, bien mediante dibujos en papel,
bien mediante prototipos de dicha interfaz
Caracterización de la IGU
Captura de los requisitos ... Normas
• EL artefactos utilizado para capturar los • Podemos considerar las siguientes normas:
casos de uso es el modelo de casos de uso, - Los casos de uso deben mantenerse tan
formado por: independientes los unos de otros como sea posible.
- Actores UML. - Los casos de uso deben describirse utilizando el
- Casos de uso UML. lenguaje del cliente.
- Cada caso de uso debe estructurarse para que
forme una especificación de funcionalidad
completa e intuitiva.

Análisis Análisis
• Durante el análisis se estudian los • Durante el análisis, los casos de uso deben
requisitos, refinándolos y estructurándolos representarse desde la perspectiva de los
• El objetivo es conseguir un comprensión desarrolladores
más precisa de los requisitos y una • Además, ahora la vista se centra en el
descripción de los mismos que sea fácil de sistema, y no en el problema
mantener y que ayude a estructurar el • Comparativamente:
sistema

Análisis Análisis
• Analizar los requisitos en forma de un
modelo de análisis es importante, ya que:
- Un modelo de análisis ofrece una especificación
más precisa de los requisitos que el modelo de
casos de uso.
- Un modelo de análisis se describe utilizando el el
lenguaje de los desarrolladores, y puede por tanto
introducir un mayor formalismo y ser utilizado
Comparación entre requisitos y análisis para razonar sobre el funcionamiento interno del
sistema.
Análisis Análisis
Introducción El papel del análisis
• Un modelo de análisis estructura los requisitos • El papel del análisis depende de la fase de
de un modo que facilita su comprensión, su desarrollo del software en la que nos
preparación, su modificación, y en general, su encontremos
mantenimiento • Las iteraciones iniciales de elaboración se
centran en el análisis
• Un modelo de análisis puede considerarse
como una primera aproximación al modelo de • Más adelante, al término de la fase de
elaboración y durante la construcción el
diseño, aunque es un modelo por sí mismo. énfasis pasa a diseño e implementación

Análisis Análisis
El papel del análisis El papel del análisis
• Además, hay tres formas diferentes de - El proyecto no utiliza en absoluto el modelo de
considerar al modelo de análisis: análisis para describir los resultados del análisis.
El proyecto concibe los requisitos como parte
- Para describir los resultados del análisis y
integrada de la captura de requisitos o en el
mantener la consistencia de este modelo durante
diseño. Suele aplicarse en el caso de tratarse de
todo el ciclo de vida del software.
sistemas simples
- Para describir los resultados del análisis,
considerando a este modelo como una herramienta
transitoria e intermedia hasta el diseño.

Análisis Análisis
El papel del análisis Artefactos
• El artefacto utilizado para capturar el
análisis es el modelo de análisis, formado
por:
- Clases de análisis.
- Realizaciones de casos de uso.
- Paquetes de análisis.
- Vista arquitectónica del modelo de análisis.
El papel del análisis en el proceso

Análisis Análisis
Artefactos Artefactos
• Una clase de análisis representa una - Esto hace que una clase de análisis se más
evidente en el contexto del dominio del problema,
abstracción de una o varias clases y/o menos específica que sus contrapartidas en diseño
subsistemas del diseño del sistema. Posee e implementación.
las siguientes características: - Una clase de análisis raramente define u ofrece
- Una clase de análisis se centra en el tratamiento una interfaz en términos de operaciones y de sus
de los requisitos funcionales y pospone los no signaturas. Su comportamiento se define mediante
funcionales, hasta llegar a las actividades de responsabilidades en un nivel más alto y menos
formal. Una responsabilidad es una descripción
diseño e implementación.
textual del comportamiento de una clase.
Análisis Análisis
- Una clase de análisis define atributos, aunque - Una clase de análisis participa en relaciones,
esos atributos también son de un nivel bastante aunque esas relaciones son más conceptuales que
alto. Normalmente los tipos de esos atributos son sus contrapartidas de diseño. Por ejemplo, la
conceptuales y reconocibles en el dominio del navegabilidad de las asociaciones no es vital en
problema, mientras que en diseño suelen ser tipos. análisis, pero sí en diseño.
Con frecuencia, los atributos identificados durante - Las clases de análisis están estereotipadas en tres
el análisis pasan a ser clases durante el diseño. tipos, mientras que es más difícil estereotipar las
clases de diseño.

Análisis Análisis
• Los estereotipos de clases de análisis • Las clases de interfaz se utilizan para
son: modelar la interacción entre el sistema y sus
– Clase de interfaz.
<<boundary>>
actores
nombre
nombre
• Esta interacción a menudo implica recibir
– Clase de control. <<control>>
nombre
información y peticiones de y hacia los
nombre
usuarios y los sistemas externos
– Clase de entidad. <<entity>>
nombre
nombre

Análisis Análisis
• Las clases de interfaz modelan las partes del • No es necesario que describan cómo se
sistema que dependen de sus actores, lo cual ejecuta físicamente la interacción,
implica que clarifican y reúnen los actividades de diseño.
requisitos en los límites del sistema • Ejemplo:
• A menudo representan abstracciones de
ventanas, formularios, paneles, interfaces de
comunicación, etc.
Una clase de interfaz
Análisis Análisis
• Las clases de entidad se utilizan para • En la mayoría de los casos, las clases de
modelar información que posee una vida entidad se derivan directamente de una
larga y que a menudo es persistente clase de entidad del negocio (o de una clase
• Modelan la información y el del dominio). Sin embargo, las clases
comportamiento asociado de algún entidad representan objetos manejados por
fenómeno o concepto, como una persona, el sistema en consideración y no del
un objeto del mundo real, o un suceso del negocio
mundo real
Análisis Análisis
• Por lo tanto, las clases de entidad reflejan la • Las clases de entidad suelen mostrar una
información de tal forma que indica como estructura de datos lógica y contribuyen a
diseñar el sistema, incluyendo el soporte de comprender de qué información depende el
persistencia sistema
• Un objeto de entidad no ha de ser • Ejemplo:
necesariamente pasivo y puede tener en
ocasiones un comportamiento relativo a la
información que representa
Ingeniería del Software
Antonio Navarro
93 Ingeniería del Software
Antonio Navarro
Clase de entidad en un caso de uso 94
Análisis Análisis
• Las clases de control representan • Los aspectos dinámicos del sistema se
coordinación secuencia, transacciones y modelan con clases de control, debido a que
control de otros objetos. ellas manejan y coordinan las acciones y los
• Se usan con frecuencia para encapsular el flujos de control principales, y delegan
control de un caso de uso en concreto trabajo a otros objetos (de interfaz y/o
• También encapsulan procesamientos entidad)
complejos que no pueden asociarse con una
clase entidad concreta

Análisis Análisis
• Ejemplo: • Una realización de caso de uso-análisis es
una colaboración dentro del modelo de
análisis que describe cómo se lleva a cabo y
se ejecuta un caso de uso determinado en
términos de las clases de análisis y sus
objetos de análisis en interacción
Clase de control en un caso de uso

Análisis Análisis
• Una realización de caso de uso-análisis
contiene:
- Descripción textual del flujo de sucesos.
- Diagramas de clases.
- Diagramas de interacción
• Ejemplo:
Diagrama de clases de análisis

Análisis Análisis
• Los paquetes de análisis proporcionan un
medio para organizar los artefactos del
modelo de análisis en piezas manejables
• Pueden contener:
- Clases de análisis.
- Realizaciones de casos de uso.
- Otros paquetes de análisis.
Pagar factura

Análisis Análisis
• Además, sus características son: • La vista arquitectónica del modelo de
- Pueden representar una separación de intereses análisis muestra los artefactos de análisis
de análisis. significativos para la arquitectura:
- Deberían crearse en baso a los requisitos - Descomposición en paquetes de análisis y sus
funcionales y el dominio del problema. dependencias.
- Probablemente se convertirán en subsistemas en - Clases fundamentales de análisis.
diseño. - Realizaciones de casos de uso que describen una
funcionalidad crítica o importante.
Diseño Diseño
• En el diseño se modela el sistema y se le • Los objetivos del diseño son:
proporciona su forma para que soporte - Adquirir una comprensión en profundidad de los
todos los requisitos aspectos relacionados con los requisitos no
funcionales y restricciones técnicas.
• Una entrada fundamental del diseño es el
modelo de análisis, que proporciona una - Crear una entrada apropiada y un punto de
partida para actividades de implementación
comprensión detallada de los requisitos e
subsiguientes.
impone una estructura al sistema

Diseño Diseño
- Ser capaces de descomponer los trabajos de
implementación en partes más manejables que
puedan ser llevadas a cabo por diferentes equipos
de desarrollo, teniendo en cuenta la posible
concurrencia.
Ingeniería del Software 107

Comparación modelo análisis y diseño
Ingeniería del Software 108
Diseño Diseño
El papel del diseño El papel del diseño
• El diseño es el centro de atención al final de • Más tarde, durante la fase de construcción
la fase de elaboración y el comienzo de las cuando la arquitectura es estable y los
iteraciones de construcción requisitos están bien entendidos, el centro
• Esto contribuye a una arquitectura estable y de atención se desplaza a implementación
sólida y a crear un plano del modelo de • El modelo de diseño está muy ligado al de
implementación. implementación, por lo que se suele
mantener actualizado al modelo durante
todo el proceso de desarrollo
Diseño Diseño
El papel del diseño Artefactos
• El artefacto utilizado para capturar el
análisis es el modelo de diseño, formado
por:
- Clases de diseño.
- Realización de caso de uso-diseño.
- Subsistema de diseño.
1 - Interfaz.
- Vista arquitectónica del modelo de diseño.
- Modelo de despliegue.
El papel del diseño en el proceso de desarrollo - Vista arquitectónica del modelo de despliegue.
Diseño Diseño
• El modelo de diseño es un modelo de • Las características de las clases de diseño
objetos que describe la realización física de son:
los casos de uso centrándose en el impacto - El lenguaje de especificación de la clase coincide
en el sistema de los requisitos con el de implementación.
• La clase de diseño es una abstracción de - Normalmente se especifica la visibilidad de los
una clase o construcción similar en la atributos.
implementación - Las relaciones entre clases de diseño se traducen
directamente en implementación.

Diseño Diseño
- Los métodos de una clase de diseño tienen - Una clase de diseño puede realizar interfaces si
correspondencia directa con el código. tiene sentido hacerlo en el lenguaje de
- Una clase de diseño puede posponer decisiones programación.
que son inapropiadas de manejar en el modelo de - Una clase de diseño puede ser activa.
diseño. • Ej.:
- Una clase de diseño se puede corresponder con
clases existentes en el lenguaje de
implementación.
Ingeniería del Software 115 Ingeniería del Software Clases de diseño 116
Diseño Diseño
• Una realización de caso de uso-diseño es • Una realización de caso de uso-diseño tiene:
una colaboración en el modelo de diseño - Una descripción del flujo de eventos textual.
que describe cómo se realiza un caso de uso - Diagramas de clases de diseño.
específico, y cómo se ejecuta, en términos - Diagramas de interacción entre objetos de
de clases de diseño y sus objetos diseño.
• Se construyen sobre los casos de uso de • Los subsistemas de diseño son una forma de
análisis organizar los artefactos del modelo de
diseño en piezas más manejables
Diseño Diseño
• Un subsistema puede constar de: - Pueden representar una separación de aspectos
- Clases de diseño. del diseño.
- Realizaciones de caso de uso. - Suelen tener relaciones con las clases y/o
- Interfaces. paquetes de análisis.
- Otros subsistemas. - Pueden representar productos software
• Características de subsistemas: reutilizados que han sido encapsulados en ellos.
- Deben ser cohesivos. - Pueden representar sistemas heredados (o parte
- Deben tener bajo acoplamiento. de ellos) encapsulándolos.

Diseño Diseño
- Los subsistemas pueden representar componentes • Las interfaces se utilizan para especificar
de grano grueso en la implementación del sistema, las operaciones que proporcionan las clases
es decir, componentes que proporcionan varios y los subsistemas de diseño
interfaces compuestos a partir de otros componentes
de grano más fino, como los que especifican clases • Una clase de diseño que realice una interfaz
de implementación individuales, y que se convierten debe proporcionar métodos que realicen las
ellos mismos en ejecutables, ficheros binarios o operaciones del interfaz
entidades similares que pueden distribuirse en
diferentes nodos.
Diseño Diseño
• Un subsistema que realice a un interfaz • Esta distinción hace independiente de la
debe contener también clases de diseño u implementación de la interfaz a cualquier
otros subsistemas que realicen la interfaz cliente que dependa de ella
• Las interfaces constituyen una forma de • Así, podemos sustituir una implementación
separar la especificación de la funcionalidad concreta de una interfaz, como puede ser
en términos de operaciones de sus una clase o un subsistema de diseño, por
implementaciones términos de métodos otra implementación sin tener que cambiar
los clientes
Diseño Diseño
• La vista arquitectónica del modelo de • Ejemplo:
diseño muestra los artefactos relevantes
para la arquitectura de la aplicación:
- Descomposición del modelo en subsistemas, sus
interfaces y las dependencias entre ellos.
- Clases de diseño fundamentales.
- Realizaciones de casos de uso-diseño que
describan alguna funcionalidad crítica
Ingeniería del Software 125 Ingeniería del Software
Diagrama de clases de diseño 126
Diseño Diseño
• El 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
• Cada nodo representa un recurso de
cómputo, normalmente un procesador o
dispositivo hardware similar
Ingeniería del Software Pagar factura 127 Ingeniería del Software 128
Diseño Diseño
• Los nodos poseen relaciones que • La funcionalidad (los procesos) de un nodo
representan medios de comunicación entre se definen por los componentes que se
ellos, tales como Internet, intranet, bus y distribuyen sobre ese nodo
similares • El modelo de despliegue en sí mismo
• El modelo de despliegue puede describir representa una correspondencia entre la
diferentes configuraciones de red, incluidas arquitectura software y la arquitectura del
las configuraciones para pruebas y sistema (el hardware)
simulación
Diseño Implementación
Artefactos Introducción
• La vista arquitectónica del modelo de • En la implementación empezamos con el
despliegue muestra los artefactos relevantes resultado del diseño e implementamos el
del modelo de despliegue para su sistema en términos de componentes, es
arquitectura decir, ficheros de código fuente, scripts,
ficheros de código binario, ejecutables y
similares

Implementación Implementación
Introducción El papel de la implementación
• Los propósitos de la implementación son: • La implementación es el centro durante las
- Planificar las integraciones de sistema necesarias iteraciones de construcción.
en cada iteración. • También se lleva a cabo trabajo de
- Distribuir el sistema asignando componentes implementación durante la fase de elaboración,
ejecutables a nodos en el diagrama de despliegue. para crear la línea base ejecutable de la
- Implementar las clases y subsistemas arquitectura
encontrados durante el diseño.
• Durante la fase de transición puede tratar
- Probar los componentes individualmente e
integrarlos. defectos tardíos

El papel de la implementación El papel de la implementación
• Ya que el modelo de implementación
denota la implementación actual del sistema
en términos de componentes y subsistemas
de implementación, es natural mantener el
modelo de implementación a lo largo de
todo el ciclo de vida del software
El papel de la implementación en el proceso de desarrollo

• El artefacto utilizado para capturar la • El modelo de implementación describe
implementación es el modelo de cómo los elementos del modelo de diseño,
implementación, formado por: como las clases, se implementan en
- Componentes. términos de componentes, como ficheros de
- Subsistemas de implementación. código fuente, ejecutables, etc.
- Interfaces. • También describe cómo se organizan los
- Visión arquitectónica del modelo de implementación. componentes y sus dependencias
- Plan de integración de construcciones.
• Un componente es el empaquetamiento físico de
los elementos de un modelo, como son las • Los subsistemas de implementación
clases en el modelo de diseño proporcionan una forma de organizar los
artefactos del modelo de implementación en
• Algunos estereotipos de componentes son: trozos más manejables
- executable es un programa ejecutable en un nodo.
• Un subsistema puede estar formado por:
- file es un fichero que contiene código fuente o
datos. - Componentes.
- library es una librería estática o dinámica. - Interfaces.
- table es una tabla de una base de datos. - Otros subsistemas.
- document es un documento.
• Un subsistema de implementación se • Los subsistemas de implementación están
manifiesta a través de un mecanismo de muy ligados a los subsistemas de diseño
empaquetamiento concreto en un entorno de
implementación determinado, tales como: • Los interfaces de implementación se
corresponden con los interfaces de diseño
- Un paquete Java.
- Un proyecto Visual Basic. • La visión arquitectónica del modelo de
- Un directorio de ficheros en un proyecto C++. implementación representa los artefactos
- Un paquete en una herramienta Rational Rose. significativos arquitectónicamente:

- La descomposición del modelo de - Las partes del modelo de implementación
implementación en subsistemas, sus interfaces y afectadas por la construcción
las dependencias entre ellos.
• Una construcción es una versión ejecutable
- Componentes claves.
del sistema, usualmente, una parte
• El plan de integración de construcciones específica del mismo.
describe la secuencia de construcciones
necesarias en una iteración, es decir: • En una iteración puede haber una o más
- La funcionalidad que se espera de la construcciones
construcción.
Prueba Prueba
• Durante la prueba se verifica el resultado de • Los objetivos de la prueba son:
la implementación probando cada - Planificar las pruebas necesarias en cada
construcción, incluyendo tanto iteración, incluidas las de integración y sistema.
construcciones internas como intermedias, Las pruebas de integración son necesarias para
así como las versiones finales del sistema a cada construcción dentro de la iteración, mientras
que las pruebas de sistema son necesarias sólo al
ser entregadas a terceros
final de la iteración.
- Diseñar e implementar las pruebas.

Prueba Prueba
Introducción El papel de la prueba
- Realizar las diferentes pruebas y manejar los • Durante la fase de inicio puede hacerse
resultados de cada prueba sistemáticamente. parte de la planificación inicial de las
pruebas cuando se define el ámbito del
sistema.
• Sin embargo, las pruebas se llevan a cabo
sobre todo cuando una construcción es
sometida a pruebas de integración y de
sistema
Prueba Prueba
El papel de la prueba El papel de la prueba
• Por tanto, la realización de pruebas se
centra en las fases de elaboración y
construcción.
• Durante la fase de transición la prueba sirve
para la corrección de defectos durante los
primeros usos.
El papel de la prueba en el proceso de desarrollo

Prueba Prueba
• El artefacto utilizado para capturar la • Un caso de prueba especifica una forma de
prueba es el modelo de prueba, formado probar el sistema, incluyendo la entrada o
por: resultado con la que se ha de probar y las
- Casos de prueba. condiciones bajo las que ha de probarse
- Procedimientos de prueba.
• Lo que se prueba puede venir dado por un
- Componente de prueba.
- Plan de prueba. requisito o colección de requisitos del
- Defecto. sistema
- Evaluación de prueba.
Prueba Prueba
• Casos de prueba comunes: - Que se sigue la secuencia de acciones
- Caso de prueba de un caso de uso. especificadas por el caso de uso.
- Caso de prueba de la realización de un caso de • Un caso de prueba basado en un caso de uso
uso-diseño. especifica típicamente una prueba del
• Un caso de prueba de caso de uso incluye: sistema como caja negra, es decir, una
- La verificación del resultado de la interacción prueba del comportamiento observable
entre los actores y el sistema.
externamente del sistema
- Que se satisfacen las pre y postcondiciones del
caso de uso.
Prueba Prueba
• Un caso de prueba de la realización de un • Se pueden especificar otros casos de prueba
caso de uso-diseño incluye: para probar el sistema como un todo:
- La verificación de la interacción entre los - Pruebas de instalación. Verifican que el sistema
componentes que implementan dicho caso de uso. puede ser instalado en la plataforma del cliente, y
• Los casos de prueba basados en la la que el sistema funciona correctamente en dicha
plataforma.
realización de un caso de uso típicamente
especifican una prueba del sistema como caja - Pruebas de configuración. Verifican que el
sistema funciona correctamente en diferentes
blanca, es decir, una prueba de la interacción configuraciones.
interna de los componentes del sistema
Prueba Prueba
- Pruebas negativas. Intentan provocar que el • El procedimiento de prueba especifica
sistema falle para poder así revelar sus cómo realizar uno o varios casos de prueba
debilidades. Se intenta probar el sistema en formas o partes de éstos
para los que no ha sido diseñado. • El componente de prueba automatiza uno o
- Pruebas de tensión o estrés. Identifican varios procedimientos de prueba o partes d
problemas con el sistema cuando hay recursos ellos
insuficientes o cuando hay competencia por los
• El plan de prueba describe las estrategias,
recursos
recursos y planificación

Prueba Prueba
• La estrategia de prueba incluye: • Un defecto es una anomalía del sistema.
- La definición del tipo de pruebas a realizar para • Una evaluación de prueba es una evaluación
cada iteración y sus objetivos. de los resultados de los esfuerzos de prueba
- El nivel de cobertura de prueba y de código
necesario.
- El porcentaje de pruebas que deberían ejecutarse
con un resultado específico.

Conclusiones Conclusiones
• Proceso unificado de desarrollo • Requisitos
• Ventaja: especifica los diagramas UML que • Análisis
hay que generar en cada actividad • Diseño
estructural • Implementación
• Inconveniente: muy ligada al método • Prueba
• Análisis y diseño OO


El - Proceso - Unificado - de - Desarrollo - de - Software - Jacobson PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

El - Proceso - Unificado - de - Desarrollo - de - Software - Jacobson PDF

Cargado por

Copyright:

Formatos disponibles

Índice

Ingeniería del Software 3 Ingeniería del Software 4

Ingeniería del Software 7 Ingeniería del Software 8

Un proceso de desarrollo de software

Ingeniería del Software 11 Ingeniería del Software 12

Ingeniería del Software 13 Ingeniería del Software 14

Ingeniería del Software 17 Ingeniería del Software 18

Introducción Análisis y diseño OO

Ingeniería del Software 19 Ingeniería del Software 20

Ingeniería del Software 21 Ingeniería del Software 22

Análisis y diseño OO Análisis y diseño OO

- Diseño OO: centrado en desarrollar un modelo

están relacionados con la solución al problema que Interacción

se está resolviendo. DISEÑO

• Con independencia de lo que digan los

Ingeniería del Software 25 Ingeniería del Software 26

Ingeniería del Software 35 Ingeniería del Software 36

Modelo del dominio

Ingeniería del Software 43 Ingeniería del Software 44

Ingeniería del Software 47 Ingeniería del Software 48

Ingeniería del Software 51 Ingeniería del Software 52

Ingeniería del Software 61 Ingeniería del Software 62

Ingeniería del Software 65 Ingeniería del Software 66

Ingeniería del Software 71 Ingeniería del Software 72

Ingeniería del Software 73 Ingeniería del Software 74

Ingeniería del Software 77 Ingeniería del Software 78

Ingeniería del Software 79 Ingeniería del Software 80

El papel del análisis en el proceso

Ingeniería del Software 85 Ingeniería del Software 86

Ingeniería del Software 87 Ingeniería del Software 88

Ingeniería del Software 95 Ingeniería del Software 96

Clase de control en un caso de uso

Ingeniería del Software 99 Ingeniería del Software 100

Ingeniería del Software 101 Ingeniería del Software 102

Ingeniería del Software 105 Ingeniería del Software 106

Ingeniería del Software 107

Ingeniería del Software 113 Ingeniería del Software 114

Ingeniería del Software 119 Ingeniería del Software 120

Ingeniería del Software 131 Ingeniería del Software 132

Ingeniería del Software 133 Ingeniería del Software 134

El papel de la implementación en el proceso de desarrollo

Ingeniería del Software 141 Ingeniería del Software 142

Ingeniería del Software 145 Ingeniería del Software 146

El papel de la prueba en el proceso de desarrollo

Ingeniería del Software 157 Ingeniería del Software 158

Ingeniería del Software 159 Ingeniería del Software 160

Ingeniería del Software 161 Ingeniería del Software 162

También podría gustarte