Unidad 2.

Modelado y Diseño Orientado a Objetos

Unidad 2.1: Introducción a la Orientación a Objetos.

La crisis del Software: origen y justificación de la

Orientación a Objetos.
En 1968 cuando en la primera conferencia elaborada por la OTAN se habló por
primera vez del conjunto de dificultades o errores ocurridos en la
planificación, estimación de los costos, productividad y calidad de un software,
o bien, lo que se conoce como la crisis del software.
En los años ‘60s las personas empezaban a notar que las técnicas que se
utilizaban para programar habían quedado obsoletas, incluso algunos todavía
creían que la programación de software debía considerarse un arte, como una
actividad que debía ser más creativa que tradicional y disciplinada. Otro de los
problemas es que muchos programadores no obtuvieron una educación formal y por
lo tanto habían aprendido experimentando.
Generalmente los proyectos carecían de una planeación y se trabajaba con mucha
informalidad.
En conjunto provocaban que los resultados se obtuvieran pasada la fecha de
entrega, los programas no funcionaban de manera correcta, era difícil realizar
cambios y se excedían los plazos y costos planeados. La mayor parte de los
errores se encuentran en una mala redacción del código (38.33%), le siguen los
errores de diseño (24.17%), los de documentación (13.33%), de requerimientos
(12.50%) y de correcciones mal implementadas (11.67%) .
Para dar solución a los problemas que se presentaban en esta conferencia se creó
una nueva rama de ingeniería, la ingeniería de software.
A principio de los 80 nace smalltalk y los métodos de diseño orientado a objetos
con el objetivo fundamental de resolver los problemas que no pudieron serlo por
métodos anteriores como el método estructurado.
Beneficios de las tecnicas Orientadas a Objetos:
• Re usabilidad del código.
• Mayor facilidad de mantenimiento y modificación.
• Disminución del gap semántico.
• Mejor interacción entre el usuario-analista-diseñador.
• Mas apropiado para abordar problemas muy complejos (por ejemplo las
interfaces graficas).

Conceptos fundamentales:
Un sistema orientado a objetos es un sistema donde los elementos son entidades
denominadas “objetos”, que “colaboran” con otros objetos comunicándose mediante
“mensajes” para cumplir un objetivo dado, cada uno con tareas definidas o un rol
dedo acorde a su “responsabilidad”.

Objeto
Encapsulado de datos que modela algo real u abstracto, y operaciones que tratan
dichos datos. Tiene un estado interno, osea, posee identidad. Cada objeto es una
instancia de la clase a la que pertenece. Los objetos no son simplemente
abstracciones de datos como las entidades de un modelo de entidad relacion, sino
que tienen un “comportamiento”, es decir, las operaciones que puede realizar.

Clase
Es a su vez un conjunto de objetos que comparten atributos, metodos, relaciones
y semantica, y una plantilla o molde para crear objetos con identidad.

Responsabilidad
Todo objeto tiene definidoun rol dentro del sistema. Que sabe el objeto y que
debe hacer, basicamente el scope/alcance.

Colaboración
Los objetos deben colaborar entre si para cumplir sus resplonsabilidades.
Es cuando dos o mas objetos interactuan entre si mediante mensajes. Un objeto
delegara la responsabilidad en otro objeto para que realice una tarea que le
solicita.

Mensajes.
Es el mecanismo por el cual se comunican los objetos para poder colaborar.

Relacion de conocimiento:
El emisor debe conocer el objeto receptor del mensaje.

La recepcion de un mensaje dispara una o mas operaciones en el objeto receptor.

Hay mensajes de Get/Set y de realizar operaciones.
Los mismos pueden ser sincrónicos (el emisor aguarda respuesta), asíncronicos o
de tiempo limite (espera un tiempo limite).

El pensamiento orientado a objetos.

El paradigma de la programación orientada a objetos es la implementación del
pensamiento orientado a objetos en la programación.

POO nos dice:

• Pensar todo en términos de objetos.
• Representar los objetos de la forma más cercana a cómo expresamos las
cosas en la vida real.
• Dar prioridad a los objetos y no a la funcionalidad.
• Pensar en el propósito general del programa como un todo antes de
subdividirlo.
• Los programas se definen en términos de objetos, propiedades, métodos,
y la interacción (comunicación) entre objetos.

Principios fundamentales.
SOLID: Es un acrónimo mnemónico introducido por Robert C. Martín a comienzos de
la década del 2000 que representa cinco principios básicos de la programación
orientada a objetos y el diseño. Cuando estos principios se aplican en conjunto
es más probable que un desarrollador cree un sistema que sea más fácil de
mantener y ampliar con el tiempo.

1. Principio de una sola responsabilidad

2. Principio abierto/cerrado
3. Principio de sustitución Liskov
4. Principio de segregación de interfaz
5. Principio de Inversión de dependencia

Principio de una sola responsabilidad

Cada clase debe tener una única responsabilidad, y esta debe estar contenida
únicamente esa la clase. Así:
• Una clase debería tener sólo una razón para cambiar.
• Cada responsabilidad es el eje del cambio.
• Para contener la propagación del cambio, se deben separar las
responsabilidades.
• Si una clase asume más de una responsabilidad, será más sensible al
cambio y las responsabilidades tendrán acoplamiento.

Principio abierto/cerrado
Este principio establece que una entidad de software (clase, módulo, función,
etc.) debe quedar abierta para su extensión, pero cerrada para su modificación.
Es decir, se debe poder extender el comportamiento de tal entidad pero sin
modificar su código fuente.

Una clase está cerrada, dado que puede ser compilada, almacenada en una librería
y usada por otras clases. Pero también está abierta, dado que a partir de ella
podríamos crear nuevas subclases que incorporaran características nuevas. Y al
crear una subclase, no hay ninguna necesidad de modificar la superclase.
 • Se dice que un módulo está abierto si se puede extender.
• Se dice que un módulo queda cerrado si no se puede modificar por otros
módulos.
• Si un cambio impacta a varios modulos, entonces la aplicacion no está
bien diseñada.
• Se deben diseñar modulos que nunca cambien para reutilizarlos más
adelante a través de su extensión (herencia).

Principio de sustitución Liskov

Los objetos de un programa deberían ser reemplazables por instancias de sus
subtipos sin alterar el correcto funcionamiento del programa.

• Cada clase que hereda de otra puede usarse como su padre sin necesidad
de conocer las diferencias entre ellas.
• Funciones que usen punteros o referencias a clases base deben poder
usar objetos de clases derivadas sin saberlo.

Principio de segregación de interfaz

Este principio hace referencia a que muchas interfaces cliente específicas son
mejores que una interfaz de propósito general.

• Este principio se aplica a una interfaz amplia y compleja para

dividirla en otras más pequeñas y específicas, de tal forma que cada
cliente use sólo aquella que necesite, pudiendo así ignorar al resto.
A este tipo de interfaces reducidas se les llama "interfaces de rol".
• Los clientes de un programa dado sólo deberían conocer los métodos que
realmente van usar, y no aquellos que no necesitan usar.
• Fue concebido para mantener a un sistema desacoplado respecto a los
sistemas de los que depende, y así resulte más fácil refactorizarlo,
modificarlo y redesplegarlo.

Principio de inversión de dependencias

Este principio establece:

• Los módulos de alto nivel no deben depender de los módulos de bajo

nivel. Ambos deben depender de abstracciones.
• Las abstracciones no deben depender de los detalles. Los detalles
deben depender de abstracciones.

Puede implementarse con: inyeccion de dependencias o inversion del control.

Basicamente, en vez de instanciar un objeto en una clase, debemos poder injecta
la interfaz de dicho objeto en la clase. Mi clase conductor no crea su propio
auto fiat 128, cuando llamamos a conductor para hacer algo debemos pasarle un
auto cualquiera (pues implementa la interfaz auto en su contructor). De esta
forma conductor, no estara condicionado a la implementacion de un auto y podra
también usar cualquiera.

Otros Conceptos:
Los lenguajes y sistemas deben mostrar los siguientes conceptos para ser
considerados Orientados a Objetos.

Abstracción
Es el principio en el cual la mente se enfoca en los aspectos importantes de un
problema y descarta los irrelevantes.
No es propio de la orientacion a objetos. Este principio es fundamental porque
nos permite crear modelos encapsulados.
En la orientacion a objetos se abstaen tanto datos, como comportamientos y se
los encapsula juntos en los objetos.

Encapsulamiento
Mecanismo que permite ocultar los detalles de implementacion de un objeto. El
objeto solo es conocido y manipulado mediante su interface.
Herencia
Es una relacion entre clases que permite reusar los atributos y operaciones de
una clase general en otras mas particulares.

Polimorfismo
Es un principio por el cual una misma operación puede ser resuelta diferente
dependiendo del objeto que recibe el mensaje.

(Sobrecarga)
Un objeto responde de diferente manejara a un mismo mensaje.

Unidad 2.2: El Lenguaje de Modelado Unificado

Visión general de UML
Unified Modeling Language, es un lenguaje gráfico estandar para visualizar,
especificar, construir y documentar artefactos de un sistema de software. UML
puede usarse en las diferentes etapas del ciclo de vida del desarrollo y en
diferentes tecnologias de implementacion. UML es independiente del proceso de
desarrollo.
No es una metodologia.

Síntesis histórica y evolución de UML

El lenguaje UML comenzó a gestarse en octubre de 1994.cuando Rumbaugh se unió a
la compañía Rational fundada por Booch. El objetivo de ambos era unificar dos
métodos que habían desarrollado: el método Booch y el OMT (Object Modelling
Tool). El primer borrador apareció en octubre de 1995. En esa misma época otro
reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas.
Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje
se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas
estas colaboraciones condujeron a la definición de la primera versión de UML. En
1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de
facto para el análisis y el diseño orientado a objetos.

La primera versión de la descripción del método unificado fue presentada en

octubre de 1995 en un documento titulado Unified Method 0.8.
Un año después se les unió Jacobson y el método unificado se transformó en UML
(The Unified Modeling Language).
Asimismo durante el año 1996 se crea un consorcio de colaboradores para trabajar
en la definición de la versión 1.0 de UML, que agrupa a grandes empresas del
sector.
De esta colaboración nace la descripción del UML versión 1.0 enviada en 1997 al
OMG (Object Management Group), constituyéndose en un estándar.
La versión UML 1.1 (1997) es aprobada por la OMG convirtiéndose en la notación
estándar de facto para el análisis y el diseño orientado a objetos.
Versión UML 1.2 (1998) por OMG.
Versión UML 1.3 (1999) por OMG.
Versión UML 2.0 (2005) por OMG.

Conceptos
Vistas, Diagramas
Es un subconjunto de contrucciones de modelado que se enfocan en un aspecto
particular del sistema. Las vistas pueden dividirse en 3 areas: clasificacion
estructural, comportamiento dinamico y gestion de modelo. La division puede ser
arbitraria pero apunta a ser intuitiva.
La clasificacion estructural: describe los elementos del sistema y sus
relaciones entre si.

Los Clasificadores: modela los elementos del sistema. Son la base sobre la que
se construye el comportamiento dinamico. Son: clases, casos de uso, componentes,
nodos, actores y colaboraciones.

El comportamiento dinamico: describe el comportamiento del sistema a traves del

tiempo. El comportamiento puede describirse como una serie de fotos tomadas a
partir de la vista estatica.

El modelo fisico: describe los recursos computacionales del sistema y el

despliegue de los artefactos en ellos.

La gestion del modelo: describe la organizacion de los modelos mismos en

unidades jerarquicas.

El paquete: es la unidad generica de organizaciones para los modelos. Los

modelos y os subsistemas son un tipo especial de paquete.

Un modelo: es un paquete jerarquico que otorga una completa abstraccion

semantica del sistema desde un punto de vista particular. Todo elemento del
modelo esta contenido en un paquete.
Nodo: es un recurso de tiempo de ejecucion que define una ubicación.

Artefacto
Es una unidad física de informacion o descripcion de comportamiento en un
sistema computacional. Los artefectos de despliegan en nodos. Un artefacto puede
ser una manifestacion, es decir una implementacion, de un componenente.
La vista de Deployment describe la configuracion de nodos del sistema corriendo
y los artefactos en ellos, incluidas las relaciones de manifestacion a
componentes.

Mecanismos de Extensibilidad. (Pagina 91 de UML para

completar)
Las extensiones de UML estan organizadas en perfiles.
Los Perfiles UML: declaran varias contrucciones pensadas para proveer un
limitado pero util mecanismo de extensivilidad. Estas construcciones incluyen
restricciones, estereotipos y valores etiquetados y son aplicables a los
elementos de todas las vistas.

Los estereotipos: es un mecanismo de extensibilidad para definir meta-clases. Es

decir, un tipo de clase basicamente.son aplicados normalmente en diagramas de
clase, pero pueden aparecer en otros lugares. Los perfiles tambien pueden
incluyir librerias de clases especificas de un dominio.
Los mas comunes son:
• Entidad: representan algo real o abstracto de lo cual hay que almacenar
datos. Ejemplos: alumno, empleado
• Frontera: representan objetos tecnicos requeridos para vincular la
aplicacion con el entorno. Ejemplos: interfaz de usuario, interfaz con
impresora.
• Control:contienen comportamiento que no pertenece naturalmente a objetos o
interfaces. Son objetos transitorios como puede ser un controlador de
reportes. El objeto manager de X es de este tipo.

En el diagrama de secuencia:

Modelado estructural (Vista estatica, de Casos de Uso y de

Desplieque)

(La vista Estatica)

Es la base de UML. Sus elementos son los conceptos significativos en una
aplicación, incluyendo conceptos reales, abstractos, conceptos de
implementacion, de comunicación y de todo tipo encontrado en el sistema.
Objetivos:
Captura la estructura de Objetos.
El la base de las demas vistas.
Es un modelo incremental.

Clasificadores
Es un concepto discreto en el modelo que tiene identidad, estado, comportamiento
y relaciones.
modela los elementos del sistema. Son la base sobre la que se construye el
comportamiento dinamico.
Son clasificadores:
• Clases, interfaces y tipos de datos.
• Los casos de uso, que mapean aspectos de comportamiento.
• Los subsistemas, componentes y nodos.
• Los paquetes.

Tipos de Clasificadores:
1. Clasificadores de elementos del Sistema:
Clase
Interfaz
Tipo de datos
2. Clasificacodres de conceptos de comportamiento:
Caso de uso
3. Clasificadores del entorno:
Actores
4. Clasificadores de estructuras de implementacion:
Componente
Nodo
Subsistema.

Operación: Servicio ofrecido por un Objeto

Método: implementación de una operación.
Representacion de Clase:
Nombre
Atributo1
Atributo2
Operacion1
Operacion2

Clase abstracta: clase de la cual no pueden generarse instancias. Contrario de

la clase concreta.
Atributo: valor que describe un objeto.

Atributo identificador: identifican univocamente a un objeto de una clase (Ids).

Atrinuto derivado: atributo calculado de otros atributos.

Visibilidad(de atributos y metodos):

(+)publico
(-)privado
(#)protegido

Relaciones
Las relaciones entre Clasificadores son:

1.Asociacion(conocimiento): conexión semantica entre los objetos individuales de

las clases dadas, muestran objetos que interactuan o pueden interactuar. es la
unica que relaciona instancias. Una asociacion relaciona una lista
ordenada(tupla) de o mas clasificadores, con las repeticiones permitidas.Posee
Cardinalidad: 0,*, 1...*
La direccionalidad de las asociaciones es importante en la etapa de diseño.
Una asociación puede tener atributos por si misma, cuyo caso es una asociacion y
una clase a la vez. Es decir una Clase Asociacion.

Asociacion Calificada: Cuando la asociacion tiene un atributo unico dentro de un

conjunto de objetos relacionados, el cual es llamado calificador. Por ejemplo,
el numero de asiento junto con la fecha vincula la entrada y el show, solo
puedes tener una entrada con esos atributos unicos.

Asociacion Ordenada:
Una asociacion que requiere que uno de los extremos presente ordenamientos, como
las diapositivas de una presentacion.

Agregacion y composicion
La agregacion es una relacion Todo-Partes. Como las partes de un auto con el
auto.
La composicion implica una asociacion mas fuerte, implica:
• Dependencia Existencial, el elemento desaparece al destruirse al otro.
• Pertenencia Fuerte: el elemento contenido es parte vital de el contenedor.
• Los objetos no son compartidos, no hacen parte del estado de otro objeto.
 • Un ejemplo seria la alu de una computadora.

Enlace: Una instancia de una asociacion es un Enlace. Un enlace es una lista

ordenada de referencias a objetos, cada uno de los cuales debe ser una
instancia de la clase correspondiente o de un decendiente de la misma.

Bidireccionalidad: las asociaciones son bidireccionales. Una asociacion no es

simetrica (sus lados/direccion son distinguibles). Una forma de verlo es que el
sujeto y el predicado no son intercambiables en una declaracion. Es decir, que
toda asociacion puede declararse de forma inversa: “Pedro tiene un perro”, “un
perro es tenido por Pedro”, si se quiere mostrar direccionalidad de una relacion
de un lado y no del otro se muestra con una flecha (generalizaciones y
dependencias).

2. Generalizacion
Relacion taxonomica entre la descripcion general y una mas especifica.
Proposito de la generalizacion: tiene 2.
El primero es definir las condiciones bajo las cuales una instancia de una
clase, puede ser utilizado cuando se declara una variable, conteniendo valores
de la clase dada esto se llama el principio de sustitucion de Liskov).
El segundo proposito es permitir la descripcion incremental de un elemento que
comparte descripciones con sis antecesores. Esto se conoce como herencia.

Principio de sustitucion de liskov: operaciones polimorficas. Una instancia de

un desendiente se puede usar donde quiera que este declarado un antecesor.
Herencia: Permite descripcion incremental.

Herencia Multiple: si un calificador tiene mas de un padre (es raro).

3.Realizacion:
Conecta un elemento del modelo, como un clase, con otro, como una interfaz, que
especifica su comportamiento pero no su estructura o implementacion. El cliente
debera tener al menos todas las operaciones que tiene el proveedor.
4.Dependencias:

Es una relacion semantica entre dos o mas elementos del modelo. Implica que un
cambio en el elemento proveedor puede producir un cambio en su
dependiente(cliente). Las herencias son un tipo especial de dependencia.

Hay varios tipos:

Intancia:es la unidad de ejecucion con identidad, es decir, que puede ser

distinguida de otras entidades de ejecucion. Tiene valores propios, que pueden
cambiar a lo largo de la ejecucion. Basicamente lo que es Objeto para Clase. Y
un enlace para una asociacion.

Instantanea: configuracion estatica particular de un sistema en ejecucion en un

instante dado.

Restriccion: expresion booleana que condiciona una relacion. Puede expresarse en

lenguaje natural

Diagramas de Clases
un Diagrama de una instantanea es una imagen del sistema, en un instante en el
tiempo. Se llama diagrama de objetos porque consiste de imagenes de objetos.
Recuerde que las instantaneas no son definiciones del sistema,sino ejemplos del
mismo.
La vista estatica describe los casos que pueden ocurrir.

Modelado de Casos de Uso

Los usuarios son entrevistados para describir distintos escenarios de uso
(instancias de casos de uso).

(La vista de Casos de Uso)

Es una vista externa del sistema. El primer modelo que se debe construir es un
modelo entendible tanto por los desarrolladores como por los usuarios.
Es el modelo que describe el sistema, sus entorno y como se relaciona con el
mismo.
Se trata al sistema como una caja negra.
Esta vista captura el comportamiento del sistema, de un subsistema, o de una
clase, tal como lo vera el usuario desde el exterior.
Particiona la funcionalidad del sistema en TRANSACCIONES significativas.
Se describe una interaccion como una secuencia de mensajes entre el sistema y
uno o mas actores.

Concepto de Actor
Es una idealizacion de una persona externa, de un proceso, o de una cosa que
interactua con el sistema. Son objetos que reciden FUERA del sistema, en tanto
que los casos de uso son objetos internos al sistema.
Un actor participa en uno o mas casos de uso.
Los actores pueden ser definidos en jerarquias de generalizacion.
El usuario es una persona que usa un sistema, el actor es un rol que asume ese
usuario.
Un usuario puede actuar como instancias de distintos actores.

Caso de Uso
Es una secuencia de transacciones realizadas por el sistema que brinda un
resultado de valor a un actor en particular.
Es una forma de usar el sistema. El usuario interactua con el sistema
interactuando con sus casos de uso.
Es una unidad coherente de funcionalidad, externamente visible, proporsionada
por una unidad del sistema y expresada por secuencias de mensajes entre actor/es
y sistema.
Cumplen dos funciones importantes:
• Capturan requerimientos funcionales del sistema: definen el comportamiento
 esperado del sistema.
• Estructuran los modelos de objetos en vistas manejables: es practico
construir modelos de objetos para cada caso de uso con los objetos que
participan. El modelo de objetos completo se obtiene al combinar todos los
modelos de objetos de casos de uso. Puede verse la responsabilidad de un
objeto al ver todos sus roles en distintos casos de uso.

Una colaboracion: es una realizacion de un caso de uso. Colaboran varias clases

del sistema.

Escenarios.
Un escenario es una secuencia de pasos que describen una interaccion entre actor
y sistema. Un caso de uso es un conjunto de escenarios con un mismo objetivo
para el actor. Los Escenarios son los distintos caminos posibles, el camino
Estandar y los caminos alternativos.

Modelado de casos de uso:

Identificando actores:
• Identificar actores
• Cuales son las principales tareas del actor
• Que accesos necesista tener al sistema
• Cuando el actor informara al sistema de cambios fuera del sistema
• uando el actor debera ser informado de cambios a traves del sistema
Identificando eventos(externos o temporales a los que debe responder el
sistema):
• Confeccionar lista de eventos
• asociar una lista de transacciones para cada evento identificado.

Diagramas de Casos de Uso.

Especificación del flujo de sucesos(eventos). (También

llamada descripcion textual del Caso de Uso)
Nombre del caso de uso
Breve descripcion del rol y el objetivo del caso de uso. (opcional)
Condiciones previas.
Flujo de Sucesos Basico.(camino estandar)
Condiciones posteriores.
Flujo de suscesos alternativo.(caminos alternativos)

El camino estandar: es una descripcion de todas las actividades que deben

realizarse de forma normal. No se describe el proceso de excepciones.

Caminos alternativos: describen casos inusuales de procesamiento y manejos de

excepciones o errores.

Ejemplo:
Caso de uso: Presionar boton rojo para ganar
precondiciones: usuario registrado.
1.el sistema informa que se debe presionar el boton rojo para ganar.
2.el usuario presiona el boton rojo.
3.el sistema anucia que ha ganado.
Post condiciones: el sistema imprime un boleto de ganador.

Caminos alternativos:
El usuario presiona boton azul.
2.1 el usuario presiona boton azul
2.2. el sistema informa que no se ha ganado.
Post condicion: el sistema imprime una hoja burlandose del usuario.

Relaciones entre casos de uso.

Los casos de uso se pueden relacionar mediante inclusion y extension (en lo
posible no usar durante el final practico).

Inclusión
Un caso de uso puede incluir en su comportamiento el comportamiento de otro caso
de uso mediante una relacion de inclusion.
Si varios casos de uso comparten secuencias de pasos, para evitar redundacia se
las extrae en secuencias comunes. Una secuencia comun es un caso abstracto que
no se puede instanciar por si mismo.
Los casos de uso que INCLUYEN la secuencia comun son casos comunes y se pueden
instanciar.
Es una relacion de dependencia entre casos de uso.

Extensión
Un caso de uso puede definirse como una extension incremental de un caso de uso
base. Los casos de uso base son instanciables siempre. Pero las extensiones solo
son instanciables en casos particulares. Toda extension debe incluirse como
camino alternativo en la descripcion textual.
Se utiliza esta relacion para:
➢ Partes opcionales de un caso de uso.
➢ Cursos complejos y alternativos
➢ Subsecuencias que se ejecutan en condiciones excepcionales.

Generalización.
Un caso de uso se puede especializar en casos de uso hijos utilizando una
relacion de generalizacion.

Modelado de Máquina de Estados.

(Vista de Maquina de Estados)

Describe el comportamiento dinamico de los objetos, en un cierto plazo,
modelando los ciclos de vida de los objetos de cada clase.
Cada objeto se trata como una entidad aislada que se comunica con el resto del
mundo detectando eventos y respondiendo a ellos.
Es una buena forma de describir el comportamiento de un objeto a traves de
varios casos de uso.

Maquina de estados: Es una vista localizada de un objeto, una vista que lo

separa del resto del mundo. Se representa por un diagrama de estados y de
transiciones. Se une a una clase y describe la respuesta de una instancia de esa
clase a los eventos que recibe.

Eventos
Es una ocurrencia significativa que tiene una localizacion en el tiempo y
espacio. No tiene duracion.
Se habla de Evento como una descripcion de todas las ocurrencias individuales
del evento que tienen la misma forma general. Una ocurrencia especifica de un
evento es por lo tanto una Instancia del evento.
Pueden tener parametros que caracterizan las instancias.
Se pueden organizar en jerarquias degeneralizacion para compartir estructura en
comun.

Los eventos se clasifican en varios tipos explicitos e implicitos:

Eventos de Señal (asincrono)
Eventos de Cambio (asincrono)
Eventos de Tiempo (asincrono)
Eventos de Llamada (sincrono)

Evento de Señal
Una señal es una entidad con nombre que se piensa especificamente como vehiculo
de comunicación entre dos objetos. La recepcion de una señal es un evento para
el objeto receptor.
Las señales se pueden modelar en diagramas de clases como clasificadores
utilizando el estereotipo “señal/signal”. Los parametros de la señal se declaran
como atributos.

Evento de Cambio
Es la satisfaccion de una expresion booleana que dependa de ciertos valores de
un atributo.
Es una manera declarativa de esperar a que una condicion sea satisfecha.
La diferencia entre una condicion de guarda y un evento de cambio es que una
condicion de guarda se evalua una vez caundo ocurre el evento disparador de la
transicion y si es falsa la transicion no ocurre. Un evento de cambio se evalua
continuamente hasta que llega a ser verdad, en cuyo caso se disara la
transicion.

Evento de Tiempo
Representan el paso del tiempo. Un evento de tiempo se puede especificar de modo
absoluto(hora) o de modo relativo (2 segundos despues de).

Evento de Llamada
Es la recepcion de una llamada por un objeto que elige poner una operación en
ejecucion, como transicion de la maquina de estados.
Para el objeto llamador un evento de llamada es indistinto de una llamada a un
metodo ordinaria.
Y el objeto receptor elige si la operación sera implementada con un metodo o con
un disparador de un evento de llamada en la maquina de estados. Los parametros
de la operación son los parametros del evento.
A diferencia de una llamada ordinaria el receptor puede continuar su propia
ejecucion en paralelo.

Estado
Describe un periodo de tiempo durante la vida de un objeto de una clase. Puede
ser caracterizado de tres maneras complementarias: como un conjunto de valores
de objeto cualitativamente similares en cierta forma; como periodo de tiempo,
durante el cual un objeto espera que ocurra algun evento o eventos; o como
periodo de tiempo durante el cual el objeto realiza cierta actividad.
Un estado puede tener un nombre, aunque a menudo es anonimo y se describe por
sus acciones.
En una maquina de estados, un conjunto de estados esta conectado mediante
transiciones. Aunque las transiciones conectan dos estados, las transiciones son
procesadas por el estado del que salen. Cuando un objeto esta en un estado es
sencible a tener una transicion cuando ocurren los eventos(correspondientes a
esa transicion) que salen de ese estado.

Transiciones
Es el cambio de un estado a otro. En general una transicion tiene un evento
disparardor, una condicion de guarda, una acción, y un destino.
Existen dos tipos de transiciones:
• Transicion Externa: cambia el estado activo
• Transicion Interna: Tiene un estado origen pero no tiene un estado
destino, o dicho de otra forma, el origen es el destino.
Si una transicion interna tiene una acción, se ejecuta, pero no existe
cambio de estado.
Evento disparador:
Es un evento cuya ocurrencia permite la transicion.
Si una señal tiene decendientes cualquier descendiente permite la transicion.
Los eventos se manejan uno solo a la vez.

Condicion de Guarda:
Es una condicion booleana referida a los atributos del objeto o a los parametros
del evento disparador, que se evalua cuando ocurre el evento disparador. Si la
expresion se evalua como cierta entonces se dispara la transicion.

Accion:
Cuando uno dispara una transion, su acción (si la hay) es ejecutada. Una acción
es un computo atomico y breve. A menudo es:
• una sentencia de asignacion
• una operación aritmetica
• el envio de una señal a otro objeto.
• La invocacion de una iperacion propia
• asignacion de valores de retorno
• creacion o destruccion de objetos
• una secuencia de acciones simples.

Atomico: no puede ser interrumpida por otro evento, Se ejecuta hasta terminar.

Cambio de estado:
Cuando se completa la ejecucion de la acción, el estado destino de la transicion
pasa a ser activo.

Transicion de Finalizacion:
Es una transicion que carece de un evento disparador explicito. Es accionada por
la terminacion de la actividad del estado que sale.
Puede tener una condicion de guarda que se evalua en el momento en que termina
la actividad.

Diagrama de máquina de Estados.

Estados compuestos
Es un estado que se ha compuesto por la combinación de varios estados
secuenciales o concurrentes.

Estados anidados: los estados se pueden anidar en estados compuestos. Una

transicion que deja el estado mas externo es aplicable a todos los estados
internos.

Estados con memoria

Hay veces que, después de salir de un estado compuesto, interesa volver al mismo
subestado en el que se estaba cuando se salió. Para modelar esta posibilidad, se
utilizan estados con memoria. Estos estados se identifican porque en la esquina
inferior izquierda tienen una letra H (de History) dentro de una circunferencia.
El “Estado de memoria” es un pseudoestado.

Si una transicion heredada causa la salida automativa del estado compuesto, el

estado recuerda el subestado donde se encontrada al momento de salir.
Si se quiere retornar al estado en el que se encontraba al momento de la salida
forzada se debe señalar una transicion hacia la H, una transicion hacia un
estado anidado o al estado compuesto no activara la memoria.
Modelado de Flujos de Actividades.
(Vista de Actividades)
Un grafo de actividades es una forma especial de maquina de estados, prevista
para modelar computos (o una operacion) y flujos de trabajos. Los estados del
grafo representan los estados de ejecucion del computo, no estados de un objeto.

Actividades (Estados de actividad):

Representa la ejecucion de una sentencia de un procedimiento, o el
funcionamiento de una actividad en un flujo de trabajo. En vez de esperar un
evento, el estado de actividad espera la terminacion de su computo. Cuando la
actividad termina, entonces la ejecucion procede al siguiente estado de
actividad dentro del grafo.
Los Estados de actividad no tienen generalmente transiciones con eventos
explicitos, pero pueden ser abortadas por transiciones en estados que los
incluyen.
Pueden tener acción de entrada y de salida y pueden tener condiciones de guarda.
No es atomico(pueden ser interrumpidos).
Las actividades producen alguna acción que esta compuesta de computaciones
atomicas.

Estados de acción: son similares a los de actividad, excepto que son atomicos y
no permiten transiciones mientras estan activos. Se usan por lo general para las
actividades cortas de mantenimiento.

Transiciones
Una transicion de terminacion es activada en un diagrama de actividades cuando
se completa la actividad procedente.

control del flujo.

Diagrama de Actividades.
Es una notacion para un grafor de actividades. Incluye algunos simbolos
especiales, abreviados por conveniencia. Estos simbolos pueden usarse en
cualquier diagrama de estados.
Es como un organigrama tradicional, excepto que prermite control de concurrencia
ademas de control secuencial, una gran diferencia.
Es escencialmente un diagrama de flujo que destaca la actividad que tiene lugar
a lo largo del tiempo. Muestra las operaciones que pasan entre objetos.
Muestra el “Flujo de Actividades” es decir, la ejecucion no atomica en curso.
Hilos Concurrentes: Puede contener bifurcaciones, asi como divisiones de control
en hilos concurrentes. Los hilos concurrentes representan actividades que se
pueden realizar concurrentemente por los diversos objetos o personas de una
organización. Las actividades concurrentes se pueden realizar simultaneamente o
en cualquier orden.

Calles: a menudo es util organizar las atividades en un modelo según su

responsabilidad. Por ejemplo agrupando juntas todas las actividades manejadas
por una organización del negocio. Esta clase de asignacion puede mostrarse
organizando las actividades en regiones distintas separadas por lineas del
diagrama, debido a su aspecto cada region se llama calle.
Flujo de Objetos:
Un diagrama de actividades puede mostrar el flujo de objetos como entrada-salida
de una actividad. En tal caso se dibuja un objeto pudiendo indicar el estado
para representar su evolucion. Para un valor de salida se representa un flecha
con linea discontinua desde la activdad al objeto. Para un valor de entrada se
dibuja una flecha con linea continua desde el objeto a la actividad.

Modelado de Interacción de Objetos.

(Vista de Interaccion)
Sirve para visualizar como se relacionan dinamicamente los distintos objetos del
sistema. Proporciona una vision mas integral del comportamiento del sistemaque
la de la maquina de estados. Esta vista es modelada por colaboraciones.

Colaboración de Objetos.
Es una descripcion de una colección de objetos que interactuan para implementar
un comportamiento en un contexto dado. Describe una sociedad de objetos
cooperantes ensamblados para llevar adelante algun proposito.
Cada colaboracion contiene roles que son ocupados por objetos y enlaces(links)
en tiempo de ejecucion. Cada objeto y/o enlace(link) cumple un rol dentro de una
colaboracion.
Un objeto puede participar en mas de una colaboracion.

Una colaboracion implementa la funcionalidad de un caso de uso dado a traves de

una dependencia de ralizacion. O dicho de otra forma “La colaboracion realiza un
caso de uso”.

El flujo de mensajes dentro de una colaboracion puede representado por una

maquina de estados, la cual especifica las secuencias de eventos legales. Los
eventos en la maquina de estados representan el intercambio de mensajes.

Aspecto estático y dinámico de la colaboración.

La colaboracion tiene 2 aspectos:
Aspecto estatico: es similar a la vista estatica, contiene el conjunto de roles
y sus relaciones que definen el contexto para el aspecto dinamico.

Aspecto Dinamico: es el conjunto de mensajes intercambiados entre los objetos

que ocupan los roles. Tal intercambio de mensajes en una colaboracion es llamada
una interaccion. Una colaboracion puede incluir una o mas interacciones.
Las interacciones son representadas por diagramas de Secuencia o diagramas de
Colaboracion.

Interaccion: es un conjunto de mensajes que se intercambian dentro del contexto

de una colaboracion por roles de clasificadores(objetos) a traves de
enlaces(instancias de asociacion).

Mensaje: es una comunicación unidireccional entre objetos,un flujo de control

con informacion desde emisor a receptor. Puede tener parametros y puede ser una
señal(asincrono) o una llamada(sincrono).
Los diagramas de colaboracion (enfocado en relaciones entre objetos) y los
diagramas de secuencia (enfocado en la relacion con el tiempo) se usan para
representar una secuencia de mensajes.
Todos los mensajes del mismo hilo se ordenan secuencialmente.
Los mensajes de distintos hilos son concurrentes a menos que haya una
dependencia secuencial explicita.

Hilos de control: agrupaciones de mensajes secuenciales. Hilos separados

representan conjuntos de mensajes concurrentes.
La sincronizacion entre hilos se modela por restricciones entre mensajes en
diferentes hilos. Una construccion de sincronizacion puede modelar una
bifurcacion del control, una reunion del control o una ramificacion del control.

Diagramas de colaboración
Es un diagrama de clases que contiene roles de clasficador y roles de
asociacion(instancias de clases) en vez de clasificadores y asociaciones a
secas. Los roles de clasificacion y roles de asociacion describen la
configuracion de objetos y enlaces que pueden ocurrir cuando una instancia de
colaboracion es ejecutada. Cuando una colaboracion es instanciada, los objetos
son ligados a roles de clasificador y los enlaces son ligados a roles de
asociacion.-
Se enfoca en las relaciones entre objetos.
Solo se representan los objetos que estan implicados en la colaboracion, aunque
puede haber otros en el sistema completo. Es decir, un diagrama de colaboracion,
modela los objetos y enlaces implicados en la implementacion de una interaccion
y no hace caso a de las otras.
Es util agrupar los objetos en una de cuatro categorias:
• Objetos que existe durante toda la interaccion
• Objetos creados durante la interaccion (constraint{new})
• Objetos destruidos durante la interaccion (constraint{destroy})
• Objetos creados y destruidos durante la interaccion
(constraint{transient})
Durante el diseño esto ayuda a determinar como debe fluir el flujo de control
dentro de la interaccion.
Aunque las colaboraciones muestran directamente la implementacion de una
operación, pueden también mostrar la realizacion de una clase entera. Esto
permite que el modelador vea roles multiples que los objetos pueden desempeñar
en varias operaciones. Esta Vista puede ser construida tomando la union de todas
las colaboraciones necesarias para describir todas las operaciones del objeto.
Flujos: Generalmente un diagrama de colaboracion contiene un simbolo para un
objeto durante una operación completa. Sin embargo a veces un objeto tiene
distintos estados que se deban hacer explicidtos. Por ejemplo un objeto pudo
cambiar localizacion, o sus asociaciones pudieron diferenciarse perceptiblemente
en distintos momentos. Un objeto se puede mostrar con su clase y su estado -un
objeto de una clase en un estado-. El mismo objeto se puede mostrar multiples
veces, cada uno con una localizacion o estado diferente.

Flujos <<Become>>: Los diferentes simbolos de objeto que representan un objeto

se pueden conectar usando flujos <<Become>>. Es una transicion, a partir de un
estado de un objeto a otro. Se dibuja como una flecha de linea discontinua con
el esterotipo <<become>> y puede ser etiquetado con un numero de serie para
mostrar cuando ocurre. Un fujo de conversion también se utiliza para mostrar a
migracion de un objeto a partir de una localización a otra localizacion.

Diagrama de secuencia.
Representa una interaccion como un grafico bidimensional. La dimension vertical
es el eje de tiempo. La dimension horizontal muestra los roles de clasificadores
que representan objetos individuales en la colaboracion. Cada rol de
clasificador es representado por una linea vertical que representa su linea de
vida. Una linea punteada representa el preiodo de “existencia” del objeto. Una
linea doble representa una activadcion del objeto.
Un mensaje es representado por una flecha dese la linea de vida de un objeto
hacia la linea de vida de otro objeto. La secuencia de mensajes esta ordenada en
forma desdencente en el diagrama.
(la llamada recursiva la representamos distinto del diagrama con una caja de
linea punteada y las condiciones).

Activacion: es la ejecucion de una operación. Es representada por una linea de

dobre trazo sobre la linea de vida del objeto que recibe el mensaje.
Un objeto activo es un objeto que contiene la raiz(root) de la pila de
activaciones. Cada objeto activo tiene su propio hilo de control que se ejecuta
en paralelo con otros objetos. Los objetos que son llamados por los objetos
activos se denominan objetos pasivos. Estos reciven el control solo cuando
reciben un mensaje solicitando una operación y lo devuelcen al retornar.

Modelado físico del sistema.

(Las vistas fisicas)
UML incluye dos vistas para representar unidades de implementacion, la vista de
implementacion y la vista de despliegue.

Modelo de Implementación:
(Vista de Implementacion)
Muestra el empaquetado fisico de las partes reutilizables del sistema en
unidades sustituibles, llamadas componentes. Una vista de implementacion muestra
la implementacion de los elementos del diseño (tales como clases) mediante
componentes, asi como sus intefaces y dependencias entre componentes. Los
componentes son las piezas reutilizables.
Componentes.
Es una unidad física de implementacion con interfaces bien definidas pensada
para ser utilizada como parte reemplazable de un sistema. Cada componente
incorpora la implementacion de ciertas clases del diseño del sistema. Los
componentes bien diseñados no dependen directamente de otros componentes sino de
las interfaces que ofrecen los componentes.
En ese caso, un componente en un sistema se puede sustituir por otro componente
que ofrezca las interfaces apropiadas.
Los componentes soportan mas interfaces y requieren ciertas interfaces de otros
componentes. Una interfaz es una lista de las operaciones que una pieza de
software o de hardware ofrece y puede realizar. El uso de las llamadas
interfaces permite evitar las dependencias entre componentes. La vista de
componentes puede aparecer de dos formas. Puede mostrar un conjunto de
componentes disponibles (una biblioteca de componentes) con sus dependencias; es
el material a partir del cual se puede ensamblar un sistema. Puede también
mostrar un sistema configurado , con la selección de componentes usados para
contruirlo (a partir de la biblioteca completa). De esta forma, cada componente
se conecta a otros componentes cuyos servicios utiliza; estas conexiones deben
ser consistentes con las interfaces de los componentes.
Un componente se dibuja como un rectangulo, con dos rectangulos pequeños a un
lado. Puede ser unido por lineas solidas a los circulos que representan
interfaces.
Un diagrama de componentes muestra dependencias entre los componentes.
Cada componente ofrece algunas interfaces y utiliza otras. Si las dependencias
entre componentes se hacen a traves de interfaces, los componentes se pueden
sustituir por otros componentes que realicen las mismas interfaces.

Modelo de despliegue:
(Vista de Desplieque)
Muestra la disposicion fisica de los recursos de ejecucion computacional, tales
como computadores y sus interconexiones. Se llaman nodos.Durante la ejecucion,
los nodos pueden contener componentes y objetos. La asignacion de componentes y
de objetos a los nodos pude ser estatica o pueden migrar entre ellos.
La vista de despliegue puede mostrar cuellos de botella para el rendimiento si
las instancias de los componentes con dependencias se ponen en distintos nodos.

Nodos.
Un nodo es un objeto fisico de ejecucion que representa un recurso
computacional, que generalmente tiene por lo menos memoria y a menudo también
capacidad de proceso. Los nodos pueden tener estereotipos para distinguir
diferentes tipos de recursos, tales como UCP, dipositivos y memorias. Los nodos
pueden contenes objetos, instancias, instancias del componente.
Un nodo se representa mediante un cubo estilizado con el nombre del nodo y
opcionalmente su clasificacion.
Las asociaciones entre los nodos representan lineas de comunicacion. Las
asociaciones pueden tener estereotipos para distinguir distintos tipos de
enlaces.
Los nodos pueden tener relaciones de generalizacion para relacionar una
descripcion general de un nodo con una variacion especificacion.
La presencia de un objeto en un nodo se representa mediante el anidamiento
fisico del simbolo del objeto dentro del simbolo del nodo. Si eso no es
conveniente, el simbolo del objeto puede contener la etiqueta “Location”, cuyo
valor sea el nombre del nodo en el que reside el objeto (su localizacion).
La migracion de objetos o de instancias de componentes entre nodos, puede
reprentarse también.

¿Enlaces?
Las asociaciones entre los nodos representan lineas de comunicacion. Las
asociaciones pueden tener estereotipos para distinguir distintos tipos de
enlaces.
Gestión del Modelo:
(Vista de Gestion del modelo)
Consiste de paquetes (incluyendo tipos especiales de paquetes) y relaciones de
dependencias entre paquetes. Que se utilizan para agrupar elementos del modelo.

Paquetes.
Es una parte de un modelo. Cada parte de un modelo debe pertener a un paquete.
Los paquetes contienen elementos del modelo tales como clases, maquinas de
estado, diagramas de casos de uso, interacciones, colaboraciones, etc. Los
paquetes también pueden contener otros paquetes.
Los paquetes son unidades de organización jerarquica.
Hay varias maneras posibles de organizar los paquetes en un sistema, por la
vista, por la funcionalidades o por cualquier otra base que elija el diseñador.
Si se eligen bien, los paquetes reflejan la arquitectura de alto nivlel de un
sistema: su descomposicion en subsistemas y sus dependencias.

Dependencias.
Dependencias en los paquetes:
Las dependencias entre paquetes resumen dependencias entre elementos internos de
ellos.
Los paquetes se dibujan como carpetas, las dependencias como trazo discontinuos.

Dependendicas de acceso e importacion:

En general un paquete no puede tener acceso al cotenido de otro paquete. Los
paquetes son opacos, a menos que sean abiertos por una dependencia de acceso o
de importacion.

Dependencia de Acceso: el contenido del paquete proveedor puede aparecer en

referencias efectuadas por elementos del paquete cliente o paquetes incuidos
dentro del paquete cliente.
Visibilidad entre paquetes
• Publica: un elemento definido con visibilidad publica dentro de su paquete
puede ser visto desde cualquier otro paquete.
• Protegida: un elemento definido con visivbilidad protegida dentro de su
paquete, puede ser visto solamente por el paquete que los contiene y por
sus descendientes.
• Privada: un elemento definido con visivbilidad protegida dentro de su
paquete, puede ser visto solamente por el paquete que los contiene, y por
cualquier paquete anidado en el interior de ese paquete.

El permiso de acceso y visibilidad apropiada son necesarios para referenciar a

un elemento. Asi para que un elemento en un paquete puede ver un elemento de
otro paquete, el primer paquete debe tener acceso o importar al segundo paquete
y el elemento destino debe tener visibilidad publica dentro del segundo paquete.

Un paquete anidado dentro de otro es parte de su contenedor y tiene acceso

completo a su contenido, sin necesidad de accesos. El contenedor sin embargo
puede no ver el interior de sus paquetes anidados si no tiene acceso.
La dependencia de acceso no modifica el espacio de nombres del cliente ni crea
referencias. Solo concede permiso para establecer referencias.
La dependencia de importacion se utiliza para agregar nombres al espacio de
nombres del paquete del cliente como sinonimos de los caminos completos.

Modelo y Subsistema.
Un modelo es un paquete que abarca una descripcion completa de una vista
particualar de un sistema. Propociona una descripcion cerrada de un sistema a
partir de un punto de vista.
La relacion de traza es un a forma debil de dependencia entre elementos de
distinos modelos, que observan la presencia de una cierta conexión sin
implicaciones semanticas especificas.
Generalmente un modelo se estructura con forma de arbol. El paquete raiz
contiene anidados en si mismo paquetes que constituyen el detalle completo del
sistema desde el punto de vista dado.
Un subsistema es un paquete que tiene piezas separadas de especificacion y de
realizacion. Representa generalmente la particion del sistema en un limite
funcional o de implementacion. Un subsistema es un agrupamiento semánticamente
útil de clases o de otros subsistemas.
Los modelos y subsistemas se dibujan como paquetes con las palabras clave de
estereotipo.

Unidad 2.3: El Proceso Unificado de Desarrollo de Software

RUP

Visión General del Proceso Unificado.

El Proceso Unificado (RUP) es un proceso de desarrollo de software: Osea, un
conjunto de actividades necesarias para transformar los requisitos del usuario
en un sistema software.
Utiliza UML.
RUP es un marco generico que puede especializarse para una variedad de tipos de
sistemas, diferentes areas de aplicacionm tupos de organizaciones, niveles de
aptitud y diferentes tamaños de proyecto. RUP esta Basado en componentes, es
decir el software esta formado por componentes interconectados a traves de
interfaces.
• RUP esta dirigido por casos de uso.
• RUP esta centrado en la arquitectura.
• RUP es Iterativo e incremental.
Es un Proceso diciplinado en la actividad de desarrollo.
Es una manera disciplinada de asignar tareas y responsabilidades de desarrollo
(quien hace que y cuando).
EL Objetivo de RUP es asegurar la produccion de software de alta calidad
quesatisfaga las necesidades del usuario final dentro de un tiempo y presupuesto
previsibles.

Conceptos fundamentales.
• RUP esta dirigido por casos de uso.
• RUP esta centrado en la arquitectura.
• RUP es Iterativo e incremental.
Dirigido por casos de uso
Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un
resultado de valor al usuario. Modelan los requerimientos funcionales del
sistema.
Todos los casos de uso juntos constituyen el modelo de casos de uso
Los casos de uso guian el proceso de desarrollo (diseño, implementacion y
prueba). Basandose en los casos de uso los desarrolladores crean una serie de
modelos de diseño e implementacion que llevan a cabo los asos de uso. De este
modo los casos de uso no solo inician el proceso de desarrollo, sino que le
proporcionan un hilo conductor, avanza a traves de una serie de flujo de trabajo
que le proporcionan los casos de uso.

Un proceso conducido por casos de Uso:

1. El Modelo de Caso de Usos representa los requisitos funcionales
La primer disciplina que se desarrolla dentro de cada iteración es la de
requerimientos
(posiblemente luego de realizar un modelado del dominio o del negocio). El
objetivo de
esta fase es determinar los requerimientos del sistema. Los requerimientos
funcionales
son plasmados a través de casos de uso en un Modelo de Casos de Uso.
2. Creación del modelo de análisis a partir de los casos de uso
El modelo del análisis es opcional. En él, se describen un conjunto de Clases
del
Análisis que se utilizan para realizar una descripción abstracta de la
realización de los
casos de uso del modelo de casos de uso. Las clases del análisis luego
evolucionan
hacia otras clases más detalladas en el Modelo del Diseño.
El modelo de análisis crece incrementalmente a medida que se analizan más y más
casos de uso. En cada iteración elegimos un conjunto de casos de uso y los
reflejamos en el modelo de análisis. Construimos el sistema como una estructura
de
clasificadores (clases del análisis) y relaciones entre ellas. También
describimos las
colaboraciones que llevan a cabo los casos de uso, es decir las realizaciones de
los
casos de uso.
Durante el Análisis se utilizan diagramas de colaboración para describir la
realización de un caso de uso.
3. Creación del modelo de diseño a partir del modelo de análisis
El modelo de diseño se crea tomando el modelo de análisis como entrada principal
(cuando este fue creado), y se lo adapta a un entorno de implementación
particular.
Esta adaptación incluye considerar por Ej. adecuaciones a un framework de
construcción de GUI particular, uso de un ORB, frameworks, sistemas heredados,
etc.
El modelo de diseño es similar al modelo de análisis ya que incluye
clasificadores,
relaciones, y realizaciones de casos de uso, y existe una relación de traza
entre los
artefactos del diseño y los del análisis, pero mientras estos últimos son
conceptuales,
los del diseño deben adecuarse al entorno de implementación específico.

De manera similar a como lo realizamos en el análisis, debemos identificar la

interacción detallada entre los objetos de diseño que tiene lugar en la
realización del
caso de uso en el modelo del diseño. En el diseño sin embargo, utilizaremos
principalmente diagramas de secuencia para representar esta interacción.

Ej.: Diagrama de secuencia para representar la realización del caso de uso Sacar
Dinero en el modelo de diseño.
Agrupación de clases en subsistemas
Es imposible utilizar sólo clases para realizar los casos de uso en un sistema
grande
con cientos o miles de clases. Es imposible comprender el sistema sin una
organización de más alto nivel. Las clases se agrupan en subsistemas.
Los subsistemas de bajo nivel se denominan subsistemas de servicio. Los
subsistemas de servicio constituyen una unidad manejable de funcionalidad
opcional.
Los subsistemas pueden diseñarse en forma descendente o ascendente.
El diseño ascendente se realiza a partir de la agrupación de clases ya
identificadas. Se
proponen subsistemas que empaquetan clases en unidades claramente definidas.
El diseño descendente, implica la definición previa por parte del arquitecto de
los
subsistemas de más alto nivel y las interfaces entre ellos, antes de que se
hayan
identificado las clases.
Ej.: Para el sistema de CA se agrupan las clases en tres subsistemas:
- <<subsystem>> Interfaz del CA: agrupa todas las clases que proporcionan
la interfaz gráfica del CA:
o Lector de tarjetas
o Dispositivo de visualización
o Teclado
o Alimentador de la salida
o Sensor de la salida
o Contador de efectivo
o Gestor de cliente
- <<subsystem>> Gestión de transacciones
o Gestión de Transacciones
o <<service subsystem>> Gestión de retirada de efectivo
§ Retirada de efectivo
- <<subsystem>> Gestión de cuentas
o Clase Persistente
o Gestor de Cuentas
o Cuenta

La ventaja de colocar todas las clases de interfaz en un subsistema permitiría

reemplazar el subsistema completo para adecuarlo a otra interfaz sin mayores
cambios en el resto del sistema.

4. Creación del modelo de implementación a partir del modelo de diseño

El modelo de implementación está formado por componentes, que incluyen todos los
ejecutables (Ej. ActiveX, JavaBeans, .exe), y otro tipo de componentes como ser
componentes de fichero (código fuente, shell scripts, etc.), componentes de
tabla
(elementos de base de datos), etc.

5. Prueba de casos de uso

Durante la prueba, verificamos que el sistema implementa correctamente su
especificación.
El modelo de prueba está compuesto por: casos de prueba y procedimientos de
prueba.

Un caso de prueba es un conjunto de entradas de prueba, condiciones de

ejecución,
y resultados esperados, desarrollados para un objetivo concreto, tal como probar
un
camino concreto a través de un caso de uso, o verificar que se cumple un
requisito
específico.
Un procedimiento de prueba es una especificación de cómo llevar a cabo la
preparación, ejecución, y evaluación de los resultados de un caso de prueba
particular.

Ej. un caso de prueba especifica la entrada, los resultados esperados, y otras

condiciones relevantes para verificar el flujo básico del caso de uso Sacar
Dinero:
Entradas:
- La cuenta 12-121-1211 del Cliente de Banco tiene un saldo de 350 $
- El Cliente de Banco se identifica correctamente
- El Cliente de Banco solicita la retirada de 200 $ de la cuenta 12-121-1211
- Hay suficiente dinero en el Cajero Automático
Resultados
- El saldo de la cuenta 12-121-1211 disminuye a 150 $
- El Cliente de Banco recibe 200 $ del Cajero Automático
Condiciones
- No se permite que ningún otro caso de uso (instancias de) acceda a la
cuenta 12-121-1211 durante la ejecución del caso de prueba.

Centrado en la arquitectura
La arquitectura de un sistema se describe mediante diferentes vistas del sistema
en construccion.
El concepto de arquitectura de sofware incluye los aspectos estaticos y
dinamicos mas significativos del sistema.
La arquitectura es una vista del diseño completo con las caracteristicas mas
importantes resaltadas dejando los detalles de lado.
Los Casos de uso y la arquitectura estan profundamente relacionados. Lo CdU
deben encajar en la arquitectura,y asu vez la arquitectura debe permitir el
desarrollo de todos los casos de uso.

El arquitecto desarrolla la arquitectura en la siguiente secuencia:

1. Crea un esquema de la arquitectura comenzando por la parte no especifica
de os casos de uso (por ejemplo la plataforma) pero con una comprension
general de los CdU.
2. Trabaja con un conjunto de casos de uso claves o fundamentales(no mas del
10% normalmente). Cada CdU es especificado en datalle y realizado en
terminos de subsistemas, clases y componentes.
3. A medida que los CdU se especifican y maduran se descubre mas de la
arquitectura, y esto a su vez lleva a la maduracion demas casos de uso.
Este proceso continua hasta que se considere estable a la arquitectura.

Un proceso centrado en la arquitectura:

La arquitectura software abarca decisiones importantes sobre:
- La organización del sistema sw.
- Los elementos estructurales que compondrán el sistema y sus interfaces.
- La composición de los elementos estructurales y del comportamiento en
subsistemas progresivamente más grandes
- El estilo de la arquitectura que guía esta organización: los elementos y sus
interfaces, sus colaboraciones y su composición.
La arquitectura se representa mediante vistas del modelo:
- una vista del modelo de casos de uso
- una vista del modelo de análisis
- una vista del modelo de diseño
- una vista del modelo de despliegue
- una vista del modelo de implementación
Estas vistas solo tienen elementos que son arquitectónicamente significativos.
Por
Ej. la vista de los casos de uso tiene los actores y casos de uso
arquitectónicamente
significativos. Lo mismo sucede en los modelos de análisis y diseño.

Importancia y necesidad de una arquitectura

Se necesita una arquitectura para:
- Comprender el sistema
- Organizar el desarrollo
- Fomentar la reutilización
- Hacer evolucionar el sistema

Desarrollo de la arquitectura
La arquitectura se desarrolla mediante iteraciones, principalmente en la etapa
de
elaboración.
El resultado de la fase de elaboración es la línea base de la arquitectura – un
esqueleto del sistema con pocos músculos de software.

Al final de la fase de elaboración hemos desarrollado modelos del sistema que

representan los casos de uso más importantes y sus realizaciones desde el punto
de
vista de la arquitectura.
Esta agregación de modelos es la línea base de la arquitectura.

Descripción de la arquitectura
La línea base de la arquitectura, es la versión interna del sistema al final de
la fase de
elaboración. El conjunto de modelos que describen esta línea base se denomina
Descripción de la Arquitectura.
El papel de la descripción de la arquitectura es guiar al equipo de desarrollo a
través
del ciclo de vida del sistema.
La descripción de la arquitectura tiene cinco secciones, una para cada modelo:
una
vista del modelo de casos de uso, una vista del modelo de análisis (opcional /
descartable), una vista del modelo de diseño, una vista del modelo de
despliegue, y
una vista del modelo de implementación.

La vista de la arquitectura del modelo de casos de uso

Presenta los actores y casos de uso más importantes.
La vista de la arquitectura del modelo de diseño
Presenta los clasificadores más importantes para la arquitectura pertenecientes al
modelo de diseño: los subsistemas e interfaces más importantes, así como algunas
pocas clases muy importantes, fundamentalmente clases activas.
La vista de la arquitectura del modelo de despliegue
Presenta los nodos interconectados y las clases activas que se ejecutan en ellos
identificados durante el diseño.
La vista de la arquitectura del modelo de implementación
El modelo de implementación es una correspondencia directa de los modelos de
diseño y de despliegue.
Cada subsistema de servicio del diseño normalmente termina siendo un componente
por cada tipo de nodo en el que deba instalarse.

Arquitectura: conjunto de decisiones significativas acerca de la organización de

un sistema softare, la selección de los elementos estructurales a partir de los
cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus
colaboraciones y su composicion.

Iterativo e incremental.
Es practico dividir el proceso de desarrollo en partes o mini proyectos.
Cada mini proyecto es una iteracion que resulta en un incremento
Las iteraciones hacen referencia a pasos en el flujo de trabajo y los
incrementos a crecimientos en el producto.
Las iteraciones deben estar CONTROLADAS, es decir, deben seleccionarse y
ejecutarse de una forma PLANIFICADA.
El resultado de una iteracion es un sistema que puede ser probado, integrado y
ejecutado.
El objetivo de esto es la “Ampliacion y refinamiento meidante multiples
iteraciones”.
Los diseñadores basan la seleccion de que debe implementarse en cada iteracion
en:
• el conjunto de casos de uso que amplian la funcionalidad.
• los riesgos mas importantes que deben mitigarse.
En cada iteracion se:
1. identifica los CdU mas relavantes
2. crea el diseño de arquitectura para implementar dichos CdU
3. Si la iteracion cumple los objetivos se continua, caso contrario se reveen
decisiones previas y se prueba un nuevo enfoque.

Beneficios del enfoque iterativo:

• La iteracion controlada reduce el riesgo a los costos de un solo
incremento.
• Reduce el riesgo de retrasos en el calendario atacando los riesgos mas
importantes primero.
• Acelera el desarrollo. Los trabajadores trabajan de manera mas eficiente
al obtener resultados a corto plazo.
• Es realista ya que los requerimientos no pueden definirse completamente al
principio.

Un proceso iterativo e incremental:

Desarrollo en pequeños pasos: Planificar un poco. Especificar, diseñar, e
implementar un poco. Integrar, probar, y ejecutar un poco en cada iteración.

¿Por qué un desarrollo iterativo e incremental?

• Para tomar las riendas de los riesgos críticos y significativos desde el

principio.
• Para poner en marcha una arquitectura que guíe el desarrollo del software.
• Para proporcionar un marco de trabajo que gestione de mejor forma los
• inevitables cambios en los requisitos y en otros aspectos.
• Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una
sola
• vez cerca del final, cuando el cambiar algo se ha vuelto costoso.
• Para proporcionar un proceso de desarrollo a través del cual el personal
puede
• trabajar de manera más eficaz.
•

¿Metodologías y Process Frameworks?

Conceptos Clave del RUP

Proceso de Ingeniería de Software
Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En
ingeniería de software, el objetivo es construir un producto de software nuevo o
extender uno existente. En RUP esto se organiza en un conjunto de Disciplinas
que define un flujo de trabajo.

Disciplina
Una disciplina es una colección de actividades relacionadas vinculadas con un
área específica del proyecto. Este agrupamiento de actividades en disciplinas es
principalmente para facilitar la comprensión del proyecto desde la perspectiva
tradicional del modelo en cascada.

Flujo de trabajo
Un flujo de trabajo describe la secuencia en que se realizan las actividades en
una disciplina, quienes la realizan (trabajadores) y que artefactos producen.

Trabajador (Rol)
Un trabajador o rol, define un comportamiento o responsabilidades de un
individuo o grupo de individuos trabajando en equipo, en el contexto de una
organización de ingeniería de software.
Actividad
Los trabajadores realizan actividades. Una actividad es algo que realiza un
trabajador para proveer un resultado de valor en el contexto de un proyecto.

Pasos (steps)
Las actividades son descompuestas en pasos. Podemos distinguir tres categorías
de pasos:
• Pasos de análisis: donde el trabajador comprende la naturaleza de la
tarea, examina los artefactos de entrada, y formula las salidas.
• Pasos de acción: donde los trabajadores crean o actualizan algunos
artefactos.
• Pasos de revisión: donde los trabajadores inspeccionan los resultados
según determinados criterios.

Artefactos
Las actividades tienen artefactos de entrada y de salida. Un artefacto es un
producto
de trabajo en un proceso: los trabajadores utilizan artefactos para realizar
actividades
y producen artefactos como resultado de sus actividades. Los artefactos son
responsabilidad de un único trabajador y promueven la idea de que toda pieza de
información en el proceso debe ser responsabilidad de un rol específico. Un
trabajador
es el “propietario” de un artefacto, pero otros trabajadores pueden usarlo y tal
vez
modificarlo si tienen permiso para ello.

Principales artefactos en el proceso y flujo de información entre ellos.

El diagrama muestra como la información fluye a través del proyecto vía los
artefactos.

Ciclo de Vida del Proceso Unificado

El proceso unificado se repite a lo largo de una serie de ciclos que construyen
la vida de un sistema. Cada ciclo constituye una version del sistema.
Son ciclos estructurados de construir-retroalimentar-adaptar.
Fases.
Cada ciclo consta de cuatro fases:
 Inicio: definir el alcance del proyecto.
 Elaboracion: planificar el proyecto, elaborar una arquitectura base.
 Construccion: construir el sistema.
 Transicion: Transicion a los usuarios.
Cada fase se divide en iteraciones.

Fase de inicio:
Durante la fase de inicio se desarrolla una descripcion del producto final,y se
presenta el ANALISIS DEL NEGOCIO.
Esta fase responde las siguientes preguntas:
• ¿Cuales son las principales funciones del sistema para los usuarios mas
importantes?
• ¿Como podria ser la mejor arquitectura del sistema?
• ¿Cual es el plan del proyecto y caunto costara desarrollar el producto?
En esta fase se identifican y priorizan los riesgos mas importantes

El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuales son

los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes
soluciones posibles y diferentes arquitecturas posibles.

Puede que todo el trabajo fisico de esta fase se descarte pero el conocimiento
del equipo es lo importante.

Los artefactos que normalmente sobreviven esta fase son:

➢ Un enunciado de los mayores requerimientos planteados generalmente como
casos de uso.
➢ Un boceto inicial de la arquitectura.
➢ Una descripcion de los objetivos del proyecto.
➢ Una version muy preliminar del plan del proyecto.
➢ Un modelo del negocio.
Esta Fase finaliza con el Hito de Objetivos del Ciclo de vida.

Este hito es alcanzado cuando el equipo de proyecto y los stakeholders llegan a

un acuerdo sobre:
➔ Cual es el conjunto de necesidades del negoio, y que conjunto de funciones
satisfacen estas necesidades.
➔ Una planificacion preeliminar de iteraciones.
➔ Una arquitectura preliminar.

Debe poder responderse las siguientes preguntas al alcanzar este hito:

✔ Se ha determinado con claridad el ambito del sistema. Que va dentro y
fuera del sistema.
✔ ¿Se ha llegado a un acuerdo con todas las personas
involucradas(stakeholders) sobre los requisitos funcionales?
✔ ¿Se vislumbra una arquitectura que puede soportar estas caracteristicas?
✔ ¿Se identifican los riesgos criticos y la forma de mitigarlos?
✔ ¿El uso del producto justifica el costo-beneficio?
✔ ¿Es factible para la organización llevar a cabo el proyecto?
✔ ¿Estan los inversores de acuerdo con los objetivos?

Fase de Elaboracion:
Durante la fase de elaboracion se especifican en detalle la mayoria de los casos
de uso del producto y se diseña la arquitectura.
Las iteraciones en esta fase:
 Establecen una firme comprension del problema a solucionar
 Establecen la fundacion arquitectural para el Software
 Establecen un plan detallado para las siguientes iteraciones
 Eliminan los mayores riesgos
El resultado de esta fase es la linea de arquitectura.

Se contruyen los siguientes artefactos:

 ➢ El cuerpo basico del Software en la forma de un prototipo arquitectural
➢ Casos de prueba
➢ La especificacion de la maoria de los casos de uso (80%) que describen la
funcionalidad del sistema.
➢ Un plan detallado para las siguientes iteraciones.

La fase termina con el Hito de la Arquitectura del Ciclo de Vida.

Este hito se alcanza cuando el equipo y los stakeholder concuerdan en:
➔ Los casos de uso que describen la funcionalidad
➔ La linea base de la arquitectura
➔ Que los mayores riesgos han sido mitigados
➔ Se ha establecido un plan del proyecto, un plan de iteraciones para las
fases de construccion y transicion.

Al alcanzar el hito debe poder responderse estas preguntas:

✔ ¿Se ha creado una linea base de la arquitecutra que es adaptable, robusta
y puede evolucionar?
✔ ¿Se han identificado y mitigado los riesgos mas grandes?
✔ ¿Se ha desarrollado un plan de proyecyo hasta el nivel necesario para
respaldar una agenda, costes y calidad realistas?
✔ ¿Se ha obtenido la aprobacion de los inversores?

Fase de Construccion:
Durante la fase de contruccion se crea el producto.La linea base de la
arquitectura crece hasta convertirse en el sistema completo.
Al final de esta el producto contiene todos los casos de uso implementados, sin
embargo puede no estar libre de defectos.

Los artefactos producidos en esta fase son:

➢ El sistema software
➢ Los casos de prueba
➢ Los manuales de usuario.

La fase finaliza con el Hito Capacidad Operativa Inicial

Este hito se alcanza cuando se acuerda con los stakeholders sobre:
➔ El producto es estable para ser usado
➔ El producto provee alguna funcionalidad de valor
➔ Todas las partes estan listas para comenzar la transicion.

Fase de Transicion:
cubre el periodo durante el cual el producto se convierte en version beta.
Las iteraciones en esta fase continuan agregando caracteristicas al software.
Sin embargo las caracteristicas se agregan a un sistema que el usuario ya se
encontra usando.
El equipo se encuentra ocupado fundamentalmente en corregir y extender la
funcionalidad del sistema desarrollado en la fase anterior.

Los artefatos contruidos en esta fase son los mismos que en la fase de
contruccion.

La fase finaliza con el Hito de Lanzamiento del Producto.

Este hito se alcanza cuando el equipo se pone de acuerdo con los stakeholders
en:
➔ Se han alcanzado los objetivos fijados en la fase de inicio.
➔ El usuario esta satisfecho con los resultados.

Hitos
Cada fase finaliza con un hito. Cada hito se determina por la diponibilidad de
un conjunto de artefactos, es decir, un conjunto de modelos o documentos que han
sido desarrollados hasta alcanzar un estado predefinido.
Los hitos tienen muchos objetivos pero el mas critico es que “los directores
deben tomar ciertas deciciones antes de que el trabajo continue con la siguiente
fase.
Los hitos permiten controlar la direccion y progreso del trabajo. Con los datos
del seguimiento de tiempo y esfuerzo consumido en cada fase se pueden realizar
estimaciones de proyecto.

FASE HITOS con los que finaliza

Inicio Objetivos del Ciclo de vida
Elaboracion Arquitectura del Ciclo de Vida
Construccion Hito Capacidad Operativa Inicial
Transicion Lanzamiento del Producto

Iteraciones
Una iteración es un mini proyecto, un recorrido más o menos completo a lo largo
de todos los flujos de trabajo fundamentales, que obtiene como resultado una
versión interna del sistema.
En cada iteracion se desarrolla en secuencia un conjunto de disciplinas o flujos
de trabajos.

Disciplinas básicas
Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo)
vinculadas a un área especifica dentro del proyecto total. Las mas importantes
son:

Disciplina Modelo que realiza

Requerimientos Modelo de casos de uso
Analisis Modelo de analisis
Diseño Modelo de diseño – Modelo de despliegue
Codificacion Modelo de implementacion
Prueba Modelo de pruebas.
Cada disiciplina esta asociada a un conjunto de modelos. Estos modelos estan
compuestos por artefactos.
Disciplina Captura de requisitos:
El propósito fundamental del flujo de trabajo de los requisitos es guiar el
desarrollo hacia el sistema correcto.
Hay diferentes puntos de partida para la captura de requisitos:
• Haciendo un modelo del negocio
• Tomando un modelo del negocio ya desarrollado
• Si es un sistema acotado que no da soporte al negocio podemos partir de un
modelo de objetos sencillo como un modelo del dominio
• El cliente puede ya haber desarrollado una especificación completa de
• requisitos no basada en objetos

En forma típica, el flujo de trabajo de requisitos incluye los siguientes pasos:

• Enumerar los requisitos candidatos.
• Comprender el contexto del sistema.
• Capturar requisitos funcionales.
• Capturar requisitos no funcionales.

Enumerar los requisitos candidatos:

La lista de características deseadas del sistema constituyen los requisitos
candidatos.
De cada característica se registra:
- Nombre corto
- Descripción
- Estado (propuesto, aprobado, incluido, o validado)
- Coste estimado de implementación (en término de tipos de recursos y
horas-hombre)
- Prioridad (crítico, importante, o secundario)
- Nivel de riesgo asociado a la implementación de la característica (crítico,
significativo, ordinario)

Estos valores se utilizan para estimar el tamaño del proyecto y decidir cómo
dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados
por ejemplo, se utiliza para decidir en que iteración se implementará la
característica.

Comprender el contexto del sistema

Hay por lo menos dos aproximaciones para expresar el contexto de un sistema:
modelado del dominio y modelado del negocio.

Un modelo del dominio describe los conceptos importantes del contexto como
objetos del dominio relacionados entres sí.

Un modelo del negocio es más amplio. Describe los procesos con el objetivo de
comprenderlos. El modelado del negocio especifica que procesos de negocio
soportará el sistema.

Capturar requisitos funcionales

Los requisitos funcionales son capturados por medio de casos de uso, que
conforman el modelo de casos de uso. Los casos de uso también capturan
requisitos no funcionales específicos de un caso de uso determinado.

Capturar requisitos no funcionales

Los requisitos no funcionales especifican propiedades del sistema, como
restricciones del entorno o de la implementación, rendimientos, etc.
Hay requisitos no funcionales específicos para un caso de uso y otros genéricos
para la aplicación. Los que son específicos para un caso de uso, pueden
documentarse junto con el caso de uso correspondiente. Los que son más genéricos
se documentan por medio de una lista de requisitos adicionales.

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 entorno en el que trabaja el sistema.
Las clases del dominio aparecen en tres formas típicas:
➔ Objetos del negocio que representan cosas que se manipulan en el negocio,
como pedidos, cuentas, contratos, etc.
➔ Objetos del mundo real y conceptos de los que el sistema debe hacer
seguimiento como aviación enemiga, misiles, trayectorias, etc.
➔ Sucesos que ocurrirán o han ocurrido, como llegada de un avión, su salida,
hora de la comida, etc.
El modelo de dominio se representa fundamentalmente por diagramas de clases en
UML.
El objetivo del modelado del dominio es comprender y describir las clases más
importantes dentro del contexto del sistema.

Modelo del Negocio.

El modelado del negocio es una técnica para comprender los procesos de negocio
de la organización.
El modelado del negocio está soportado por dos tipos de modelos de UML: el
modelado de casos de uso, y modelos de objetos.
Un Modelo de Casos de Uso del Negocio describe los proceso de negocio de una
empresa en términos de casos de uso del negocio y actores del negocio que se
corresponden con los procesos del negocio y los clientes respectivamente.
Al igual que el modelo de casos de uso para un sistema software, el modelo de
casos de uso del negocio presenta un sistema (en este caso, el negocio) desde la
perspectiva de su uso, y esquematiza como proporciona valor a sus usuarios.

Un modelo de objetos del negocio describe como cada caso de uso del negocio es
llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto
de entidades del negocio y de unidades de trabajo.
Cada realización de un caso de uso del negocio puede mostrarse en diagramas de
interacción y diagramas de actividad.
Una entidad del negocio representa algo que los trabajadores toman, manipulan,
inspeccionan, producen o utilizan en un negocio.
Una unidad de trabajo es un conjunto de esas entidades que conforma un todo
reconocible para el usuario final.

La técnica de modelado de negocio identifica entidades y trabajadores que

participan en la realización de los casos de uso del negocio.
Los trabajadores identificados en el modelo de negocio se utilizan como punto de
partida para derivar un primer conjunto de actores y casos de uso del sistema.

Búsqueda de Casos de Uso a partir de un modelo del negocio

En primer lugar se identifica un actor por cada trabajador y por cada actor del
negocio (es decir, el cliente).
Cada trabajador y actor del negocio que vaya a ser usuario del sistema de
información requerirá un soporte por parte del mismo. El soporte necesario se
determina tratando cada uno de los actores uno detrás de otro.
Una vez que hemos encontrado todos los roles de un trabajador o actor del
negocio, uno por cada caso de uso del negocio en el que participa, podemos
encontrar los casos de uso de los actores del sistema.
La manera más directa de identificar un conjunto tentativo de casos de uso es
crear un caso de uso para el actor correspondiente a cada rol de cada trabajador
y de cada actor del negocio. Los analistas pueden después ajustar los casos de
uso tentativos.

Requisitos adicionales
Los requisitos adicionales, son requerimientos No funcionales que no pueden
asociarse a ningún caso de uso en particular. Algunos ejemplos son el
rendimiento, las interfaces, y los requisitos de diseño físico, así como las
restricciones arquitectónicas.
Los requisitos adicionales se capturan de forma muy parecida a como se hacía en
la especificación de requisitos tradicional, es decir con una lista de
requisitos. Luego se utilizan durante el análisis junto al modelo de casos de
uso.

Captura de requisitos como casos de uso.

Los requisitos funcionales se estructuran de forma natural mediante casos de uso
que constituyen el Modelo de Casos de Uso.
Los requisitos no funcionales restantes, se modelan como dijimos en el documento
de requisitos adicionales.

REQUISITOS
Actividad Trabajador Resp. de Artefactos (entrada)
(Salida)
1 Analista de Modelo de casos de uso Modelo del negocio o
Encontrar actores y Sistemas (esbozado) Modelo del dominio
casos de uso Glosario Requisitos adicionales
Actores Lista de características
2 Arquitecto Descripción de la Modelo de casos de uso
Priorizar casos de arquitectura (vista del (esbozado)
uso mod.de casos de uso)
3 Especificador de Caso de uso (detallado) Requisitos adicionales
Detallar Casos de casos de uso Glosario
Uso
4 Analista de Modelo de casos de uso Modelo de casos de uso
Estructurar el modelo Sistemas (estructurado) (esbozado)
de casos de uso Requisitos adicionales
Glosario
5 Diseñador de Prototipo de interfaz de Modelo de casos de uso
Prototipar interfaz de Interfaz de usuario Requisitos adicionales
usuario usuario Caso de uso (detallado)
Glosario

Artefacto: Modelo de casos de uso

Un modelo de casos de uso es un modelo del sistema que contiene actores, casos
de uso y sus relaciones.

Artefacto: actor
El modelo de casos de uso describe lo que hace el sistema para cada tipo de
usuario.
Cada uno de éstos se representa mediante uno o más actores.
Los actores suelen corresponderse con trabajadores (o actores del negocio).

Artefacto: Caso de Uso

Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para
aportar un resultado de valor para sus actores.
Para cada caso de uso debe detallarse su flujo de sucesos. El flujo de sucesos
puede plasmarse en forma textual y describe como interactúa el sistema con los
actores cuando se lleva a cabo un caso de uso.
Tambien pueden vincularse a un caso de uso requisitos no funcionales específicos
del caso de uso.

Artefacto: Descripción de la arquitectura (vista del modelo de casos de

uso)
La descripción de la arquitectura contiene una vista de la arquitectura del
modelo de casos de uso, que representa los casos de uso significativos para la
arquitectura.

Artefacto: glosario
Podemos utilizar un glosario para definir términos comunes importantes que los
analistas utilizan para describir el sistema.

Artefacto: prototipo de interfaz de usuario

Los prototipos de interfaz de usuario nos ayudan a comprender y especificar las
interacciones entre actores humanos y el sistema durante la captura de
requisitos.

Trabajadores
Analizamos los trabajadores responsables de crear los artefactos mencionados.

Trabajador: analista de sistemas

Responsable de:
- modelo de casos de uso
- actores que contiene
- glosario

Trabajador: especificador de casos de uso

Asisten al analista de sistema en la descripción detallada de cada caso de uso.
Responsable de:
- caso de uso

Trabajador: diseñador de interfaz de usuario

Responsable de:
- prototipo de interfaz de usuario

Trabajador: arquitecto
Responsable de:
- descripción de la arquitectura (vista del modelo de casos de uso)

Flujo de Trabajo

Actividad: encontrar actores y casos de uso

Identificamos actores y casos de uso para:
• - Delimitar el sistema de su entorno
• - Esbozar quién y qué (actores) interactuarán con el sistema, y que
funcionalidad (casos de uso) se espera del sistema
• - Capturar y definir un glosario de términos comunes esenciales para la
creación de descripciones detalladas de las funcionalidades del sistema.

Esta actividad consta de cuatro pasos:

1. - Encontrar los actores
2. - Encontrar los casos de uso
3. - Describir brevemente cada caso de uso
4. - Describir el modelo de casos de uso completo (este paso tambien incluye
la preparación de un glosario de términos)
Estos pasos no tienen que ser ejecutados en un orden determinado, y a menudo se
hacen simultáneamente.

Encontrar actores:
Depende de nuestro punto de partida.
Si partimos de un modelo del negocio, el analista puede asignar un actor a cada
trabajador del negocio y un actor a cada actor del negocio (cliente) que
utilizará información del sistema.
En otro caso, con o sin un modelo del dominio, el analista del sistema junto con
el cliente identifica los usuarios e intenta organizarlos en categorías
representadas por actores.
En ambos casos hay que identificar actores que representan sistemas externos y
los actores de mantenimiento y operación del sistema.
Los actores modelan roles.

Encontrar casos de uso:

Cuando se parte de un modelo del negocio, se propone un caso de uso para cada
rol de trabajador que utilizará información del sistema.
El método más general es la identificación a partir del análisis de cada actor
por separado.

Actividad: priorizar casos de uso

El propósito de esta actividad es priorizar cuales son los casos de uso más
importantes para abordar en las primeras iteraciones.
Los resultados se recogen en la vista de la arquitectura del modelo de casos de
uso.
Esta vista revisada con el jefe de proyecto se utiliza como entrada al hacer la
planificación de lo que debe desarrollarse dentro de una iteración.

Actividad: detallar casos de uso

El objetivo principal de detallar cada caso de uso es describir su flujo de
sucesos en detalle, incluyendo como comienza, termina, e interactúan con los
actores.
Para detallar los casos de uso se usan:
• Descripciones textuales
• Diagramas de transición de estados para describir los estados de los casos
de uso y las transiciones entre esos estados
• Diagramas de actividad para describir transiciones entre estados con más
detalle como secuencias de acciones. Los diagramas de actividad pueden
describirse como la generalización de los diagramas de transición de
estados
• Diagramas de interacción para describir cómo interactúa una instancia de
caso de uso con la instancia de un actor. Los diagramas de interacción
muestran el caso de uso y el actor o actores participantes.

Para cada caso de uso debe detallarse:

• Estado inicial como precondición
• Cómo y cuando comienza el caso de uso (primera acción a ejecutar)
• Orden en que deben ejecutarse las acciones (puede ser una secuencia
numerada)
• Cómo y cuando terminan los casos de uso
• Posibles estados finales como postcondiciones
• Caminos de ejecución que no están permitidos
• Camino básico
• Caminos alternativos

Actividad: prototipar interfaz de usuario

Comenzamos con los casos de uso e intentamos discernir que se necesita de las
interfaces de usuario para habilitar los casos de uso para cada actor. Hacemos
un diseño lógico de la interfaz de usuario, luego creamos un modelo físico, y
desarrollamos prototipos para ilustrar como pueden utilizar el sistema los
usuarios para ejecutar los casos de uso.

Actividad: estructurar el modelo de casos de uso

Los casos de uso identificado son estructurados utilizando las relaciones de uso
(secuencias comunes), extensiones (casos excepcionales), y generalizaciones.

Disciplina de Análisis:
Durante el análisis, analizamos los requisitos que se describieron en la captura
de requisitos, refinándolos y estructurándolos. El objetivo de hacerlo es
conseguir una comprensión más precisa de los requisitos y una descripción de los
mismos que sea fácil de mantener y que nos ayude a estructurar el sistema
entero, incluyendo su arquitectura.

Conceptos generales.
Comparación del modelo de casos de uso con el modelo del análisis:
Modelo de casos de uso Modelo de Análisis
Descrito en el lenguaje del cliente. Descrito en el lenguaje del
desarrollador.
Vista externa del sistema. Vista interna del sistema.
Estructurado por casos de uso; Estructurado por clases y paquetes
proporciona la estructura a la vista estereotipados; proporciona la
externa. estructura a la vista interna.
Utilizado fundamentalmente como Utilizado fundamentalmente por los
contrato entre el cliente y los desarrolladores para comprender cómo
desarrolladores sobre qué debería y deberá darse forma al sistema, es
qué no debería hacer el sistema. decir, cómo debería ser diseñado e
implementado.
Puede contener redundancias e No debería contener redundancias ni
inconsistencias entre requisitos. inconsistencias entre requisitos.
Captura la funcionalidad del sistema, Esboza cómo llevar a cabo la
incluida la funcionalidad significativa funcionalidad dentro del sistema,
para la arquitectura. incluida la funcionalidad significativa
para la arquitectura; sirve como una
primera aprox. al diseño.
Define casos de uso que se analizarán Define realizaciones de caso de uso, y
con más profundidad en el modelo de cada una de ellas representa el
análisis. análisis de un caso de uso del modelo
de casos de uso.

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

conceptual, que llamamos modelo de análisis. El modelo de análisis nos ayuda a
refinar los requisitos.
Analizar los requisitos en la forma de un modelo de análisis es importante por
varios motivos:
• Un modelo de análisis ofrece una especificación más precisa de los
requisitos que la que tenemos como resultado de la captura de requisitos,
incluyendo al modelo de casos de uso.
• Un modelo de análisis se describe utilizando el lenguaje de los
desarrolladores, y se puede por tanto introducir un mayor formalismo y ser
utilizado para razonar sobre los funcionamientos internos del sistema.
• Un modelo de análisis estructura los requisitos de un modo que facilita su
comprensión, su preparación, su modificación, y en general, su
mantenimiento.
• Un modelo de análisis puede considerarse como una primera aproximación al
modelo de diseño (aunque es un modelo por sí mismo), y es por tanto una
entrada fundamental cuando se da forma al sistema en el diseño y en la
implementación.

Artefactos.
ANALISIS
Actividad Trabajador Resp. de Artefactos (entrada)
(Salida)
1 Arquitecto Modelo de Analisis Modelo de casos de uso
Análisis de la {Paquete del análisis Requisitos adicionales
arquitectura (esbozado) Modelo del negocio o
Clase del análisis modelo del dominio
(esbozada)} Descripción de la
Descripción de la arquitectura (vista del
arquitectura (vista del modelo de casos de
modelo de análisis) uso)
2 Ingeniero de Realización de caso de Modelo de casos de uso
Analizar un caso de casos de uso uso (análisis) Requisitos adicionales
uso Clase del análisis Modelo del negocio o
(esbozo) modelo del dominio
Descripción de la
arquitectura (vista del
modelo de análisis)
3 Ingeniero de Clase del análisis Realización de caso de
Analizar una clase componentes (terminada) uso-
análisis
Clase del análisis
(esbozo)
4 Ingeniero de Paquete del análisis Descripción de la
Analizar un paquete componentes (terminado) arquitectura (vista del
modelo de análisis)
Paquete del análisis
(esbozo)

Artefacto: Modelo del análisis

Compuesto por un sistema de análisis que es el paquete de más alto nivel, el
cual se compone a su vez de otros paquetes y clases de análisis y realizaciones
de casos de uso.
Artefacto: clase del análisis
Una clase de análisis representa una abstracción de una o varias clases y/o
subsistemas del diseño.

Características:
• Se centra en el tratamiento de requisitos funcionales y pospone los no
funcionales para el diseño.
• Es más “conceptual”.
• Raramente define una interfaz en términos de operaciones y sus signaturas.
Su comportamiento se define mediante “responsabilidades” en un nivel más
alto y menos formal. Una responsabilidad es una descripción textual de un
conjunto cohesivo del comportamiento de una clase.
• Define atributos en un nivel tambien conceptual y reconocibles en el
dominio del problema, mientras que en el diseño los atributos se ajustan a
tipos del lenguaje de programación.
• Las relaciones entre clases del análisis también son más conceptuales. Por
ejemplo no se da importancia a la navegación de la relación.
• Las clases de análisis siempre encajan en alguno de los estereotipos
básicos: de interfaz, de control, o entidad.

➢ Clases entidad: se derivan de las clases entidad del negocio (o dominio).

➢ Clases de control: encapsulan el control de casos de uso, o cálculos
complejos.
➢ Clases de interfaz: modelan la interacción entre actores y el sistema.

Artefacto: realización caso de uso análisis

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 del análisis y sus objetos del análisis en
interacción.
Una realización de caso de uso análisis posee una descripción textual del flujo
de sucesos, diagramas de clases participantes, y diagramas de interacción que
muestran la realización de un flujo o escenario particular del caso de uso en
término de objetos del análisis.
Artefacto: paquete del análisis
Los paquetes del análisis proporcionan un medio para organizar los artefactos
del modelo de análisis en piezas manejables. Un paquete de análisis puede
constar de clases de análisis, de realizaciones de casos de uso, y de otros
paquetes del análisis recursivamente.
Los paquetes del análisis son particionamientos funcionales del sistema basados
en el dominio del problema y debería ser reconocibles por las personas con
conocimiento del dominio.
Los paquetes del análisis probablemente se convertirán en subsistemas en las dos
capas de aplicación superiores del modelo de diseño, o se distribuirán entre
ellos.

Paquete de servicio
Un servicio representa un conjunto coherente de acciones relacionadas
funcionalmente (un paquete de funcionalidad) que se utiliza en varios casos de
uso.
Un cliente de un sistema normalmente compra una combinación de servicios para
ofrecer a sus usuarios los casos de uso necesario. Un servicio es indivisible en
el sentido de que el sistema necesita ofrecerlo o todo entero o nada en
absoluto.
Los casos de uso atraviesan los servicios, es decir, un caso de uso requiere
acciones de varios servicios.
En RUP, el concepto de servicio está soportado por los paquetes de servicio.
Los paquetes de servicio se utilizan en el nivel más bajo de la jerarquía (de
agregación) de paquetes de análisis para estructurar el sistema de acuerdo a los
servicios que proporciona.
Podemos observar lo siguiente acerca de los paquetes de servicio:
• Un paquete de servicios contiene un conjunto de clases relacionadas
funcionalmente.
• Un paquete de servicios es indivisible.
• Para llevar a cabo un caso de uso puede que participen más de un paquete
de servicios.
• Un paquete de servicios puede depender de otro paquete de servicios.
• Un paquete de servicios normalmente es relevante para un pequeño grupo de
actores.
• Un paquete de servicios puede gestionarse como una unidad de distribución
independiente. Puede representar una funcionalidad “adicional” del
sistema.
• Los paquetes de servicio pueden ser mutuamente excluyentes, o pueden
representar diferentes variantes del mismo servicio.
• Los paquetes de servicio constituyen la entrada fundamental para las
actividades de diseño e implementación subsiguientes, dado que ayudarán a
estructurar los modelos de diseño e implementación en términos de
subsistemas de servicio.

Artefacto: descripción de la arquitectura (vista del modelo de análisis)

Los siguientes artefactos del modelo de análisis se consideran significativos
para la arquitectura:
• Descomposición del modelo de análisis en paquetes de análisis y sus
dependencias. Esta descomposición suele tener su efecto en los subsistemas
de las capas superiores durante el diseño e implementación.
• Las clases fundamentales del análisis.
• Realizaciones de casos de uso que describen funcionalidades importantes y
 críticas, probablemente las correspondientes a los casos de uso que
aparecen en la vista de la arquitectura del modelo de casos de uso.

Trabajadores
Trabajador: Arquitecto
Es responsable de la integridad del modelo de análisis, garantizando que sea
correcto consistente, y legible como un todo.
El arquitecto es responsable de:
- la descripción de la arquitectura
- modelo del análisis

Trabajador: Ingeniero de casos de uso

Es responsable de la integridad de una o más realizaciones de caso de uso,
garantizando que cumplen los requisitos que recaen sobre ellos.
El ing. de casos de uso es responsable de:
- realización de casos de uso – análisis

Trabajador: Ingeniero de componentes

Define y mantiene las responsabilidades, atributos, relaciones, y requisitos
especiales de una o varias clases del análisis asegurándose de que cada clase
del análisis cumple los requisitos que se esperan de ella de acuerdo a las
realizaciones de caso de uso en que participan.
También mantiene la integridad de uno o varios paquetes del análisis.
El ingeniero de componentes es responsable de:
- clase del análisis
- paquete del análisis

Flujo de Trabajo.
Actividad: análisis de la arquitectura
El propósito de análisis de la arquitectura es esbozar el modelo de análisis y
la arquitectura mediante la identificación de paquetes del análisis, clases del
análisis evidentes, y requisitos especiales comunes.

Identificación de paquetes de análisis

Los paquetes proporcionan un medio para organizar el modelo de análisis en
piezas más pequeñas y manejables.
Pueden identificarse inicialmente como forma de dividir el análisis o
encontrarse a medida que se avanza en el análisis.
Una identificación inicial se hace de manera natural basándonos en los
requisitos funcionales y en el dominio de problema, agrupando un cierto número
de casos de uso en un paquete concreto, y realizando la funcionalidad
correspondiente dentro de dicho paquete. Algunos criterios para agrupar casos de
uso son:
• Casos de uso para dar soporte a un determinado proceso de negocio.
• Casos de uso para dar soporte a un determinado actor del sistema.
• Casos de uso relacionados mediante relaciones de generalización y de
extensión.

Cuando dos paquetes necesitan compartir una misma clase, es conveniente ubicar
dicha clase en su propio paquete.

Identificación de paquetes de servicio

La identificación de paquetes de servicio se suele hacer cuando el trabajo de
análisis está avanzado, cuando se comprenden bien los requisitos funcionales, y
existen la mayoría de las clases del análisis.

Para identificar paquetes de servicio debemos:

• Identificar un paquete de servicio por cada servicio opcional. El paquete
de servicio será una unidad de compra. (por ej. enviar avisos a clientes)
• Identificar un paquete de servicio por cada servicio que podría hacerse
opcional, incluso aunque todos los clientes siempre lo quieran.

Definición de dependencias entre paquetes del análisis

Deben definirse dependencias entre los paquetes del análisis si sus contenidos
están relacionados. La dirección de la dependencia debería ser la misma
(navegabilidad) dirección de la relación.
Buscamos definir paquete que sean débilmente acoplados y altamente cohesivos con
respecto a las clases que contienen.
Para hacer más claras las dependencias puede ser útil estratificar el modelo de
análisis haciendo que los paquetes específicos de la aplicación queden en una
capa de nivel superior y los paquetes generales queden en una capa inferior.

Identificación de clases de entidad obvias

Pueden identificarse una lista de clases entidad candidatas basado en las clases
del dominio o las entidades del negocio.
Sin embargo la mayoría de las clases se identificarán al crear las realizaciones
de casos de uso. Por lo cual en esta etapa es conveniente con un esbozo inicial
de las clases significativas para la arquitectura.

Identificación de requisitos especiales

Un requisito especial es un requisito que aparece durante el análisis y que es
importante anotar de forma que pueda ser tratado adecuadamente en las
subsiguientes actividades de diseño e implementación.
Como ejemplos podemos citar restricciones sobre:
- persistencia
- distribución y concurrencia
- características de seguridad
- tolerancia a fallos
- gestión de transacciones

Actividad: analizar un caso de uso

Analizamos un caso de uso para:
 • Identificar las clases del análisis cuyos objetos son necesarios para
llevar a cabo el flujo de suceso del caso de uso.
• Distribuir el comportamiento del caso de uso entre objetos del análisis
que interactúan.
• Capturar requisitos especiales sobre la realización del caso de uso.

Identificación de clases del análisis

Buscamos clases de entidad, control, e interfaz y esbozamos sus nombres,
responsabilidades, atributos, y relaciones.
Podemos utilizar las siguientes guías para identificar clases:
• Identificar clases entidad a partir de considerarse que información debe
utilizarse y manipularse para realizar el caso de uso.
• Identificar una clase de interfaz para cada actor humano, y dejar que esta
clase represente la ventana principal de la interfaz de usuario con la
cual interactúa el actor.
• Identificar una clase de interfaz primitiva para cada clase de entidad que
hayamos encontrado anteriormente. Estas clases representan objetos lógicos
con los que interactúa el actor en la interfaz de usuario.
• Identificar una clase de interfaz central para cada actor que sea un
sistema externo.
• Identificar una clase de control responsable del tratamiento del control y
de la coordinación de la realización del caso de uso, y después refinar
esta clase de control de acuerdo a los requisitos del caso de uso.

Descripción de las interacciones entre objetos del análisis

Se utiliza un diagrama de colaboración para describir como interactúan los
objetos encontrados para realizar el caso de uso. Podemos observar lo siguiente:
• Un caso de uso se inicia mediante un mensaje proveniente de una instancia
de un actor.
• Cada clase identificada en el paso anterior debe tener una instancia en
esta colaboración.
• Los mensajes no se asocian con operaciones, ya que las clases de análisis
se definen en término de responsabilidades no en operaciones atómicas.
• Los enlaces del diagrama son instancias de las asociaciones entre clases
del análisis.

Captura de requisitos especiales

Recogemos todos los requisitos adicionales inherentes al caso de uso que se está
tratando.

Actividad: analizar una clase

Los objetivos de analizar una clase son:
• Identificar y mantener las responsabilidades de la clase, basadas en su
papel en las realizaciones de casos de uso.
• Identificar atributos y relaciones de la clase.
• Capturar requisitos especiales sobre la realización de la clase.

Actividad: analizar un paquete

Los objetivos de analizar una clase son:
• Garantizar que el paquete es tan independiente de otros como sea posible.
• Garantizar que el paquete del análisis cumple su objetivo de realizar
algunas clases del dominio o casos de uso.
• Describir las dependencias de forma que pueda estimarse el efecto de los
cambios futuros.

Disciplina de Diseño:
Durante el diseño modelamos el sistema y su arquitectura para que soporte los
requisitos funcionales y no funcionales. Una entrada esencial al diseño es el
modelo
de análisis.

Conceptos generales.
Comparación modelo del análisis – modelo del diseño
Modelo de Análisis Modelo de Diseño
Modelo conceptual. Modelo físico (implementación)
Genérico respecto al diseño (aplicable Específico para una implementación
a varios
diseños)
Tres estereotipos: entidad, control, Cualquier nro. de estereotipos físicos.
interface.
Menos formal. Mas formal.
Menos caro de desarrollar Más caro.
Menos capas. Más capas.
Dinámico (no muy centrado en la Dinámico (muy centrado en la secuencia)
secuencia)
Creado principalmente como trabajo Creado fundamentalmente como
manual “programación
visual” en ing.de ida y vuelta.
Puede no mantenerse todo el ciclo de Debe ser mantenido todo el ciclo de
vida. vida.

El diseño es el centro de atención al final de la fase de elaboración y comienzo

de las iteraciones de construcción.

DISEÑO
Actividad Trabajador Resp. de Artefactos (entrada)
(Salida)
1 Arquitecto Modelo de diseño Modelo de casos de uso
Diseño de la Subsistema (esbozado) Requisitos adicionales
arquitectura Interfaz (esbozada) Modelo de análisis
Clase de diseño Desc.de la arq. (vista
(esbozada) del
Modelo de despliegue modelo de análisis)
(esbozado)
Desc.de la arq. (vista
de los modelos de
diseño y distr.)
2 Ingeniero de Realización de caso de Modelo de casos de uso
Diseño de un caso de casos de uso uso (diseño) Requisitos adicionales
uso Clase de diseño Modelo de análisis
(esbozada) Modelo de diseño
Subsistema (esbozado) Modelo de despliegue.
Interfaz (esbozada)
3 Ingeniero de Clase de diseño Realización de casos de
Diseño de una clase componentes (terminada) uso
– diseño
Clase de diseño
(esbozada)
 Interfaz (esbozada)
Clase del análisis
(terminada)
4.Diseño de un Ingeniero de Subsistema (terminado) Desc. de la arquitectura
subsistema componentes Interfaz (terminada) (vista del mod. de
diseño)
Subsistema (esbozado)
Interfaz (esbozada)

Artefactos
Artefacto: Modelo del Diseño
El modelo de diseño es un modelo de objetos que describe la realización física
de los casos de uso centrándose en los requisitos funcionales como en los no
funcionales.
Las abstracciones del modelo de diseño tienen una correspondencia directa con
los elementos físicos del ambiente de implementación.

Artefacto: Clase del Diseño

Una clase de diseño es una abstracción sin costuras con una clase o construcción
similar en la implementación del sistema.
- Se especifica en el lenguaje de implementación (Java, C#, etc).
- Se especifica visibilidad de atributos y operaciones.
- Se implementan las relaciones de generalización vía herencia del lenguaje
de programación.
- Se implementan las relaciones de asociación y agregación vía atributos de
las clases que implementan las referencias.
- Se especifican los métodos con la sintaxis del lenguaje de programación.
- Se usan estereotipos que se corresponden con el lenguaje de
programación, por ejemplo en VB se puede utilizar <<class module>>,
<<form>>, etc.

Artefacto: realización de caso de uso (diseño)

Es una colaboración en término de clases de diseño que describe como se realiza
un caso de uso específico. Una realización de caso de uso diseño, tiene una
traza directa a la correspondiente realización del caso de uso análisis.
Una realización de caso de uso-diseño se describe utilizando:
- Diagramas de clases para mostrar los objetos participantes en la realización.
- Diagrama de interacción, particularmente diagramas de secuencia, enfatizando
en la secuencia de mensajes.
- Flujos de sucesos-diseño, descripción textual que explica y complementa los
diagramas y sus etiquetas.

Artefacto: subsistema de diseño

Los subsistemas de diseño son una forma de organizar los artefactos del modelo
de diseño en piezas más manejables. Un subsistema puede constar de clases de
diseño, realizaciones de caso de uso, interfaces, y otros subsistemas.
Un subsistema puede proporcionar interfaces que representan la funcionalidad que
exportan en término de operaciones.
Los subsistemas pueden representar separación de un sistema grande en
subsistemas que pueden desarrollarse por equipos separados.
Las dos capas de aplicación de nivel más alto suelen tener trazas directas hacia
paquetes y/o clases del análisis.
Los subsistemas pueden representar productos software reutilizados.
Los subsistemas pueden representar sistemas heredados encapsulándolos.

Subsistemas de Servicio: Los subsistemas de servicio diseño se usan en un nivel

inferior de la jerarquía de subsistemas. La identificación de subsistemas de
servicio se basa en los paquetes de servicio del modelo de análisis, y
normalmente existe una traza uno a uno.
Un subsistema de servicio ofrece servicios en término de interfaces y
operaciones.
Un subsistema de servicio suele dar lugar a un componente ejecutable en la
implementación.

Artefacto: interfaz
Las interfaces se utilizan para especificar las operaciones que proporcionan las
clases y los subsistemas del diseño.
Se dice que una clase de diseño o un subsistema de diseño “realizan” o
implementan una interfaz.
Las interfaces constituyen una forma de separar la especificación de la
funcionalidad en términos de operaciones de sus implementaciones en términos de
métodos.

Artefacto: descripción de la arquitectura (vista del modelo de diseño)

Se consideran significativos para la arquitectura los siguientes artefactos del
modelo de diseño:
- La descomposición del modelo de diseño en subsistemas, sus interfaces, y
las dependencias entre ellos.
- Clases de diseño fundamentales como clases activas y clases centrales.
- Realizaciones de caso de uso-diseño que describan alguna funcionalidad
importante y crítica.

Artefacto: modelo de despliegue

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.

Artefacto: descripción de la arquitectura (vista del modelo de despliegue)

La descripción de la arquitectura contiene una vista de la arquitectura del
modelo de despliegue que muestra sus artefactos relevantes para la arquitectura.

Trabajadores
Trabajador: arquitecto
Responsable del modelo de diseño, modelo de despliegue, y descripción de la
arquitectura.

Trabajador: ingeniero de casos de uso

Responsable del realización de caso de uso – diseño.

Trabajador: ingeniero de componentes

Responsable de Clases de diseño, subsistema de diseño, interfaz.

Flujo de Trabajo.

Actividad: diseño de la arquitectura

El objetivo del diseño de la arquitectura es esbozar los modelos de diseño y
despliegue identificando:
- Nodos y configuraciones de red.
- Subsistemas e interfaces
- Clases de diseño significativas para la arquitectura como las clases activas
(procesos).
- Mecanismos de diseño genéricos que tratan requisitos comunes.

Nodos y configuraciones de red

Entre los aspectos de configuraciones de red podemos resaltar:
- ¿Qué nodos se necesitan, que capacidad deben tener?
- ¿Qué tipo de conexiones debe haber entre los nodos, que protocolos de
comunicaciones?
- ¿Qué características deben tener los nodos, ancho de banda,
disponibilidad, calidad, etc?
- ¿procesos redundantes, capacidad de fallos, etc?

Identificación de subsistemas y de sus interfaces

Los subsistemas constituyen un medio para organizar el modelo de diseño en pieza
manejables.
Pueden identificarse inicialmente como forma de dividir el trabajo de diseño, o
bien pueden irse encontrando a medida que el modelo de diseño evoluciona.

Subsistemas de aplicación: Son las capas superiores de la aplicación y pueden

derivarse directamente de los paquetes de análisis. Se distingue capa específica
y general de la aplicación.

Subsistemas intermedios y de software del sistema: Constituyen los cimientos de

un sistema. Son sistemas operativos, SGBD, software de comunicaciones,
tecnologías de distribución de objetos, kits de construcción de GUIs, gestores
de transacciones, etc.

Actividad: diseño de un caso de uso

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

Actividad: diseño de una clase

Para una clase implica definir:
- sus operaciones
- sus atributos
- sus relaciones
- sus métodos (que realizan sus operaciones)
- su ciclo de vida (máquina de estados)
- sus dependencias con cualquier mecanismo de diseño generico
- los requisitos relevantes a su implementación
- la correcta realización de cualquier interfaz requerida

Esbozar la clase del diseño:

• Diseñar clase interfaz: depende de la tecnología específica que se use
(VB,Java, etc)
• Diseñar clases entidad: aspectos de persistencia, a menudo implica uso de
tecnologías BD.
• Diseñar clases de control: encapsulan secuencias, coordinación de otros
objetos, y aveces lógica del negocio. Se deben tener en cuenta: aspectos
de distribución en nodos de red, aspectos de rendimiento, aspectos de
transacción.

Identificar Operaciones:
Identificamos las operaciones y las describimos utilizando el lenguaje de
programación que se usará. Entradas importantes son:
- Responsabilidades de las clases de análisis que tienen traza con la clase de
diseño
- Requisitos especiales de la clase de análisis que tienen traza
- Interfaces que la clase de diseño necesita proporcionar
- Realizaciones de caso de uso diseño en las que la clase participa

Identificar Atributos:
Identificamos atributos requeridos por la clase y los describimos utilizando el
lenguaje de programación que se usará.

Identificar Asociaciones y agregaciones:

Los ingenieros de componentes estudian la transmisión de mensajes en los
diagramas de secuencia para determinar que asociaciones son necesarias.
Aspectos a tener en cuenta:
- Asociaciones y agregaciones en las clases de análisis correspondientes
- Los nombres de roles de asociación pueden llegar a ser atributos de la
clase de diseño que referencia a la otra clase.
- Una asociación de clases puede llegar a ser una nueva clase.
- Se debe considerar la navegabilidad (dirección de los mensajes).

Identificar generalizaciones:
Las generalizaciones deben implementarse utilizando herencia si el lenguaje lo
permite. Si el lenguaje no lo admite debe utilizarse asociación / agregación
para proporcionar la delegación desde los objetos de clases más específicas a
objetos de clases más generales.

Describir los métodos:

Pueden describirse los algoritmos de los métodos utilizando lenguaje natural,
pseudocódigo, o el lenguaje de programación específico. Sin embargo esto suele
diferirse hasta la implementación de la clase.

Describir estados:
Se utilizan diagramas de estado para describir los estados de los objetos estado
dependientes.

Actividad: diseño de un subsistema

Los objetivos del diseño de un subsistema son:
• Garantizar que el subsistema es lo más independiente de los otros
subsistemas.
• Garantizar que el susbsistema proporciona las interfaces correctas.
• Garantizar que el subsistema cumple su propósito de ofrecer una
realización correcta de las operaciones que se definen en las interfaces.

Disciplina de Implementación:
En la implementación empezamos con el resultado del diseño e implementamos el
sistema en término de componentes, es decir, ficheros de código fuente, scripts,
ficheros de código binario, ejecutables, y similares.

Conceptos generales.
La implementación es el centro durante las iteraciones de construcción, aunque
también se lleva a cabo trabajo de implementación durante la fase de
elaboración, para crear la línea base ejecutable de la arquitectura, y durante
la fase de transición para tratar defectos tardíos.

IMPLEMENTACION
Actividad Trabajador Resp. de Artefactos (entrada)
(Salida)
1 Arquitecto Componente (esbozado Modelo de diseño
Implementación de la y Modelo de despliegue
arquitectura posib.asignado a Descrip.de la
nodos) arquitectura
Descripción de la (vista de los mod.de
arquitectura (vista de diseño
los y despliegue)
modelos de impl.y
despl.)
2 Integrador de Plan de integración de Requisitos adicionales
Integrar el sistema sistemas construcciones Modelo de casos de uso
Modelo de Modelo de diseño
implementación Modelo de
(construcciones implementación
anteriores) (construcciones
anteriores)
3 Ingeniero de Subsistema de Descrip.de la arquitec.
Implementar un componentes implementac. (vista
subsistema (implementado para del modelo de
una implementac)
construcción) Subsistema de diseño
Interfaz (implementado (terminado)
para Interfaz (terminado)
una construcción)
4 Ingeniero de Componente Clase de diseño
Implementar una componentes (implentado) (terminada)
clase Interfaz (proporcionada
por
la clase de diseño)
5 Ingeniero de Componente (probado) Componente
Realizar prueba de componentes (implementado)
unidad Interfaz

Artefactos.
Artefacto: Modelo de Implementación
El modelo de diseño es un modelo de objetos que describe la realización física
de los elementos del modelo de diseño.

Artefacto: componente
Un componente es el empaquetamiento físico de los elementos de un modelo, como
son las clases en el modelo de diseño. Algunos estereotipos típicos son:
<<executable>> programa ejecutable en un nodo
<<file>> fichero que contiene código fuente o datos
<<library>> librería estática o dinámica
<<table>> es una tabla de base de datos
<<document>> es un documento

Los componentes tienen relaciones de traza con los elementos que implementan.
Es normal que un componente implemente varios elementos, por ejemplo varias
clases.
Stubs
Un Stub es un componente con una implementación esquelética o de propósito
especial que puede ser utilizado para desarrollar o probar otro componente que
depende del stub.

Artefacto: subsistema de implementación

Los subsistemas de implementación proporcionan una forma de organizar los
artefactos del modelo de implementación en trozos más manejables.
Un subsistema de implementación se manifiesta a través de un mecanismo de
empaquetamiento concreto en un entorno de implementación determinado, como:
- Un paquete en Java
- Un proyecto en VB.
- Un directorio de ficheros en un proyecto de C++
- Un paquete en una herramienta de modelado como Rational Rose.

Los subsistemas de implementación están muy relacionados con los subsistemas de

diseño con los cuales tienen una traza uno a uno (isomórfica).

Artefacto: interfaz
En el modelo de implementación las interfaces pueden ser utilizadas para
especificar las operaciones implementadas por componentes y subsistemas de
implementación.

Artefacto: descripción de la arquitectura

La descripción de la arquitectura tiene la visión de la arquitectura del modelo
de implementación.
Los siguientes artefactos son considerados arquitectónicamente significativos:
- Descomposición del modelo de implementación en subsistemas, sus interfaces, y
dependencias entre ellos.
- Componentes clave que siguen la traza de las clases de diseño significativas
arquitectónicamente.

Artefacto: plan de integración

El sistema se desarrolla incrementalmente a pasos manejables. Cada paso de
construcción debe ser sometido a pruebas de integración.
Para prepararse ante el fallo de una construcción se lleva un control de
versiones para poder volver atrás a una construcción anterior.
Un plan de integración de construcciones describe la secuencia de construcciones
necesarias en una iteración. Un plan de este tipo describe lo siguiente para
cada construcción:
- La funcionalidad que se espera sea implementada en dicha construcción,
consiste en una lista de casos de uso a implementar.
- Las partes del modelo de implementación que están afectadas por la
construcción (lista de subsistemas y componentes necesarios para implementar la
funcionalidad).

Trabajadores
Trabajador: arquitecto
Durante la fase de implementación, el arquitecto es responsable de la integridad
del modelo de implementación y asegura que el modelo como un todo es correcto,
completo, y legible.
El arquitecto es responsable del modelo de implementación, el modelo de
despliegue, y la descripción de la arquitectura.

Trabajador: ingeniero de componentes

Define y mantiene el código fuente de uno o varios componentes, garantizando que
el componente implementa la funcionalidad correcta.
A menudo también mantiene la integridad de uno o varios subsistemas de
implementación.

Trabajador: integrador de sistemas

Es responsable del plan de integración de construcciones.

Flujo de Trabajo.

Actividad: implementación de la arquitectura

El propósito de la implementación de la arquitectura es esbozar el modelo de
implementación y su arquitectura mediante:
- Identificación de componentes significativos arquitectónicamente tales
como componentes ejecutables.
- La asignación de componentes a los nodos en las configuraciones de redes
relevantes.
Para esto consideramos las clases activas encontradas durante el diseño y
asignamos un componente ejecutable a cada clase activa.

Actividad: integrar el sistema

Los objetivos de la integración son:
- Crear un plan de integración de construcciones
- Integrar cada construcción antes de que sea sometida a pruebas de
integración.

Actividad: implementar un subsistema

El propósito de implementar un subsistema es el de asegurar que un subsistema
cumpla su papel en cada construcción.

Actividad: implementar una clase

El propósito de implementar una clase es implementar una clase de diseño en un
componente fichero. Esto incluye:
• Esbozo de un componente fichero que contendrá el código.
• Generación del código fuente a partir de la clase de diseño y de las
relaciones en que participa.
• Implementación de las operaciones de la clase de diseño en forma de
métodos.
• Comprobación de que el componente proporciona las mismas interfaces
que la clase de diseño.

Actividad: realizar prueba de unidad

El propósito de realizar la prueba de unidad es probar los componentes
implementados como unidades individuales. Existen dos tipos de prueba:
- Prueba de especificación, o prueba de “caja negra”, que verifica el
comportamiento de la unidad observable externamente.
- Prueba de estructura o prueba de “caja blanca”, que verifica la implementación
interna de la unidad.

Disciplina de Prueba:
Conceptos generales.
Los objetivos de la prueba son:
- Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas
de integración y las pruebas de sistema.
- Diseñar e implementar pruebas creando los casos de prueba (especifican
qué probar), procedimientos de prueba (especifican cómo realizar las
pruebas), creando componentes de prueba para automatizar las pruebas.
- Realizar las pruebas.

PRUEBA
Actividad Trabajador Resp. de Artefactos (entrada)
(Salida)
1 Ingeniero de Plan de Prueba Requisitos adicionales
Planificar prueba pruebas Modelo de casos de uso
Modelo de análisis
Modelo de diseño
Modelo de
implementación
Descripción de arqu.
(vistas
arquitec.de los
modelos)
2 Ingeniero de Caso de prueba Requisitos adicionales
Diseñar prueba pruebas Procedimiento de Modelo de casos de uso
 prueba Modelo de análisis
Modelo de diseño
Modelo de
implementación
Descripción de arqu.
(vistas
arquitec.de los
modelos)
Plan de prueba
(estrategia
de prueba y planific.)
3 Ingeniero de Componente de prueba Caso de prueba
Implementar prueba componentes Procedimiento de
prueba
Modelo de implement.
(construida para ser
probada)
4 Ingeniero de Defecto Caso de prueba
Realizar pruebas de pruebas de Procedimiento de
integración integración prueba
Componente de prueba
Modelo de
implementación
(construcción a probar)
5 Ingeniero de Defecto Caso de prueba
Realizar prueba de pruebas de Procedimiento de
sistema sistema prueba
Componente de prueba
Modelo de
implementación
(construcción a probar)
6 Ingeniero de Evaluación de prueba Plan de prueba
Evaluar prueba pruebas (para Modelo de prueba
una iteración) Defecto

Artefactos
Artefacto: Modelo de pruebas
Describe como se prueban los componentes en el modelo de implementación. El
modelo de pruebas es una colección de casos de prueba, procedimientos de prueba,
y componentes de prueba.

Artefacto: Caso de prueba

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.

Artefacto: Procedimiento de prueba

Un procedimiento de prueba especifica cómo realizar uno o varios casos de prueba
o partes de estos.
Artefacto: Componente de prueba
Un componente de prueba automatiza uno o varios procedimientos de prueba o
partes de ellos.

Artefacto: Plan de prueba

El plan de prueba describe las estrategias, recursos y planificación de la
prueba. La estrategia incluye definición de tipo de pruebas a realizar por
iteración, sus objetivos, nivel de cobertura y código necesario.

Artefacto: Defecto
Un defecto es una anomalía del sistema. Un defecto puede ser utilizado para
localizar cualquier cosa que los desarrolladores necesitan registrar como
síntoma de un problema.

Artefacto: Evaluación de prueba

Una evaluación de prueba es una evaluación de los resultados de la prueba.

Trabajadores.
Trabajador: diseñador de pruebas
Un diseñador de pruebas es responsable de la integridad del modelo de pruebas,
asegurando que el modelo cumple con su propósito.
Planean las pruebas.
Seleccionan y describen los casos de prueba y procedimientos de prueba.

Trabajador: ingeniero de componentes

Son responsables de los componentes de prueba que automatizan algunos de los
procedimientos de prueba.

Trabajador: ingeniero de pruebas de integración

Son los responsables de realizar las pruebas de integración que se necesitan
para cada construcción producida en el flujo de implementación.
Documentan los defectos que aparecen como resultados de las pruebas de
integración.

Trabajador: ingeniero de pruebas de sistema

Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de
sistema necesarias sobre una construcción que muestra el resultado de una
iteración completa.
Las pruebas de sistema se llevan a cabo para verificar interacciones entre los
actores y el sistema.

Flujo de Trabajo.
Actividad: planificar prueba
- Describir una estrategia de la prueba
- Estimar requisitos para la prueba, recursos humanos y sistemas necesarios
- Planificar esfuerzo de la prueba

Actividad: diseñar la prueba

- Identificar y describir los casos de prueba para cada construcción
- Identificar y estructurar los procedimientos de prueba especificando como
realizar los casos de prueba.

Actividad: implementar la prueba

- Automatizar los procedimientos de prueba creando componentes de prueba si
esto es posible.

Actividad: realizar pruebas de integración

- Realizar las pruebas de integración relevantes ejecutando los procedimientos o
componentes de prueba correspondientes.
- Comparar los resultados de las pruebas con los resultados esperados e
investigar resultados no esperados.
- Informar defectos a los ingenieros de componentes responsables de los
componentes que registran fallas.
- Informar los defectos a los diseñadores de pruebas, quienes usarán los
defectos para evaluar los resultados de las pruebas.

Actividad: realizar prueba del sistema

Una vez finalizadas las pruebas de integración se realizan las pruebas de
sistema de forma similar.
Actividad: evaluar la prueba
Se comparan resultados de la prueba con resultados esperados. Para esto se
utilizan métricas:
- Compleción de la prueba: indica el porcentaje de casos de prueba que han
sido ejecutados y el porcentaje de código que ha sido probado.
- Fiabilidad: Se basa en el análisis de las tendencias den los defectos
detectados y en las tendencias en las pruebas que se ejecutan con el
resultado esperado.

Unidad 2.4: Metodologías Agiles

Introducción a las Metodologías Ágiles. Procesos Predecibles vs. Adaptables. La
Importancia
del Factor Humano en los Métodos Ágiles.
El Modelado Ágil de Aplicaciones. Objetivos. Alcances. Valores. Principios.
Prácticas.
Integración entre las prácticas de AM.
Ciclo de Vida para el Desarrollo Ágil de Software Integración de AM con XP y con
RUP.
Una introducción a XP. ¿Qué es la programación Extrema? Valores, Principios y
Centrales de XP. El Proyecto XP. Límites de XP.
Una introducción a Scrum. Conceptos generales.