WORKFLOW DE ANLISIS

Introduccin
Durante el anlisis, se analizan los requerimientos capturados en la captura de requerimientos (workflow de
requerimientos), refinndolos y estructurndolos. Esto se hace con el objetivo de conseguir una comprensin de los
requerimientos de una forma ms precisa y una descripcin de los mismos que sea fcil de mantener y que nos
ayude a estructurar el sistema entero.
En el workflow de requerimientos, es probable que an queden aspectos sin resolver relativos a los requerimientos
del sistema. Este es el precio que hay que pagar por el uso del lenguaje intuitivo pero impreciso del cliente durante
la captura de requerimientos. El propsito fundamental del anlisis es resolverlos analizando los requerimientos con
mayor profundidad, pero con la gran diferencia de que puede utilizarse el lenguaje del desarrollador para describir
los resultados.
MODELO DE CASOS DE USO
Descrito en lenguaje del cliente.
Vista externa del sistema.
Estructurado por casos de uso

Utilizado como contrato entre el cliente y los

desarrolladores sobre que debera y que no
debera hacer el sistema.

Puede contener redundancias, inconsistencias,

etc. entre requerimientos.
Captura la funcionalidad del sistema, incluida la
funcionalidad significativa para la arquitectura.

Define casos de uso que se analizarn con ms

profundidad en el modelo de anlisis.

MODELO DE ANLISIS
Descrito en lenguaje del desarrollador.
Vista interna del sistema.
Estructurado por clases y paquetes
estereotipados.
Utilizado por los desarrolladores para
comprender como debera darse forma al
sistema, es decir, como debera ser diseado e
implementado.
No
debera
contener
redundancias,
inconsistencias, etc. entre requerimientos.
Esboza como llevar a cabo la funcionalidad
dentro del sistema, incluida la funcionalidad
significativa para la arquitectura; sirve como
una primera aproximacin al diseo.
Define realizaciones de casos de uso, y cada una
de ellas representa el anlisis de un caso de uso
de uso del modelo de casos de uso.

El anlisis
El lenguaje que utilizamos en el anlisis se basa en un modelo de objetos conceptual, que llamamos modelo de
anlisis. Este modelo, nos ayuda a refinar los requerimientos y nos permite razonar sobre los aspectos internos del
sistema.
El modelo de anlisis, tambin nos ayuda a estructurar los requerimientos y nos proporciona una estructura centrada
en el mantenimiento, en aspectos tales como la flexibilidad ante los cambios y la reutilizacin. Esta estructura
tambin sirve como entrada en las actividades de diseo e implementacin, ya que se trata de preservar dicha
estructura mientras le damos forma al sistema. Por esto, el modelo de anlisis puede considerarse una primera
aproximacin al modelo de diseo, aunque es un modelo por s mismo.
El modelo de anlisis hace abstracciones y evita resolver algunos problemas y tratar algunos requerimientos que
pensamos que es mejor en posponer al diseo y a la implementacin. Por ello, no siempre se puede conservar la
estructura proporcionada por el anlisis, ya que el diseo debe considerar la plataforma de implementacin:
lenguaje de programacin, sistemas operativos, frameworks, sistemas heredados, etc.

-1-

El anlisis no es diseo ni implementacin

El diseo y la implementacin son mucho ms que el anlisis, por lo que se requiere una separacin de intereses. El
diseo y la implementacin se preocupan en dar forma al sistema de manera que d vida a los requerimientos
(funcionales y no funcionales) que incorpora.
Antes de comenzar a disear e implementar deberamos contar con una compresin precisa y detallada de los
requerimientos. Si contamos con una estructura de requerimientos que puede utilizarse como entrada para dar
forma al sistema, mejor. Esto se consigue mediante el anlisis.

Cundo hacer anlisis

Mediante la realizacin separada del anlisis, en lugar de llevarlo a cabo como parte integrada en el diseo
y la implementacin, podemos analizar sin grandes costes una gran parte del sistema. Se puede utilizar el
resultado para planificar el trabajo de diseo e implementacin subsiguiente en varios incrementos
sucesivos, donde cada incremento sola disea e implementa una pequea parte del sistema, o quiz en
varios incrementos concurrentes.
El anlisis proporciona una visin ms general del sistema que puede ser ms difcil de obtener mediante el
estudio de los resultados del diseo y la implementacin, debido a que contienen demasiados detalles. Una
visin general como esa puede ser muy valiosa para recin llegados al sistema o para desarrolladores que
en general mantienen el sistema.
Algunas partes del sistema tienen diseos y/o implementaciones alternativas. El modelo de anlisis puede
proporcionar una vista conceptual, precisa y unificadora de esas implementaciones alternativas.
El sistema se construye utilizando un sistema heredado complejo. La reingeniera de este sistema heredado,
o de una parte l, puede hacerse en trminos del modelo de anlisis de manera que los desarrolladores
puedan comprender el sistema heredado sin tener que profundizar en los detalles de su diseo e
implementacin, y construir el nuevo sistema utilizando el heredado como un bloque de construccin
reutilizable.

El papel del anlisis en el ciclo de vida del software

Las iteraciones iniciales de la elaboracin se centran en el anlisis.

Cmo utilizar el anlisis

La manera exacta de ver y emplear el anlisis puede diferir de un proyecto a otro. Tres formas:
1. El proyecto utiliza el modelo de anlisis para describir los resultados de anlisis, y mantiene la consistencia
de este modelo a lo largo de todo el ciclo de vida del software.

-2-

2. El proyecto utiliza el modelo de anlisis para describir los resultados del anlisis pero considera a este
modelo como una herramienta intermedia o transitoria. Cuando el diseo e implantacin estn en marcha
durante la fase de construccin, se deja de actualizar el anlisis.
3. El proyecto no utiliza en absoluto el modelo de anlisis para describir los resultados del anlisis. En cambio,
el proyecto analiza los requerimientos como parte integrada en la captura de requerimientos o en el diseo.
Al elegir entre las dos primeras variantes, hay que sopesar las ventajas de mantener el modelo de anlisis con el
coste de mantenerlo durante varias iteraciones y generaciones. Hay que realizar un anlisis costo/beneficio correcto
y decidir si se debiera dejar de actualizar el modelo de anlisis o conservarlo y mantenerlo durante el resto de la vida
del sistema.
La tercera variante se emplea en casos excepcionales para sistemas extraordinariamente simples.
La segunda opcin suele ser la ms usada, ya que el anlisis se centra en la fase de elaboracin.

Artefactos de anlisis
1.
2.
3.
4.
5.

Modelo de anlisis
Clase del anlisis
Realizacin de caso de uso-anlisis
Paquete del anlisis
Descripcin de la arquitectura (vista del modelo de anlisis)

Modelo de anlisis
(ver atrs)

Clase de anlisis
Representa una abstraccin de una o varias clases y/o subsistemas del diseo del sistema.

Una clase de anlisis se centra en el tratamiento de los requerimientos funcionales y pospone los no
funcionales.
Son evidentes en el contexto del dominio del problema, ms conceptual.
Su comportamiento se define mediante responsabilidades en un alto nivel y menos formal. No se define
mediante una interfaz en trminos de operaciones y de sus firmas.
Una clase de anlisis define atributos en un alto nivel. Los tipos de los atributos son conceptuales y
reconocibles en el dominio del problema. En el diseo los tipos pertenecen al lenguaje de programacin.
Una clase de anlisis participa en relaciones, aunque esas relaciones son ms conceptuales que las de diseo
e implementacin.
Las clases de anlisis siempre encajan en uno de los tres estereotipos bsicos: de interfaz, de control o de
entidad.

Estos tres estereotipos estn estandarizados en UML y se utilizan para ayudar a los desarrolladores a distinguir el
mbito de las diferentes clases. Son:

Clases de interfaz (boundary): se utilizan para modelar la interaccin entre el sistema y sus actores. Esta
interaccin implica a menudo recibir (y presentar) informacin y peticiones de (y hacia) los usuarios y los
sistemas externos.
Representan a menudo abstracciones de ventanas, formularios, paneles, interfaces de comunicaciones,
interfaces de impresoras, sensores, etc. Deberan asociarse con un al menos un actor y viceversa.
Clases de entidad: se utilizan para modelar informacin que posee una vida larga y que es a menudo
persistente. Modelan la informacin y el comportamiento asociado a algn fenmeno o concepto, como
una persona, un objeto del mundo real, o un suceso del mundo real.
-3-

En la mayora de los casos, las clases de entidad se derivan directamente de una clase de entidad del negocio
(o de una clase del dominio). Una diferencia fundamental entre clases de entidad y clases de entidad de
negocio es que las primeras consideran objetos manejados por el sistema. En consecuencia, las clases de
entidad reflejan la informacin de un modo que beneficia a los desarrolladores al disear e implementar el
sistema, incluyendo su soporte de persistencia.
Modelan informacin relevante para el dominio y que dura en el tiempo, siendo candidatas a ser persistentes
mediante bases de datos.
Clases de control: representan coordinacin, secuencia, transacciones, y control de otros objetos y se usan
con frecuencia para encapsular el control de un caso de uso en concreto. Tambin se utilizan para
representar derivaciones y clculos complejos, como la lgica de negocio que no puede asociarse con
ninguna clase de entidad concreta.
Los aspectos dinmicos del sistema se modelan con clases de control, debido a que ellas manejan y
coordinan las acciones y los flujos de control principales, y delegan trabajo a otros objetos.
Son el nexo entre las clases de entidad y de interfaz, ya que stas no se relacionan directamente.

Realizacin de caso de uso-anlisis

Una realizacin de caso de uso-anlisis es una colaboracin dentro del modelo de anlisis que describe cmo se lleva
a cabo y se ejecuta un caso de uso determinado en trmino de las clases del anlisis y de sus objetos del anlisis en
interaccin.
Poseen una descripcin textual del flujo de sucesos, diagramas de clases que muestran sus clases de anlisis
participantes, y diagramas de interaccin que muestran la realizacin de un flujo o escenario particular del caso de
uso en trminos de interacciones de objetos del anlisis. Se centra de manera natural en los requerimientos
funcionales, por ende, puede posponer el tratamiento de los requerimientos no funcionales hasta el diseo y la
implementacin.

Paquetes del anlisis

Los paquetes del anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas
manejables. Puede estar compuesto de clases de anlisis, de realizaciones de casos de uso de anlisis y de otros
paquetes (recursivamente).
Los paquetes de anlisis deberan ser cohesivos (contenidos fuertemente relacionados) y deberan ser dbilmente
acoplados (mnima dependencia de uno de otros).
Tienen las siguientes caractersticas:

Los paquetes de anlisis pueden representar una separacin de intereses de anlisis.

Los paquetes de anlisis deberan crearse basndose en los requerimientos funcionales y en el dominio del
problema.
Los paquetes del anlisis probablemente se convertirn en subsistemas en las dos capas de aplicacin
superiores del modelo de diseo, o se distribuirn entre ellos.

Descripcin de la arquitectura (vista del modelo de anlisis)

La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de anlisis, que muestra sus
artefactos significativos para la arquitectura.
-4-

Artefactos que se consideran significativos para la arquitectura:

La descomposicin del modelo de anlisis en paquetes de anlisis y sus dependencias.

Las clases fundamentales del anlisis (entidad, control e interfaz).
Realizaciones de caso de uso que describen cierta funcionalidad importante y crtica.

Trabajadores del anlisis

1. Arquitecto.
2. Ingeniero de casos de uso.
3. Ingeniero de componentes.

Arquitecto
El arquitecto es el responsable de la integridad del modelo de anlisis, garantizando que ste sea correcto,
consistente y legible como un todo.
El modelo de anlisis es correcto cuando realiza la funcionalidad descrita en el modelo de casos de uso, y slo esa
funcionalidad.
El arquitecto tambin es responsable de la arquitectura, es decir, de la existencia de sus partes significativas para la
arquitectura tal y como se muestran en la vista de la arquitectura del modelo.
El arquitecto no es responsable del desarrollo y mantenimiento continuo de los diferentes artefactos del modelo de
anlisis.

Ingeniero de casos de uso

Un ingeniero de casos de uso es responsable de la integridad de una o ms realizaciones de caso de uso, garantizando
que cumplen los requerimientos que recaen sobre ellos.
No es responsable de las clases de anlisis ni de las relaciones que se usan en la realizacin del caso de uso.

Ingeniero de componentes
El ingeniero de componentes define y mantiene las responsabilidades, atributos, relaciones y requerimientos
especiales de una o varias clases del anlisis, asegurndose de que cada clase del anlisis cumple con los
requerimientos que se esperan de ella de acuerdo a las realizaciones de caso de uso en las que participa.
Tambin se encarga de mantener la integridad de uno o varios paquetes del anlisis.

-5-

Flujo de trabajo (actividades)

1. Los arquitectos comienzan con la creacin del modelo de anlisis, identificando los paquetes de anlisis
principales, las clases de entidad evidentes y los requerimientos comunes.
2. Los ingenieros de caso de uso realizan cada caso de uso en trmino de las clases de anlisis participantes
exponiendo los requerimientos de comportamiento de cada clase.
3. Los ingenieros de componentes especifican estos requerimientos de comportamiento y los integran dentro
de cada clase creando responsabilidades, atributos y relaciones consistentes para cada clase.
4. Durante el anlisis, los arquitectos identifican de manera continua nuevos paquetes de anlisis, clases y
requerimientos comunes a medida que el modelo evoluciona, y los ingenieros de componentes refinan y
mantienen continuamente los paquetes del anlisis.

Anlisis de la arquitectura (por arquitecto)

El propsito del anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la
identificacin de paquetes de anlisis, clases de anlisis evidentes y requerimientos especiales comunes.
Identificacin de paquetes del anlisis
Pueden identificarse inicialmente como una forma de dividir el trabajo de anlisis, o bien encontrarse a medida
que el modelo de anlisis evoluciona.
Una identificacin inicial de los paquetes de anlisis se basa en los requerimientos funcionales y en el dominio
del problema. Para ello, se asigna un nmero de casos de uso a un paquete y luego se realiza la funcionalidad
correspondiente a ese paquete.
Estas asignaciones de casos de uso a paquetes pueden hacerse:

Los casos de uso requeridos para dar soporte a un determinado proceso de negocio.
Los casos de uso requeridos para dar soporte a un determinado actor del sistema.
Los casos de uso que estn relacionados mediante relaciones de generalizacin y de extensin.

Identificacin de clases de entidad evidentes

Consiste en una propuesta preliminar de las clases de entidad ms importantes basado en las clases del dominio
o las entidades de negocio que se identificaron durante la captura de requerimientos.
Identificacin de requerimientos especiales comunes
Un requerimiento especial es un requerimiento que aparece durante el anlisis y que es importante anotar de
forma que pueda ser tratado adecuadamente en las actividades de diseo e implementacin (req. no
funcionales).

-6-

Analizar un caso de uso (por ing. de casos de uso)

Analizamos un caso de uso para:

Identificar clases de anlisis cuyos objetos son necesarios para llevar a cabo el caso de uso.
Distribuir el comportamiento del caso de uso entre los objetos del anlisis que interactan.
Capturar requerimientos especiales sobre la realizacin del caso de uso.

Identificacin de clases de anlisis

Se identifican las clases de entidad, control e interfaz necesarias para realizar los casos de uso, y se esbozan sus
nombres, responsabilidades, atributos y relaciones.
Descripcin de interacciones entre objetos del anlisis
Cuando tenemos un esbozo de las clases necesarias para realizar un caso de uso, debemos describir cmo
interactan sus correspondientes objetos del anlisis. Esto se hace mediante diagramas de colaboracin que
contienen las instancias de actores participantes, los objetos del anlisis, y sus enlaces.
Captura de requerimientos especiales
Se capturan los requerimientos no funcionales que aparecen, pero se los posterga para el diseo e
implementacin.

-7-

Analizar una clase (por ing. de componentes)

Los objetivos de analizar una clase son:

Identificar y mantener las responsabilidades de una clase de anlisis, basadas en su papel en las realizaciones
de caso de uso.
Identificar y mantener los atributos y relaciones de la clase de anlisis.
Capturar requerimientos especiales sobre la realizacin de la clase de anlisis.

Identificar responsabilidades
Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en diferentes
realizaciones de caso de uso.
Identificar atributos
Un atributo especifica una propiedad de una clase de anlisis, y normalmente es necesario para las
responsabilidades de su clase.
Identificar asociaciones y agregaciones
El ingeniero de componentes debera estudiar los enlaces empleados en los diagramas de colaboracin para
determinar que asociaciones son necesarias.
Identificar generalizaciones
Las generalizaciones deberan utilizarse en el anlisis para extraer comportamiento compartido y comn entre
varias clases de anlisis diferentes.
Captura de requerimientos especiales
Se capturan los requerimientos no funcionales que aparecen, pero se los posterga para el diseo e
implementacin.

Analizar un paquete (por ing. de componentes)

Los objetivos de analizar un paquete son:

Garantizar que el paquete de anlisis es tan

independiente de otros paquetes como sea posible.
Garantizar que el paquete de anlisis cumple su
objetivo de realizar algunas clases de dominio o
casos de uso.
Describir las dependencias de forma que pueda
estimarse el efecto de los cambios futuros.

-8-

UML
El Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es un lenguaje estndar para describir planos
de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema
que involucre una gran cantidad de software.
UML es slo un lenguaje, y por tanto, es tan slo una parte de un mtodo de desarrollo de software. UML es
independiente del proceso, aunque para utilizarlo ptimamente se debera usar en un proceso que fuese dirigido
por casos de uso, centrado en la arquitectura, iterativo e incremental.

UML es un lenguaje
Un lenguaje proporciona un vocabulario y las reglas para combinar palabras de ese vocabulario con el objetivo de
posibilitar la comunicacin. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representacin conceptual y fsica de un sistema. Un lenguaje de modelado como UML es, por tanto, un lenguaje
estndar para los planos de software.
El modelado nos ayuda a la compresin del sistema. Nunca es suficiente un nico modelo. Para comprender
cualquier cosa, a menudo se necesitan mltiples modelos conectados entre s.
El vocabulario y reglas de UML indican como crear y leer modelos bien formados, pero no dicen que modelos crear
ni cundo se deberan crear. sta es la tarea del proceso de desarrollo de software (Proceso Unificado de Desarrollo,
PUD).

UML es un lenguaje para visualizar

UML es algo ms que un montn de smbolos grficos. Detrs de cada smbolo en la notacin de UML hay un
significado bien definido. De esta manera, un desarrollador puede escribir un modelo UML, otro desarrollador, o
incluso otra herramienta, puede interpretar ese modelo sin ambigedad.

UML es un lenguaje para especificar

Especificar se refiere a construir modelos precisos, no ambiguos y completos.

UML es un lenguaje para construir

UML no es un lenguaje de programacin visual, pero sus modelos pueden conectarse de forma directa a una gran
variedad de lenguajes de programacin. Esto significa que es posible establecer correspondencias desde un modelo
UML a un lenguaje de programacin como Java, C++ o Visual Basic, o incluso a tablas e una base de datos relacional.
Esta correspondencia permite ingeniera directa e inversa:

Ingeniera directa: la generacin de cdigo a partir de un modelo UML en un lenguaje de programacin.

Ingeniera inversa: reconstruir un modelo UML a partir de cdigo.

UML es un lenguaje para documentar

UML cubre la documentacin de la arquitectura de un sistema y todos sus detalles.

Proporciona un lenguaje para expresar requerimientos y pruebas.
Proporciona un lenguaje para modelar las actividades de planificacin de proyectos y gestin de versiones.

-9-

Bloques bsicos de construccin

1. ELEMENTOS
1.1. Estructurales
1.2. De comportamiento
1.3. De agrupacin
1.4. De anotacin
2. RELACIONES
2.1. Dependencia
2.2. Asociacin
2.2.1.Agregacin
2.3. Generalizacin
2.4. Realizacin
3. DIAGRAMAS

Elementos
Elementos estructurales: son las partes estticas de un modelo, y representan conceptos o cosas materiales.
Ejemplo:
1. Clase: descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones
y semntica.
2. Interfaz: coleccin de operaciones que especifican un servicio de una clase o componente. Define un
conjunto de operaciones, pero nunca la implementacin de tales.
3. Colaboracin: define una interaccin y es una sociedad de roles y otros elementos que colaboran para
proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.
4. Caso de uso: descripcin de un conjunto de secuencias de acciones que ejecuta un sistema y que produce
un resultado observable de inters para un actor particular.
5. Clase activa: es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin. Clase con
comportamiento concurrente.
6. Componente: es una parte modular del diseo del sistema que oculta su implementacin tras un conjunto
de interfaces externas.
7. Artefacto: es una parte fsica y reemplazable de un sistema que contiene informacin fsica (bits, ej. cdigo
fuente).
8. Nodo: elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, que por
lo general tiene algo de memoria y capacidad de procesamiento.
Elementos de comportamiento: son las partes dinmicas de los modelos de UML. Ejemplo:
1. Interaccin: es un comportamiento que comprende un conjunto de mensajes intercambiados entre un
conjunto de objetos, dentro de un contexto particular, para alcanzar un objetivo especfico.
2. Mquina de estados: es un comportamiento que especifica las secuencias de estados por las que pasa un
objeto o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.
3. Actividad: es un comportamiento que especifica la secuencia de pasos que ejecuta un proceso
computacional.
Elementos de agrupacin: son las partes organizativas de los modelos UML. Ejemplo:
1. Paquete: es un mecanismo de propsito general para organizar el propio diseo. Es el elemento de
agrupacin bsico para organizar un modelo UML.
Elementos de anotacin: son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar
para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo. Ejemplo:
- 10 -

1. Nota: es un smbolo para mostrar restricciones y comentarios junto a un elemento o una coleccin de
elementos.

Relaciones
Relacin de dependencia: es una relacin semntica entre dos elementos, en la cual un cambio a un elemento (el
elemento independiente) puede afectar a la semntica del otro elemento (elemento dependiente).
Relacin de asociacin: es una relacin estructural entre clases que describe un conjunto de enlaces, los cuales son
conexiones entre objetos que son instancias de clases.
1. Agregacin: es un tipo especial de asociacin, que representa una relacin estructural entre un todo y sus
partes.
Relacin de generalizacin: es una relacin de especializacin/generalizacin en la cual el elemento especializado
(hijo) se basa en la especificacin del elemento generalizado (padre). El hijo comparte la estructura y
comportamiento del padre.
Relacin de realizacin: es una relacin semntica entre clasificadores, en donde un clasificador especifica un
contrato que otro clasificador garantiza que cumplir.

Diagramas
Diagrama: es la representacin grfica de un conjunto de elementos, visualizado la mayora de las veces como un
grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde
diferentes perspectivas, de forma que un diagrama es una proyeccin de un sistema. Un diagrama puede contener
cualquier combinacin de elementos y relaciones. Sin embargo, en la prctica siempre surgen un nmero de
combinaciones habituales, las cuales son consistentes con las cinco vistas ms tiles que comprenden la arquitectura
de un sistema. UML incluye algunos tipos de diagramas:
1. Diagrama de clases: muestra un conjunto de clases, interfaces y colaboracin, as como sus relaciones.
Abarcan la vista de diseo esttica de un sistema.
2. Diagrama de objetos: muestra un conjunto de objetos y sus relaciones. Representan instantneas estticas
de instancias de los elementos de los diagramas de clases (clases). Cubren la vista de diseo esttica.
3. Diagrama de componentes: representa la encapsulacin de una clase, junto con sus interfaces, puertos y
estructura interna, la cual est formada por otros componentes anidados y conectores. Cubren la vista de
implementacin esttica del diseo de un sistema.
4. Diagrama de casos de uso: muestra un conjunto de casos de uso y actores y sus relaciones. Organizan y
modelan el comportamiento del sistema. Cubren la vista de casos de uso esttica de un sistema.
5. Diagrama de interaccin: muestra una interaccin, que consta de un conjunto de objetos o roles, incluyendo
los mensajes que pueden ser enviados entre ellos. Cubren la vista dinmica de un sistema.
a. Diagrama de secuencia: es un diagrama de interaccin que resalta la ordenacin temporal de los
mensajes.
b. Diagrama de comunicacin: es un diagrama de interaccin que resalta la organizacin estructural
de los objetos o roles que envan y reciben mensajes.
6. Diagrama de estados: muestra una mquina de estados, que consta de estados, transiciones, eventos y
actividades. Muestra la vista dinmica de un objeto.
7. Diagrama de actividades: muestra la estructura de un proceso u otra computacin como el flujo de control
y datos paso a paso. Cubren la vista dinmica del sistema.
8. Diagrama de despliegue: muestra la configuracin de nodos de procesamiento en tiempo de ejecucin y los
artefactos que residen en ellos. Abordan la vista de despliegue esttica de una arquitectura.
9. Diagrama de artefactos: muestra los constituyentes fsicos de un sistema en el computador (archivos, bases
de datos, etc.).
- 11 -

10. Diagrama de paquetes: muestra la descomposicin del propio modelo en unidades organizativas y sus
dependencias.
11. Diagrama de tiempos: es un diagrama de interaccin que muestra los tiempos reales entre diferentes
objetos o roles, en oposicin a la simple secuencia relativa de mensajes.

Reglas de UML
Los bloques de construccin de UML no pueden combinarse de cualquier manera. UML tiene un nmero de reglas
que especifican a qu debe parecerse un modelo bien formado. Un modelo bien formado es aquel que es
semnticamente autoconsistente y est en armona con todos sus modelos relacionados.
UML tiene reglas sintcticas y semnticas para:

Nombres: como llamar a los elementos, relaciones y diagramas.

Alcance: el contexto que da un significado especfico a un nombre.
Visibilidad: cmo se pueden ver y utilizar esos nombres por otros.
Integridad: cmo se relacionan apropiada y consistentemente unos elementos con otros.
Ejecucin: que significa ejecutar o simular un modelo dinmico.

Es habitual que el equipo de desarrollo no slo construya modelos bien formados, sino tambin modelos que sean:

Abreviados: ciertos elementos se ocultan para simplificar la vista.

Incompletos: pueden estar ausentes ciertos elementos.
Inconsistentes: no se garantiza la integridad del modelo.

Mecanismos comunes de UML

1.
2.
3.
4.

Especificaciones.
Adornos.
Divisiones comunes.
Mecanismos de extensibilidad.

Especificaciones
UML es algo ms que un lenguaje grfico. Detrs de cada elemento de su notacin grfica hay una especificacin
que proporciona una explicacin textual de la sintaxis y semntica de ese bloque de construccin.

Adornos
La mayora de elementos UML tienen una notacin grfica nica y clara que proporciona una representacin visual
de los aspectos ms importantes del elemento.
Todos los elementos en la notacin UML parten de un smbolo bsico, al cual pueden aadirse una variedad de
adornos especficos de ese smbolo.
Por ejemplo, a los atributos y mtodos de las clases suelen ir acompaados de un smbolo que indica su visibilidad,
como + (public), - (private) y # (protected).

Divisiones comunes
Al moldear sistemas orientados a objetos, el mundo a menudo se divide de varias formas.

Divisin entre clase y objeto: una clase es una abstraccin; un objeto es una manifestacin concreta de esa
abstraccin.
Divisin entre interfaz e implementacin: una interfaz declara un contrato, y una implementacin
representa una realizacin de ese contrato.
- 12 -

Divisin entre tipo y rol: el tipo declara la clase de una entidad, como un objeto, un atributo o un parmetro.
Un rol describe el significado de una entidad en un contexto, como una clase, un componente o una
colaboracin.

Mecanismos de extensibilidad
1. Estereotipos.
2. Valores etiquetados.
3. Restricciones.

Estereotipo: extiende el vocabulario de UML, permitiendo crear nuevos bloques de construccin que
derivan de los existentes pero que son especficos a un problema.
Valor etiquetado: extiende las propiedades de un estereotipo de UML, permitiendo aadir nueva
informacin en la especificacin de ese estereotipo.
Restriccin: extiende la semntica de un bloque de construccin de UML, permitiendo aadir nuevas reglas
o modificar las existentes.

En conjunto, estos tres mecanismos de extensibilidad permiten configurar y extender UML para las necesidades de
un proyecto. Permiten a UML adaptarse a nuevas tecnologas de software.

Arquitectura
Arquitectura: conjunto de decisiones significativas que tomamos sobre el producto para cumplir con los
requerimientos. Explica cmo se satisfacen los requerimientos funcionales y no funcionales.
Diferentes usuarios siguen diferentes agendas en relacin con el proyecto, y cada uno mira al sistema de formas
diferentes en diversos momentos a lo largo de la vida del proyecto. La arquitectura de un sistema es el artefacto
ms importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo
iterativo e incremental de un sistema.
La arquitectura no tiene que ver solamente con la estructura y el comportamiento, sino tambin con el uso, la
funcionalidad, el rendimiento, la capacidad de adaptacin, las restricciones econmicas y tecnolgicas, etc.

Vistas
La arquitectura de un sistema puede describirse mejor a travs de cinco vistas interrelacionadas. Cada vista es una
proyeccin de la organizacin y la estructura del sistema, centrada en un aspecto particular del mismo.

Vista de casos de uso: comprende los casos de uso que describen el comportamiento del sistema tal y como
es percibido por los usuarios finales, analistas y encargados de las pruebas. Con UML, los aspectos estticos
de sta vista se capturan en los diagramas de casos de uso; los aspectos dinmicos de esta vista se capturan
en los diagramas de interaccin, diagramas de estados y diagramas de actividades. Comportamiento.
Vista de diseo: comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema
y su solucin. Soporta principalmente los requerimientos funcionales del sistema. Con UML, los aspectos
estticos se capturan con diagramas de clases y de objetos; los dinmicos dem a la vista de casos de uso.
Vocabulario.
Vista de interaccin (o de procesos): muestra el flujo de control entre las diversas partes del sistema,
incluyendo mecanismos de concurrencia y sincronizacin. Con UML, los aspectos estticos y dinmicos se
capturan con los mismos diagramas que en la vista de diseo, pero haciendo nfasis en clases activas que
controlan el sistema y los mensajes que fluyen entre ellas. Flujo de control.
Vista de implementacin: comprende los artefactos que se utilizan ensamblar y poner en ejecucin el
sistema fsico. Con UML, los aspectos estticos de esta vista se capturan con el diagrama de artefactos; los
dinmicos dem vista de casos de uso. Ensamblado.
- 13 -

Vista de despliegue: contiene los nodos que forman la topologa de hardware sobre la que se ejecuta el
sistema. Con UML, los aspectos estticos se capturan con el diagrama de despliegue; los dinmicos dem a
la vista de casos de uso. Topologa de hardware.

Cada una de estas vistas puede existir por s misma, de forma que diferentes usuarios puedan centrarse en las
cuestiones de la arquitectura del sistema que ms les interesen. Adems, estas cinco vistas interactan entre s.

Ciclo de vida del desarrollo de software

Proceso de desarrollo: conjunto de actividades que transforma los requerimientos de un cliente en un sistema de
software. Es un entorno genrico que se puede especificar segn el producto, el ciclo de vida, etc.
Entorno de proceso genrico: que sirve para cualquier software en cualquier situacin.
UML es independiente del proceso, lo que significa que no est ligado a ningn ciclo de vida de desarrollo de software
particular. Sin embargo, para obtener el mximo beneficio de UML, se debera considerar un proceso que fuese:
dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.

Dirigido por casos de uso: significa que los casos de uso se utilizan como un artefacto bsico para establecer
el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas
y para la comunicacin entre las personas involucradas en el proyecto. Se dice que los casos de uso guan el
proceso de desarrollo.
Centrado en la arquitectura: significa que la arquitectura del sistema se utiliza como un artefacto bsico
para conceptualizar, construir, gestionar y hacer evolucionar el sistema en desarrollo.
Iterativo e incremental
o Proceso iterativo: es aquel que involucra la gestin de un flujo de versiones ejecutables.
o Proceso incremental: mediante la arquitectura se integran las versiones, donde cada nuevo
ejecutable incorpora mejoras incrementales sobre los otros.

Este proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental puede descomponerse
en fases. Una fase es el intervalo de tiempo entre dos hitos importantes del proceso.

Fases
Hay cuatro fases en el ciclo de vida del desarrollo de software: inicio, elaboracin, construccin y transicin.
1. Inicio (o concepcin): se desarrolla una descripcin final del producto a partir de una buena idea y se
presenta el anlisis de negocio para el producto.
2. Elaboracin: se especifican en detalle la mayora de los casos de uso del producto (requerimientos) y se
disea la arquitectura del sistema.
3. Construccin: se crea el producto.
- 14 -

4. Transicin: el producto se convierte en versin beta. Un nmero reducido de usuarios con experiencia
prueba el producto e informa los defectos y deficiencias. Los desarrolladores corrigen los problemas e
incorporan algunas mejoras.
Un elemento que distingue a este proceso y que afecta a las cuatro fases es una iteracin.
Iteracin: es un conjunto bien definido de actividades, con un plan y unos criterios de evaluacin bien establecidos,
que acaba en un sistema que puede ejecutarse, probarse y evaluarse.

Diagramas
Diagrama: es una representacin grfica de un conjunto de elementos, que la mayora de las veces se dibuja como
un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se utilizan para visualizar un sistema desde
diferentes perspectivas.
Los diagramas de UML se dividen en dos categoras, diagramas estructurales y diagramas de comportamiento.

Diagramas estructurales: sirven para representar las partes estticas de un sistema. Ejemplos: de clase, de
componentes, de estructura compuesta, de objetos, de despliegue y de artefactos.
Diagramas de comportamiento: sirven para representar las partes dinmicas de un sistema. Ejemplo: de
casos de uso, de secuencia, de comunicacin, de estados y de actividades.
(Ver diagramas en bloques bsicos de construccin)

Para cualquier sistema, los diagramas se organizan en paquetes, excepto en los triviales.

Interacciones
Interaccin: es un comportamiento que incluye un conjunto de mensajes que se intercambian un conjunto de
objetos dentro de un contexto para lograr un propsito.
Las interacciones se utilizan para modelar los aspectos dinmicos de las colaboraciones, que representan sociedades
de objetos que desempean roles especficos, y colaboran entre s para desarrollar un comportamiento mayor que
la suma de sus elementos.
Cada interaccin puede modelarse de dos formas: destacando la ordenacin temporal de los mensajes, o destacando
la secuencia de mensajes en el contexto de una organizacin estructural de objetos.
En UML, los aspectos dinmicos de un sistema se modelan mediante interacciones. Una interaccin establece el
escenario para su comportamiento presentando todos los objetos que colaboran para realizar alguna accin. Las
interacciones incluyen mensajes enviados entre objetos. Un mensaje implica la invocacin de una operacin o el
envo de una seal; un mensaje tambin puede incluir la creacin o destruccin de otros objetos.

Contexto
Una interaccin puede aparecer siempre que haya unos objetos enlazados a otros. Las interacciones aparecern en
la colaboracin de objetos existentes en el contexto de un sistema o subsistema, en el contexto de una operacin y
en el contexto de una clase.

Objetos y roles
Los objetos que participan en una interaccin son o bien elementos concretos (algo del mundo real) o bien
elementos prototpicos (instancias).
En el contexto de una interaccin podemos encontrar instancias de clases, componentes, nodos y casos de uso.
Aunque las clases abstractas y las interfaces, por definicin, no pueden tener instancias directas, podemos
representar instancias de estos elementos en una interaccin (clases hijas concretas o clases que realicen la interfaz).
- 15 -

Enlaces y conectores
Enlace: conexin semntica entre objetos. Es una instancia de una asociacin.
Un enlace especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto (o a s mismo).

Mensajes
Mensaje: es la especificacin de una comunicacin entre objetos que transmite informacin, con la expectativa de
que se desencadenar una actividad.
Cuando se pasa un mensaje, su recepcin produce normalmente una accin. Una accin puede producir un cambio
en el estado del destinatario y en los objetos accesibles desde l.
Se pueden modelar varios tipos de acciones:

Llamada: invoca una operacin sobre un objeto.

Retorno: devuelve un valor al invocador.
Envo: enva una seal a un objeto.
Creacin: crea un objeto.
Destruccin: destruye un objeto.

El tipo ms comn de mensaje que se modelar ser la llamada, en la cual un objeto invoca una operacin de otro
objeto (o de l mismo).
Los mensajes tambin pueden corresponderse con el envo de seales. Una seal es un valor objeto que se comunica
de manera asncrona a un objeto destinatario. Despus de enviar la seal, el objeto que la envi contina su propia
ejecucin. Cuando el objeto destinatario recibe la seal, l decide qu hacer con ella. Normalmente las seales
disparan transiciones en la mquina de estados del receptor.

Secuenciacin
Cuando un objeto enva un mensaje a otro, el objeto receptor puede, a su vez, enviar un mensaje a otro objeto, el
cual puede enviar un mensaje a otro objeto diferente, y as sucesivamente. Este flujo de mensajes forma una
secuencia. El inicio de cada secuencia tiene su origen en algn proceso o hilo que la contiene.
Los mensajes se ordenan en secuencia conforme sucedan en el tiempo. Para visualizar mejor la secuencia de
mensajes, se puede expresar explcitamente la posicin de un mensaje con relacin al inicio de la secuencia,
precedindolo de un nmero de secuencia, separado por dos puntos.

Creacin, modificacin y destruccin

La mayora de las veces, los objetos que participan en una interaccin existen durante todo el tiempo que dura la
interaccin. Sin embargo, algunas interacciones pueden conllevar la creacin y destruccin de objetos. Esto tambin
se aplica a los enlaces.
En un diagrama de secuencia se representan de manera explcita la vida, la creacin y destruccin de objetos o roles
a travs de la longitud vertical de sus lneas de vida. Dentro de un diagrama de comunicacin, la creacin y la
destruccin deben indicarse con notas.

Representacin
Los roles y los mensajes implicados en una interaccin se pueden visualizar de dos formas: destacando la ordenacin
temporal de sus mensajes, o destacando la organizacin estructural de los roles que envan y reciben mensajes. El
primero se llama diagrama de secuencia, y el segundo, diagrama de comunicacin.
Los diagramas de secuencia y de comunicacin son similares, lo que significa que podemos partir de uno de ellos y
transformarlo en el otro, aunque a veces muestren informacin diferente. Los diagramas de secuencia permiten
- 16 -

modelar la lnea de vida de un objeto, mientras que los de comunicacin permiten modelar los enlaces estructurales
que pueden existir entre los objetos de la interaccin.

Diagrama de secuencia: destaca la ordenacin temporal de los mensajes. Un mensaje se representa con una
flecha que va de una lnea de vida hasta la otra. Tienen dos caractersticas que los distinguen de los de
comunicacin:
o Lnea de vida: es una lnea discontinua vertical que representa la existencia de un objeto a lo largo
de un perodo de tiempo.
o Foco de control: es un rectngulo delgado y estrecho que representa el perodo de tiempo durante
el cual un objeto ejecuta una accin.
Diagrama de comunicacin: destaca la organizacin de los objetos que participan en la interaccin. Tienen
dos caractersticas que los distinguen de los de secuencia:
o El camino: es una lnea que se dibuja hacindola corresponder con una asociacin.
o Nmero de secuencia: nmero que indica el orden del mensaje.

Mquinas de estados
Mquina de estados: es un comportamiento que especifica la secuencia de estados por las que pasa un objeto
durante su vida, en respuesta a eventos, junto con sus respuestas a esos eventos.
Se utilizan para modelar los aspectos dinmicos de un sistema. La mayora de las veces, esto implica modelar la vida
de las instancias de una clase, un caso de uso o un sistema completo. Estas instancias pueden responder a eventos
tales como seales, operaciones o el paso del tiempo. Al ocurrir un evento, tendr lugar un cierto efecto, segn el
estado actual del objeto. Un efecto es la especificacin de la ejecucin de un comportamiento dentro de una
mquina de estados. Conllevan la ejecucin de acciones que cambian el estado de un objeto o devuelven valores. El
estado de un objeto es un perodo de tiempo durante el cual satisface alguna condicin, realiza alguna actividad o
espera algn evento.
La dinmica de la ejecucin se puede ver de dos formas: destacando el flujo de control entre actividades (con
diagramas de actividades), o destacando los estados potenciales de los objetos y las transiciones entre esos estados
(con diagramas de estados).
Mientras que en una interaccin se modela una sociedad de objetos que colaboran para llevar a cabo alguna accin,
una mquina de estados modela la vida de un nico objeto, bien sea una instancia de una clase, un caso de uso o un
sistema completo. Durante su vida, un objeto puede estar expuesto a varios tipos de eventos, como una seal, la
invocacin de una operacin, la creacin o destruccin del objeto, el paso del tiempo o el cambio en alguna
condicin.
Como respuesta a estos eventos, el objeto reacciona con alguna accin, y despus cambia su estado a un nuevo
valor.

Conceptos
Estado: es una condicin o situacin en la vida de un objeto durante el cual satisface alguna condicin, realiza alguna
actividad o espera algn evento.
Evento: es la especificacin de un acontecimiento significativo situado en el tiempo y en el espacio. Es la aparicin
de un estmulo que puede disparar una transicin de estados (o no).
Transicin: es una relacin entre dos estados que indica que un objeto que est en el primer estado realizar ciertas
acciones y entrar en el segundo estado cuando ocurra un evento especificado y se satisfagan ciertas condiciones
especificadas.
Actividad: es una ejecucin no atmica en curso, dentro de una mquina de estados.
- 17 -

Accin: es una computacin atmica ejecutable que produce un cambio en el estado del modelo o devuelve un
valor.

Contexto
Es la mejor forma de especificar el comportamiento de los objetos que deben responder a estmulos asncronos o
cuyo comportamiento actual depende de su pasado.

Estados
Un objeto permanece en un estado durante una cantidad de tiempo finita.
Un estado tiene varias partes:

Nombre: cadena de texto que distingue al estado de otros.

Efectos de entrada/salida: acciones ejecutadas al entrar y salir del estado.
Transiciones internas: transiciones que se manejan sin causar un cambio de estado.
Subestados: estructura anidada de un estado, que engloba subestados disjuntos o concurrentes. Estados
anidados dentro de otro.
Eventos diferidos: lista de eventos que no se manejan en este estado sino que se posponen y se aaden a
una cola para ser manejado por el objeto en otro estado.

En la mquina de estados de un objeto se pueden definir dos estados especiales:

Estado inicial: indica el punto de comienzo por defecto para la mquina de estados. Se representa mediante
un crculo negro.
Estado final: indica que la ejecucin de la mquina de estados o del estado que lo contiene ha finalizado. Se
representa con un crculo negro dentro de un crculo blanco.

Transiciones
Una transicin tiene cinco partes:

Estado origen: el estado afectado por la transicin.

Evento de disparo: evento que provoca la transicin.
Condicin de guarda: expresin booleana que se evala cuando la transicin se activa por la recepcin del
evento de disparo.
Efecto: un comportamiento ejecutable, como una accin.
Estado destino: el estado activo tras completarse la transicin.

Una transicin se representa con una lnea continua dirigida desde el estado origen hacia el destino. Una
autotransicin es una transicin donde el estado origen y el estado destino son el mismo.
NOTA: a los diagramas de interaccin se le agregan los diagramas de timing y los diagramas de descripcin de
interaccin.
El diagrama de una mquina de estados es a nivel de clase, mientras que el de timing es a nivel de instancia (o sea a
nivel de objeto).

- 18 -

PATRONES GRASP
Responsabilidades y mtodos
UML define una responsabilidad como un contrato u obligacin de un clasificador. Las responsabilidades estn
relacionadas con las obligaciones de un objeto en cuanto a su comportamiento. Estas responsabilidades son de dos
tipos: conocer y hacer.

Responsabilidades del conocer:

o Conocer datos privados encapsulados. Conocer
datos propios como nombre, apellido, dni,
fechaNacimiento.
o Conocer objetos relacionados. Conocer
atributos de las clases relacionadas como nacio.
o Conocer las cosas que puede derivar o calcular. Conocer datos que se pueden calcular de datos
propios como la edad mediante calcularEdad() que utilizar fechaNacimiento para realizar el clculo.
Responsabilidades del hacer:
o Hacer algo l mismo, como crear un objeto o hacer un clculo, y responder peticiones.
o Iniciar una accin en otros objetos (delegar responsabilidades).
o Controlar y coordinar actividades en otros objetos.

Una responsabilidad no es lo mismo que un mtodo, pero los mtodos se implementan para llevar a cabo
responsabilidades. Las responsabilidades se implementan utilizando mtodos que o actan solos o colaboran con
otros mtodos u objetos.

Patrones
Un patrn es una descripcin de un problema y la solucin, a la que se da un nombre, y que se puede aplicar a
nuevos contextos. Proporciona consejos sobre el modo de aplicarlo en varias circunstancias, y considera los puntos
fuertes y compromisos.
Patrn: es un par problema/solucin con nombre que se puede aplicar en nuevos contextos, con consejos acerca de
cmo aplicarlo en nuevas situaciones y discusiones sobre sus compromisos.
Los importante de los patrones no es expresar nuevas ideas de diseo, sino justamente lo contrario. Los patrones
pretenden codificar conocimientos, estilos y principios existentes y que se han probado que son vlidos.
Todos los patrones, idealmente, tienen nombres sugerentes que apoyan la identificacin e incorporacin de ese
concepto en nuestro conocimiento y memoria, y facilita la comunicacin.

Patrones de asignacin de responsabilidades (GRASP)

Patrones GRASP: describen los principios fundamentales del diseo de objetos y la asignacin de responsabilidades,
expresados como patrones. GRASP (General Responsibility Assignment Software Patterns).
1.
2.
3.
4.
5.

Experto en informacin.
Creador.
Alta cohesin.
Bajo acoplamiento.
Controlador.

Experto en informacin
Solucin: asignar una responsabilidad al experto en informacin (la clase que tiene la informacin necesaria para
realizar la responsabilidad).
- 19 -

Poner el comportamiento lo ms cerca posible de los datos, o sea, poner los mtodos en la clase que tiene los datos
para cumplir con el comportamiento.
Ejemplo:

En el primer ejemplo, el gestor junta todos los nombres de las pelculas y luego resuelve el problema el mismo
(verificar si existe).
En el segundo ejemplo, se delega la responsabilidad a la clase Pelcula, donde directamente el gestor le pregunta si
existe, y la misma Pelcula, utilizando su atributo nombre se encargar de resolver el problema.
Beneficios:

Se mantiene el encapsulamiento de la informacin, puesto que los objetos utilizan su propia informacin
para llevar a cabo las tareas. Esto conlleva a un bajo acoplamiento, lo que da lugar a sistemas ms robustos
y fciles de mantener.
Se distribuye el comportamiento entre las clases que contienen la informacin requerida, por tanto, se
estimula las definiciones de clases ms cohesivas y ligeras que son ms fciles de entender y mantener.

Creador
Solucin: asignar a la clase A la responsabilidad de crear una instancia de la clase B si se cumple uno o ms de los
casos siguientes:
1. A est formado por B
2. A est compuesto por B
3. A tiene la informacin para
crear a B
4. A contiene a B
5. A utiliza a B

- 20 -

Ejemplo:

Aplicando el patrn se eliminan dependencias que son innecesarias, disminuyendo el acoplamiento.

Beneficios:

Se soporta bajo acoplamiento, lo que implica menos dependencias de mantenimiento y mayores

oportunidades para reutilizar.
No se incrementa el acoplamiento porque la clase creada es presumible que ya sea visible a la clase creadora,
debido a las asociaciones existentes que motivaron su eleccin como creador.

- 21 -

Bajo acoplamiento
Solucin: asignar una responsabilidad de manera que el acoplamiento permanezca bajo
Acoplamiento: es una medida de la fuerza con que un elemento est conectado a, tiene conocimiento de, confa en,
otros elementos. Un elemento con bajo (o dbil) acoplamiento no depende de demasiados otros elementos;
demasiados depende del contexto.
Una clase con alto (o fuerte) acoplamiento confa en muchas otras clases. Tales clases podran no ser deseables;
algunas adolecen de los siguientes problemas:

Los cambios en las clases relacionadas fuerzan cambios locales.

Son difciles de entender de manera aislada.
Son difciles de reutilizar puesto que su uso requiere la presencia adicional de las clases de las que depende.

Es la idea de tener las clases lo menos ligadas entre s que se pueda. De tal forma que en caso de producirse una
modificacin en alguna de ellas, se tenga la mnima repercusin posible en el resto de clases, potenciando la
reutilizacin, y disminuyendo la dependencia entre las clases.
El caso extremo de Bajo Acoplamiento es cuando no existe acoplamiento entre clases. Esto no es deseable porque
una metfora central de la tecnologa de objetos es un sistema de objetos conectados que se comunican mediante
el paso de mensajes.
Un grado moderado de acoplamiento es normal y necesario si quiere crearse un sistema orientado a objetos, donde
los objetos colaboran entre s.
Beneficios:

No afectan los cambios en otros componentes.

Fcil de entender de manera aislada.
Conveniente para reutilizar.

Alta cohesin
Solucin: asignar una responsabilidad de manera que la cohesin permanezca alta.
Cohesin: es una medida de la fuerza con la que se relacionan los objetos y de grado de focalizacin de las
responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas, y que no hace una
gran cantidad de trabajo, tiene alta cohesin.
Una clase con baja cohesin hace muchas cosas no relacionadas, o hace demasiado trabajo. Tales clases no son
convenientes, adolecen de los siguientes problemas:

Difciles de entender.
Difciles de reutilizar.
Difciles de mantener.
Delicadas, constantemente afectadas por los cambios.

Cada atributo y mtodo tiene que tener sentido con el concepto de la clase. Una alta cohesin funcional provoca una
mayor cantidad de clases.
Beneficios:

Se incrementa la claridad y facilita la compresin del diseo.

Se simplifican el mantenimiento y las mejoras.
Se soporta a menudo bajo acoplamiento.
- 22 -

Incrementa la reutilizacin porque una clase cohesiva se puede utilizar para un propsito muy especfico.

Controlador
Solucin: asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que
representa una de las siguientes opciones:

Representa el sistema global, dispositivo o subsistema.

Representa un escenario de caso de uso en el que tiene lugar el evento del sistema.

Controlador: es un objeto que no pertenece a la interfaz de usuario, responsable de recibir o manejar un evento del
sistema. Un controlador define el mtodo para la operacin del sistema.
Es un patrn que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal
forma que es la que recibe los datos del usuario y la que los enva a las distintas clases segn el mtodo llamado. Este
patrn sugiere que la lgica de negocios debe estar separada de la capa de presentacin, esto para aumentar la
reutilizacin de cdigo y a la vez tener un mayor control.
Normalmente, un controlador debera delegar en otros objetos el trabajo que necesita hacer, coordina o controla la
actividad.
Hay dos categoras de controlador:

Controlador de fachada: representa al sistema global, dispositivo o subsistema. Son adecuados cuando no
existen demasiados eventos del sistema, o no es posible que la interfaz de usuario (UI) redireccione
mensajes de los eventos del sistema a controladores alternativos.
Controlador de casos de uso: hay un controlador diferente para cada caso de uso. Aqu, el controlador no
es un objeto de dominio; es una construccin artificial para dar soporta al sistema (clase de fabricacin pura).

Un importante corolario del patrn Controlador es que los objetos interfaz y la capa de presentacin no deberan
ser responsables de llevar a cabo los eventos del sistema. Las operaciones del sistema se deberan manejar en la
lgica de la aplicacin o capa del dominio en lugar de en la capa de interfaz del sistema. El controlador recibe la
solicitud del servicio desde la capa de UI y coordina su realizacin, normalmente delegando a otros objetos.
Intermediario entre la interfaz y las entidades.
Beneficios:

Aumenta el potencial para reutilizar y las interfaces conectables: asegura que la lgica de la aplicacin no se
maneja en la capa de interfaz. Delegando la responsabilidad de una operacin del sistema a un controlador
ayuda a la reutilizacin de la lgica en futuras aplicaciones. Y puesto que la lgica no est ligada a la capa de
interfaz, puede sustituirse por una interfaz nueva.
Razonamiento sobre el estado de los casos de uso: a veces es necesario asegurar que las operaciones del
sistema tienen lugar en una secuencia vlida, o ser capaces de razonar sobre el estado actual de la actividad
y operaciones del caso de uso que est en marcha.

Fabricacin pura: es una creacin arbitraria del diseador, no una clase software cuto nombre se inspira en el
modelo de dominio. Un controlador de caso de uso es un tipo de fabricacin pura.

- 23 -

WORKFLOW DE DISEO
Introduccin
En el diseo modelamos el sistema y encontramos su forma (incluida la arquitectura) para que soporte todos los
requerimientos, incluyendo los requerimientos no funcionales y otras restricciones. Una entrada esencial en el
diseo es el resultado del anlisis, o sea el modelo de anlisis, el cual proporciona una comprensin detallada de los
requerimientos e impone una estructura del sistema que debemos esforzarnos por conservar los ms fielmente
posible al momento de darle forma al sistema.

Anlisis vs Diseo
El anlisis:

Ofrece una especificacin ms precisa de los requerimientos.

Se describe utilizando el lenguaje de los desarrolladores, introduciendo mayor formalismo.
Estructura los requerimientos de modo que facilita su comprensin, su preparacin, su modificacin, y su
mantenimiento.
Es la primera aproximacin al diseo.

El diseo:

Es un proceso mediante el cual se aplican varias tcnicas y principios con el objetivo de definir un dispositivo,
un proceso o un sistema con suficiente nivel de detalle como para permitir su realizacin fsica.
Es un proceso iterativo de transformar un modelo lgico en un modelo fsico, teniendo en cuenta las
restricciones del negocio.
Es el proceso de decidir de cmo se va a construir el producto final.

MODELO DE ANLISIS

MODELO DE DISEO

Modelo conceptual, porque es una

abstraccin del sistema.
Genrico respecto al diseo (es aplicable a
varios diseos).
Tres estereotipos conceptuales sobre las
clases: entidad, control e interfaz.

Menos formal.
Menos caro de desarrollar.
Dinmico (no muy centrado en la secuencia).
Bosquejo del diseo del sistema, incluyendo
su arquitectura.
Puede no estar mantenido durante todo el
ciclo de vida del software.
Define una entrada que es esencial para
modelar el sistema.

Modela la solucin en trminos lgicos.

- 24 -

Modelo fsico, porque es un plano de la

implementacin.
No es genrico, es especfico para una
implementacin.
Nmero indefinido de estereotipos (fsicos) sobre
las clases, dependiendo del lenguaje de
programacin.
Ms formal.
Ms caro de desarrollar.
Dinmico (muy centrado en las secuencias).
Manifiesto del diseo del sistema, incluyendo su
arquitectura.
Debe ser mantenido durante todo el ciclo de vida
del software.
Da forma al sistema mientras que se intenta
preservar la estructura definida en el modelo de
anlisis lo ms posible.
Modela la solucin en trminos fsicos.

Propsitos del diseo

Adquirir una compresin profunda de aspectos relacionados con requerimientos no funcionales y

restricciones del entorno de implementacin (lenguajes de programacin, sistemas operativos, etc.).
Refinar los requerimientos para subsistemas, clases e interfaces.
Descomponer el trabajo de implementacin en piezas manejables por diferentes equipos de desarrollo.
Capturar interfaces entre subsistemas.
Crear una abstraccin de la implementacin del sistema.

El papel del diseo en el ciclo de vida del software

El diseo es el centro de atencin al final de la fase de elaboracin y el comienzo de las iteraciones de construccin.
Durante la fase de construccin, cuando la arquitectura es estable y los requerimientos estn bien entendidos, el
centro de atencin se desplaza a la implementacin.
El modelo de diseo se puede utilizar para visualizar la implementacin y para soportar las tcnicas de programacin
grfica. A esto se lo denomina ingeniera de ida y vuelta. El diseo crea el plano para el modelo de implementacin.

Artefactos de diseo
1.
2.
3.
4.
5.
6.
7.
8.

Modelo de diseo.
Clase de diseo.
Realizacin de caso de uso-diseo.
Subsistema de diseo.
Interfaz.
Descripcin de la arquitectura (vista del modelo de diseo).
Modelo de despliegue.
Descripcin de la arquitectura (vista del modelo de despliegue).

Modelo de diseo
Es un modelo de objetos que describe la realizacin fsica de los casos de uso centrndose en cmo los
requerimientos funcionales y no funcionales, junto con otras restricciones de la implementacin, tienen impacto en
el sistema a considerar. Sirve de abstraccin de la implementacin del sistema.
Los casos de uso son realizados por clases de diseo y sus objetos. Esto se representa por colaboraciones en el
modelo de diseo y denota realizacin de caso de uso-diseo.

- 25 -

Clase de diseo
Las clases de diseo son clases cuyas especificaciones se han completado hasta tal nivel que se pueden implementar.

Son especificadas mediante un lenguaje de programacin.

Se especifican con frecuencia la visibilidad de los atributos y operaciones.
Los mtodos (realizaciones de operaciones) de una clase de diseo, tienen correspondencia directa con el
correspondiente mtodo en la implementacin de las clases (en el cdigo).
Una clase de diseo puede posponer el manejo de algunos requerimientos para las subsiguientes actividades
de implementacin, indicndolos como requerimientos de implementacin de la clase.
Una clase de diseo puede realizar (y por tanto, proporcionar) interfaces, si tiene sentido hacerlo en el
lenguaje de programacin.
Una clase de diseo puede activarse, implicando que objetos de la clase mantengan su propio hilo de control
y se ejecuten concurrentemente con otros objetos activos.

Las clases de diseo provienen de dos lados:

El mbito del problema va una mejora de las clases de anlisis: a las clases de anlisis se le aaden detalles
de implementacin.
El mbito de la solucin: es el mbito de libreras de clases de utilidad y componentes reutilizables (Time,
Date, String, colecciones, middleware, frameworks, etc.).

En las clases de diseo hay que especificar: atributos (nombre, tipo, visibilidad y opcionalmente un valor
predeterminado), operaciones o mtodos (nombre, parmetros con tipo y tipo de retorno). Esto adems sirve para
generar cdigo que despus les servir a los programadores.
Cuatro caractersticas que debe tener una clase de diseo para que se considere bien diseada:

Completa y suficiente: proporciona a los clientes lo que se espera de ella y contiene el conjunto esperado
de operaciones y nada ms.
Sencilla: ofrece un solo servicio sencillo. A veces se relaja un poco por cuestiones de rendimiento.
Alta cohesin: tiene un pequeo nmero de responsabilidades que estn ntimamente relacionadas. Son
fciles de entender y mantener, y son reutilizables.
Bajo acoplamiento: debera asociarse con clases si solamente tienen vnculo semntico entre ellas.

Realizacin de caso de uso-diseo

Una realizacin de caso de uso-diseo es una colaboracin en el modelo de diseo que describe como se realiza un
caso de uso especfico, y como se ejecuta, en trminos de clases de diseo y sus objetos.
Una realizacin de caso de uso-diseo tiene una descripcin de flujo de eventos textual, diagramas de clases que
muestra sus clases de diseo participantes; y diagramas de interaccin que muestran la realizacin de un flujo o
escenario concreto de un caso de uso en trminos de interaccin entre objetos del diseo.
Una realizacin de caso de uso-diseo proporciona una realizacin fsica de la realizacin de caso de uso-anlisis
para la que es trazado, y tambin gestiona muchos de los requerimientos no funcionales capturados en la realizacin
de caso de uso-anlisis.
Pueden posponer requerimientos hasta la siguiente actividad anotndolos como requerimientos de implementacin
en la realizacin.

Diagramas de clases: contienen clases de diseo, y se utilizan conectados a una realizacin de caso de usodiseo para mostrar las clases de diseo participantes, subsistemas y sus relaciones.

- 26 -

Diagramas de interaccin: muestran la interaccin entre objetos para llevar a cabo el caso de uso. En el
diseo es preferible utilizar diagramas de secuencia ya que es importante encontrar secuencias de
interacciones detalladas y ordenadas en el tiempo.
Flujo de sucesos-diseo: es una descripcin textual que explica y complementa a los diagramas y a sus
etiquetas.
Requerimientos de implementacin: requerimientos capturados en el diseo, pero que es mejor tratarlos
en la implementacin.

Subsistema de diseo
Son una forma de organizar los artefactos del modelo de diseo en piezas ms manejables.
Un subsistema debera ser cohesivo, es decir, sus contenidos deberan estar fuertemente asociados. Adems, los
subsistemas deberan ser dbilmente acoplados, esto es, sus dependencias entre unos y otros, o entre sus interfaces,
deberan ser mnimas.
Deberan poseer las siguientes caractersticas:

Pueden representar una separacin de aspectos del diseo. Un sistema puede desarrollarse por separado
por diferentes grupos de desarrolladores.
Las dos capas de aplicacin de ms alto nivel y sus subsistemas dentro del modelo de diseo suelen tener
trazas directas hacia paquetes y/o clases del anlisis.
Pueden representar componentes de grano grueso en la implementacin del sistema.
Pueden representar productos de software reutilizados que han sido encapsulados en ellos.
Pueden representar sistemas heredados (o parte de ellos) encapsulndolos.

Interfaz
Las interfaces se utilizan para especificar las operaciones que proporcionaran las clases y los subsistemas de diseo.
Constituyen una forma de separar la especificacin de la funcionalidad en trminos de operaciones de sus
implementaciones en trminos de mtodos.
Podemos sustituir una implementacin concreta de una interfaz, como puede ser una clase o un subsistema del
diseo, por otra implementacin sin tener que cambiar los clientes.

Descripcin de la arquitectura (vista del modelo de diseo)

La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de diseo que muestra los
artefactos ms significativos para la arquitectura, como:

La descomposicin del modelo de diseo en subsistemas, sus interfaces y las dependencias entre ellos, ya
que constituyen la estructura fundamental del sistema.
Clases del diseo fundamentales, como clases con traza con clases del anlisis, clases activas, clases de
diseo generales y centrarles; normalmente son clases abstractas.
Realizaciones de caso de uso-diseo que describan alguna funcionalidad importante y crtica que debe
desarrollarse pronto dentro del ciclo de vida del software, que impliquen muchas clases de diseo y por
tanto tengan una cobertura amplia, posiblemente a lo largo de varios subsistemas.

Modelo de despliegue
El modelo de despliegue es un modelo de objetos que describe la distribucin fsica del sistema en trminos de cmo
se distribuye la funcionalidad entre los nodos de cmputo.

Cada nodo representa un recurso de cmputo (ej. procesador).

- 27 -

Los nodos poseen relaciones que representan medios de comunicacin entre ellos (ej. internet, intranet,
bus, etc.).
El modelo de despliegue puede describir diferentes configuraciones de red.
La funcionalidad (los procesos) de un nodo se definen por los componentes que se distribuyen en ellos.
El modelo de despliegue en s mismo representa una correspondencia entre la arquitectura software y la
arquitectura del sistema (el hardware).

Descripcin de la arquitectura (vista del modelo de despliegue)

La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de despliegue que muestra sus
artefactos relevantes para la arquitectura.
Debido a su importancia, deberan mostrarse todos los aspectos del modelo de despliegue en la vista arquitectnica,
incluyendo la correspondencia de los componentes sobre los nodos tal como se identific durante la
implementacin.

Trabajadores del diseo

1. Arquitecto.
2. Ingeniero de casos de uso.
3. Ingeniero de componentes.

Arquitecto
En el diseo, el arquitecto es responsable de la integridad de los modelos de diseo y de despliegue, garantizando
que los modelos sean correctos, consistentes y legibles como un todo.
Los modelos son correctos cuando realizan la funcionalidad, y slo la funcionalidad, descrita en el modelo de casos
de uso, en los requerimientos adicionales y en el modelo de anlisis.
Tambin, es responsable de la arquitectura de los modelos de diseo y despliegue, es decir, de la existencia de sus
partes significativas para la arquitectura.
No es responsable del desarrollo y mantenimiento continuos de los distintos artefactos del modelo de diseo.

Ingeniero de casos de uso

El ingeniero de casos de uso es responsable de la integridad de una o ms realizaciones de caso de uso-diseo, y
debe garantizar que cumplen los requerimientos que se esperan de ellos. Una realizacin de caso de uso-diseo
debe realizar correctamente el comportamiento de su correspondiente realizacin de caso de uso-anlisis del
modelo de anlisis, as como el comportamiento de su correspondiente caso de uso del modelo de casos de uso, y
solo esos comportamientos.

Ingeniero de componentes
El ingeniero de componentes define y mantiene las operaciones, mtodos, atributos, relaciones y requerimientos
de implementacin de una o ms clases del diseo, garantizando que cada clase cumple los requerimientos
esperados de ella segn las realizaciones de caso de uso en las que participa.
El ingeniero de componentes puede mantener tambin la integridad de uno o ms subsistemas. Esto incluye
garantizar que sus contenidos (clases y relaciones) son correctos, que las dependencias de otros subsistemas y/o
interfaces son correctas y mnimas, y que realizan correctamente las interfaces que ofrecen.

- 28 -

Flujo de trabajo (actividades)

1. Los arquitectos inician la creacin de los modelos de diseo y de despliegue (esbozan nodos del modelo de
despliegue, los subsistemas principales y sus interfaces, las clases de diseo importantes).
2. Despus, los ingenieros de casos de uso realizan cada caso de uso en trminos de clases y/o subsistemas del
diseo participantes y sus interfaces.
3. Los ingenieros de componentes especifican a continuacin los requerimientos, y los integran dentro de cada
clase, bien mediante la creacin de operaciones, atributos y relaciones consistentes sobre cada clase, o bien
mediante la creacin de operaciones consistentes en cada interfaz que proporcione el subsistema.
4. A lo largo del flujo de trabajo de diseo, los desarrolladores identificarn, a medida que evolucione el diseo,
nuevos candidatos para ser subsistemas, interfaces, clases y mecanismos de diseo genrico, y los
ingenieros de componentes responsables de los subsistemas individuales debern refinarlos y mantenerlos.

Diseo de la arquitectura (por arquitecto)

El objetivo del diseo de la arquitectura es esbozar los modelos de diseo y despliegue y su arquitectura mediante
la identificacin de los siguientes elementos:
Identificacin de nodos y configuraciones de red
Las configuraciones de red habituales utilizan un patrn de tres capas en el cual los clientes se dejan en una
capa, la funcionalidad de la base de datos en otra, y la lgica de negocio en una tercera. Aspectos a tener en
cuenta:

Que nodos se necesitan. Cul debe ser su capacidad en trminos de potencia y tamao de memoria.
Qu tipo de conexiones debe haber entre los nodos. Que protocolos de comunicaciones se deben
utilizar.
- 29 -

Qu caractersticas deben tener las conexiones y los protocolos de comunicaciones, como el ancho de
banda, disponibilidad, calidad.
Si se necesita copias de seguridad de datos, capacidad de procesos redundante, etc.

Identificacin de subsistemas y sus interfaces

Los subsistemas pueden identificarse inicialmente como una forma de dividir el trabajo de diseo, o bien
pueden irse encontrando a medida que el modelo de diseo evoluciona y va creciendo hasta convertirse en una
gran estructura que debe ser descompuesta. Algunos subsistemas representan productos reutilizados y otros
son recursos existentes en la empresa.
Identificacin de clases de diseo significativas para la arquitectura
Los desarrolladores deberan evitar el identificar demasiadas clases en esta etapa o el quedar atrapados en
demasiados detalles. Sera suficiente con un esbozo inicial de las clases significativas para la arquitectura, como
las clases activas.
Identificacin de mecanismos genricos de diseo
El resultado es un conjunto de mecanismos genricos de diseo que pueden manifestarse como clases,
colaboraciones, subsistemas. Los requerimientos a tratarse suelen estar relacionados con: persistencia,
distribucin transparente de objetos, caractersticas de seguridad, deteccin y recuperacin de errores, etc.

Diseo de un caso de uso (por ing. de casos de uso)

Los objetivos de disear un caso de uso son:

Identificar las clases del diseo y/o subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de
sucesos del caso de uso.
Distribuir el comportamiento del caso de uso entre los objetos del diseo que interactan y/o entre los
subsistemas participantes.
Definir los requerimientos sobre las operaciones de las clases del diseo y/o sobre los subsistemas y sus
interfaces.
Capturar los requerimientos de implementacin del caso de uso.

Identificar las clases del diseo participantes

Se identifican las clases de diseo necesarias para realizar el caso de uso.

Estudiar las clases del anlisis que participan en la correspondiente realizacin de caso de uso-anlisis.
- 30 -

Estudiar los requerimientos especiales de la correspondiente realizacin de caso de uso-anlisis,

identificando las clases del diseo que los cumplen.

Descripcin de las interacciones entre objetos del diseo

Debemos describir cmo interactan los objetos del diseo correspondientes a las clases del diseo. Esto se
hace mediante diagramas de secuencia que contienen instancias de los actores, los objetos del diseo y las
transmisiones de mensajes entre stos, que participan en el caso de uso.
Identificacin de subsistemas e interfaces participantes
A veces es ms apropiado disear un caso de uso en trmino de los subsistemas y/o interfaces que participan
en l:

Estudiar las clases del anlisis que participen en las correspondientes realizaciones de caso de usoanlisis. Identificar los paquetes del anlisis que contienen a esas clases del anlisis, si existen. Despus,
identificar los subsistemas del diseo que poseen una traza hacia eses paquetes del anlisis.
Estudiar los requerimientos especiales de las correspondientes realizaciones de caso de uso-anlisis.
Identificar las clases de diseo que realizan dichos requerimientos especiales, si existen. Despus,
identificar los subsistemas del diseo que contienen a esas clases.

Descripcin de interfaces entre subsistemas

Cuando tenemos un esbozo de los subsistemas necesarios para realizar el caso de uso, debemos describir cmo
interactan los objetos de las clases que contiene en el nivel de subsistema. Lo haremos mediante el diagrama
de secuencia, que contiene instancias de actores, subsistemas, y transmisiones de mensajes entre stos.
Captura de requerimientos especiales
Se capturan los requerimientos que se tratarn en la implementacin.

Diseo de una clase (por ing. de componentes)

El propsito de disear una clase es crear una clase de diseo que cumpla su papel en las realizaciones de los casos
de uso y los requerimientos no funcionales que se aplican a estos.
Esbozar una clase
Esbozar clases de diseo tomando como entrada clases de anlisis (entidades, de control) y/o interfaces.
Identificar operaciones
Identificamos las operaciones que las clases del diseo van a necesitar y describimos esas operaciones
utilizando la sintaxis los lenguajes de programacin, incluyendo la visibilidad (public, private, protected, etc.).

- 31 -

Identificar atributos
Identificamos los atributos requeridos por la clase de diseo y los describimos utilizando la sintaxis del lenguaje
de programacin. Un atributo especifica una propiedad de una clase de diseo y est a menudo implicado y es
requerido por las operaciones de la clase.
Identificar asociaciones y agregaciones
Como los objetos del diseo interactan unos con otros, estas interacciones necesitan asociaciones entre las
clases correspondientes.
Identificar las generalizaciones
Las generalizaciones deben utilizarse con la misma semntica definida en el lenguaje de programacin.
Describir los mtodos
Los mtodos pueden ser utilizados en el diseo para especificar como se deben realizar las operaciones. El
mtodo puede ser especificado mediante lenguaje natural o pseudocdigo, aunque la mayora de las veces no
son especificados en el diseo, sino en la implementacin utilizando directamente el lenguaje de programacin.
Describir estados
Se utilizan diagramas de estado para describir las diferentes transiciones de estado de un objeto del diseo.
Tratar requerimientos especiales
En esta fase debe ser tratado cualquier requerimiento especial que no haya sido considerado en pasos
anteriores.

Diseo de un subsistema (por ing. de componentes)

Los objetivos del diseo de un subsistema son:

Garantizar que el subsistema es tan independiente como se posible de otros subsistemas.

Garantizar que el subsistema proporciona las interfaces correctas.
Garantizar que el subsistema cumple su propsito de ofrecer una realizacin correcta de las operaciones tal
y como se definen en las interfaces que proporciona.

Mantenimiento de las dependencias entre subsistemas

Deberan definirse y mantenerse dependencias en un subsistema respecto a otros cuando los elementos no
contenidos en estos ltimos estn asociados con elementos dentro de aquel. Hay que minimizar las
dependencias entre subsistemas y/o interfaces.

- 32 -

Mantenimiento de interfaces proporcionadas por el subsistema

Las operaciones definidas por las interfaces que proporciona un subsistema deber soportar todos los roles que
cumple el subsistema en las diferentes realizaciones de caso de uso.
Mantenimiento de los contenidos de los subsistemas
Un subsistema cumple sus objetivos cuando ofrece una realizacin correcta de las operaciones tal y como estn
descritas por las interfaces que proporciona.

DISEO
Qu se disea?
1.
2.
3.
4.
5.
6.

Arquitectura.
Datos (Bases de datos).
Procesos.
Interfaces.
Formas de entrada/salida.
Procedimientos manuales.

Diseo arquitectnico
Arquitectura: es el conjunto de decisiones significativas que tomamos para cumplir los requerimientos del producto.
Se muestra a travs de vistas (diagramas de UML).
Define la relacin entre los principales elementos estructurales del programa.
Toma los requerimientos no funcionales y los aplica al modelo de anlisis.
Es un modelo genrico que no entra en detalles.

Diseo de datos (bases de datos)

Transforma los requerimientos en las estructuras de datos necesarias para implementar el software.
Para la persistencia de los objetos, se presenta el problema de que las bases de datos utilizan el modelo relacional.
Para ello hay que hacer un mapeo, que se encargar de transformar objetos a tablas de la base de datos y viceversa.
A esto se lo conoce como ORM (Object-Relational Mapping).

Diseo de procesos
Transforma elementos estructurales de la arquitectura del programa en una descripcin procedimental de los
componentes del software.
- 33 -

Se toman en cuenta aspectos como la concurrencia, distribucin de procesos, distribucin de bases de datos,
performance, persistencia, etc.

Diseo de interfaces
Describe como se comunica el software consigo mismo, con los sistemas que operan en l, con los dispositivos
externos y con los usuarios. Como se comunica el sistema con el ambiente.

Diseo de interfaces externas

Diseo de interfaces de usuario: son difciles de disear ya que se deben adecuar al conocimiento de las
personas que la van a utilizar, y deben ser de utilizada (usabilidad).
Diseo de interfaces internas: un subsistema proporciona un servicio y otro pide el servicio. Son como las
interfaces de Java (u otro lenguaje de programacin orientado a objetos).

Diseo de formas de entrada/salida

Describe cmo se ingresa informacin al software y como se presentan las salidas del mismo.
Tipos de procesamiento:

En lotes: la transaccin ocurri, pero el software la procesa despus. Se acumulan transacciones para
procesarlas despus. Se utiliza para procesar procesos lentos cuando el procesador no est ocupado.
En lnea: la transaccin se procesa en el momento en el que ocurre.
En tiempo real: son sistemas en lnea, pero puede modificar el ambiente donde est inmerso. Es muy estricto
a los tiempos de respuesta (muy preciso; si un proceso debe durar un determinado tiempo, no puede durar
ms). Ejemplo: los aspersores que se activan cuando hay un incendio y quitan el oxgeno dentro de 30
segundos.

Diseo de procedimientos manuales

Describe como integra el software al sistema de negocio.
Los procedimientos manuales nos permiten insertar el software en el negocio. Ejemplo: capacitacin, planes B, etc.
Ejemplo de Plan B: si la pgina de inscripcin a exmenes no funciona, la inscripcin se realiza personalmente en
bedela.

Gua para evaluar un buen diseo

El diseo deber implementar todos los requerimientos explcitos del modelo de anlisis y debern ajustarse a todos
los requerimientos que desea el cliente.
El diseo deber ser una gua legible y comprensible para aquellas que generan cdigo y para aquellos que comprueban
y consecuentemente, dan soporte al software.
El diseo deber proporcionar una imagen completa del software, enfrentndose a los dominios de comportamiento,
funcionales y de datos desde una perspectiva de implementacin.

Directrices sobre calidad del diseo

Un diseo deber presentar una estructura arquitectnica que:

o Se haya creado mediante patrones de diseo reconocibles.
o Que est formada por componentes que exhiban caractersticas de buen diseo.
o Que se puedan implementar de manera evolutiva, facilitando as la implementacin y la comprobacin.
Un diseo deber ser modular: es decir el software deber dividirse lgicamente en elementos que realicen funciones
y sub-funciones especficas.
Un diseo deber conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y con el
entorno externo.

- 34 -

Un diseo deber derivarse mediante un mediante un mtodo repetitivo y controlado, de la informacin obtenida
durante el anlisis de los requerimientos del software.
Un diseo deber contener distintas representaciones de datos, arquitecturas, interfaces y componentes.
Un diseo deber conducir a estructuras de datos adecuadas para los objetos que se van a implementar y que procedan
de patrones de datos reconocibles.
Un diseo deber conducir a componentes que presenten caractersticas funcionales independientes.

Principios de diseo del software

El diseo deber poderse rastrear hasta el modelo de anlisis.

El diseo no deber inventar nada que ya est inventado.
El diseo deber minimizar la distancia intelectual entre el software y el problema como si de la misma vida real se
tratara.
El diseo deber presentar uniformidad e integracin.
El diseo deber estructurase para admitir cambios.

DISEO ARQUITECTNICO
Introduccin
El diseo arquitectnico, es la asignacin de modelos de requerimiento esenciales a una tecnologa especfica. Es el
plan del diseo (es la primera etapa del diseo).
El diseo arquitectnico se interesa por entender cmo debe organizarse un sistema y como tiene que disearse la
estructura global de ese sistema.
Es el enlace crucial entre el diseo y la ingeniera de requerimientos, ya que identifica los principales componentes
estructurales en un sistema y su relacin entre ellos. La salida del proceso de diseo arquitectnico consiste en un
modelo arquitectnico que describe la forma en que se organiza el sistema como un conjunto de componentes
comunicados entre s.
Las arquitecturas de software se disean en dos niveles de abstraccin:

Arquitectura en pequeo: se interesa por la arquitectura de programas individuales. En este nivel, uno se
preocupa por la forma en que el programa individual se separa en componentes.
Arquitectura en grande: se interesa por la arquitectura de sistemas empresariales complejos que incluyen
otros sistemas, programas y componentes de programa.

La arquitectura captura la estructura del sistema en trminos de componentes y como estos interactan.

Rol del arquitecto

Revisar y negociar los requerimientos.

Documentar la arquitectura.
Comunicar la arquitectura, asegurando que los interesados la comprendan.
Direccionar los requerimientos no funcionales a la arquitectura.
Configurar la arquitectura de hardware.
Trabajar con el Administrador del Proyecto, ayudando en la planificacin, la estimacin, la distribucin de
las tareas y la calendarizacin del proyecto.

Ventajas de disear y documentar la arquitectura

Comunicacin con los participantes: la arquitectura es una presentacin que sirve para usarse como
enfoque para la discusin de un amplio nmero de participantes.
- 35 -

Anlisis del sistema: sirve para aclarar la arquitectura del sistema, para saber si se cumplen los
requerimientos crticos.
Reutilizacin a gran escala: es posible desarrollar arquitecturas de lnea de productos donde la misma
arquitectura se reutilice mediante una amplia gama de sistemas relacionados.

Requerimientos no funcionales
Los requerimientos no funcionales definen las cualidades o atributos que deben estar presentes en el producto de
software resultante.

Juegan un papel crucial en el diseo y desarrollo del sistema de informacin.

Pueden definirse como consideraciones o restricciones asociadas a un servicio del sistema.
Suelen llamarse tambin requerimientos de calidad o no comportamentales en contraste con los
comportamentales.
Pueden ser crticos con los funcionales.

Dificultades asociadas a los requerimientos no funcionales

No hay reglas ni lineamientos para determinar cundo se obtuvo una solucin ptima.
Tiene buenas y malas soluciones, no soluciones correctas e incorrectas.
Problemas relacionados con requerimientos no funcionales pueden ser sntomas de problemas mayores.
Hay dos objetivos que deben poseer: deben ser objetivos y testeables.

reas de requerimientos no funcionales

Restricciones tcnicas: restringen opciones de diseo para especificar ciertas tecnologas que la aplicacin
debe usar. Ejemplo: solo tenemos diseadores Java, la base de datos debe correr con Windows XP.
Usualmente no son negociables.
Restricciones de negocio: tambin restringen las opciones de diseo pero por razones de negocio, no por
razones tcnicas. Ejemplo: las licencias son muy costosas, nos vamos a una versin de cdigo abierto, hay
que desarrollar interfaz con el producto X que ya existe en la empresa. La mayora de las veces no son
negociables.
Atributos de calidad del producto: definen los requerimientos de la aplicacin. Los atributos de calidad
direccionan aspectos de inters para los usuarios de la aplicacin, como as tambin de otros involucrados.
Ejemplo: escalabilidad, disponibilidad, portabilidad, usabilidad, performance, etc.

Clasificacin completa de requerimientos no funcionales

Restricciones tcnicas
o De interoperatividad
o De implementacin
Restricciones de negocio
o De estndares
o De entrega
o ticos
o Legales
De producto
o Disponibilidad
o Performance
Concurrencia
Uso de recursos
Tiempo de respuesta
o Usabilidad
o Seguridad
Lgica

- 36 -

o
o
o

Fsica
Confiabilidad
Portabilidad
Interfaz
Hardware
Software
Comunicacin
Usuario

Atributos de calidad del producto (ISO9126)

Los atributos de calidad son parte de los requerimientos no funcionales de una aplicacin, que capturan muchas
facetas sobre como los requerimientos funcionales son llevados a cabo.
1. Performance (desempeo): establece en cuanto tiempo debe realizarse un trabajo. Hace referencia al
rendimiento, tiempo de respuesta y plazos (deadlines).
2. Escalabilidad: indica cuan preparado est el sistema para crecer sin perder la calidad y estabilidad en los
servicios que ofrece. Incluye solicitud de carga, conexiones simultneas, tamao de los datos, despliegue.
3. Modificabilidad: es una manera de medir que tan fcil es aplicar cambios en la aplicacin.
4. Seguridad: hace referencia a la autenticacin, autorizacin, encriptacin, integridad.
o Autenticacin: la aplicacin tiene que poder verificar la identidad de sus usuarios.
o Autorizacin: los usuarios y/o roles tienen ciertos privilegios.
o Encriptacin: los mensajes enviados son encriptados.
o Integridad: asegurar que el contenido de los mensajes no es alterado.
5. Disponibilidad: relacionado con la confiabilidad, que pueda ser usado cuando se lo necesite.
6. Integracin: que la aplicacin pueda ser incorporada en un contexto ms amplio.
7. Portabilidad: que una aplicacin pueda ser ejecutada en diferentes plataformas de hardware/software.
Depende de la tecnologa utilizada.
8. Testeabilidad (capacidad de prueba): que sea fcil de probar.

Modelado de la arquitectura

El modelo arquitectnico mapea los requerimientos funcionales del anlisis a una arquitectura tecnolgica.
Debe tratar con los requerimientos no funcionales.
No existe la solucin perfecta, el modelado arquitectnico debe escoger la solucin ptima para el
conjunto de circunstancias existentes.
Debe considerar informacin sobre:
o Volmenes de datos
o Funcionalidad ms demandada del negocio
o Distribucin geogrfica
o Distribucin de procesamiento de datos
o Dnde se guardarn los datos
o Cules procesos se ejecutarn en qu procesadores y que tanta comunicacin se requerir entre
ellos.

Salidas del modelo arquitectnico

Distribucin geogrfica de los requerimientos de computacin.

Componentes de hardware para las mquinas clientes y para los servidores.
Configuracin y cantidad de niveles de hardware.
Mecanismos y lenguajes de comunicacin de la red.
Sistema operativo.
Paradigma de desarrollo
Lenguaje de presentacin (front-end)
- 37 -

Lenguaje de fondo (back-end)

Sistema de administracin de base de datos
Ubicacin/es de los procesos
Ubicacin/es de los datos fsicos
Estrategias de sincronizacin de los datos distribuidos fsicamente

Eleccin del modelo arquitectnico y los requerimientos no funcionales

Aunque cada sistema es nico, los sistemas en el mismo dominio de aplicacin tienen normalmente arquitecturas
similares que reflejan los conceptos fundamentales del dominio. Cuando se disea una arquitectura de sistema,
debe decidirse que tienen en comn el sistema y las clases de aplicacin ms amplias, con la finalidad de determinar
cunto conocimiento se puede reutilizar de dichas arquitecturas de aplicacin.
La arquitectura de un sistema de software puede basarse en un patrn o en un estilo arquitectnico particular. Un
patrn arquitectnico es una descripcin de una organizacin del sistema. stos captan la esencia de una
arquitectura que se us en diferentes sistemas de software.
Debido a la estrecha relacin entre los requerimientos no funcionales y la arquitectura de software, el estilo y la
estructura arquitectnica particulares que se elijan para un sistema dependern de los requerimientos no
funcionales del sistema:

Desempeo (performance): si es un requerimiento crtico, esto sugiere que la arquitectura se debe disear
para localizar operaciones crticas dentro de un nmero reducido de subsistemas con poca comunicacin
(hasta donde sea posible) entre estos subsistemas, es decir, componentes de granulidad gruesa para reducir
componentes de comunicacin.
Seguridad: si es un requerimiento crtico, esto sugiere utilizar una estructura en capas para la arquitectura
con los recursos ms crticos protegidos con capas internas y un alto nivel de validacin aplicado a esas
capas.
Proteccin: si es un requerimiento crtico, sugiere que la arquitectura debe disearse para incluir
operaciones relacionadas con la proteccin se localicen en un solo subsistema o en un nmero reducido de
subsistemas. Esto reduce costos y problemas de validacin.
Disponibilidad: si es un requerimiento crtico, debe disearse una arquitectura que incluya componentes
redundantes de tal forma que puedan reemplazarse y actualizarse sin detener el sistema.
Mantenibilidad: si es un requerimiento crtico, la arquitectura debe disearse utilizando componentes
autocontenidos de granularidad fina que puedan cambiarse con facilidad. Los productores de datos
separados de los consumidores y las estructuras de datos compartidas deben evitarse.

Conflictos arquitectnicos

Utilizar componentes de granulidad alta mejora la performance pero reduce la mantenibilidad.

La introduccin de datos redundantes mejora la disponibilidad pero hace la seguridad ms difcil.
La localizacin de aspectos de seguridad relacionados usualmente significa ms comunicacin, por lo tanto
degrada la performance.

- 38 -

Proceso de arquitectura de software

1) Determinar los requerimientos arquitectnicos

Antes de que una solucin arquitectnica sea diseada, es necesario tener una buena idea de los requerimientos
para la arquitectura de la aplicacin. Los requerimientos arquitectnicos son esencialmente la calidad y los
requerimientos no funcionales de la aplicacin.
Identificar los requerimientos arquitectnicos
Se toman como entrada los requerimientos funcionales y los requerimientos de los involucrados (stakeholders).
Se determinan los requerimientos arquitectnicos, y se produce como salida un documento que contiene los
requerimientos arquitectnicos de la aplicacin.
Priorizar requerimientos
Los requerimientos se ubican en tres categoras:

Alto: la aplicacin debe soportar este requerimiento. Conducen el diseo de la arquitectura.

Medio: necesitar ser soportado en alguna etapa, pero no necesariamente en el primer release.
Bajo: estos requerimientos son parte de la lista de deseos. Las soluciones que los incluyen son deseables
pero no conducen el diseo.

2) Proceso de diseo arquitectnico

Eleccin del framework de la arquitectura
La mayora de las aplicaciones estn basadas en un pequeo
nmero de arquitecturas probadas. Hay una buena razn
para esto, funcionan. Utilizar estas soluciones ya probadas
hace que los riesgos se minimicen.
No hay una frmula mgica para disear un framework de
arquitectura. Un pre-requisito es conocer los patrones
arquitectnicos para abordar ciertos atributos de calidad.
Distribuir componentes
Una vez seleccionado el framework arquitectnico, basado en uno o ms patrones arquitectnicos, la siguiente
tarea es definir los componentes que comprendern el diseo.
Para ello se debe identificar:

Los componentes principales de la aplicacin.

Servicios o interfaces que cada componente soporta.
Responsabilidades del componente.
- 39 -

Dependencias entre componentes.

Particiones en la arquitectura que son candidatas para distribucin entre servidores de red.

Lineamientos para el diseo de componentes:

Minimizar dependencias entre componentes

o Recordar: si lo cambias, debes re-testearlo.
Disear componentes que encapsulen un conjunto de responsabilidades altamente cohesivas.
Aislar dependencias entre middleware y cualquier COT de infraestructura tecnolgica.
o Es ms fcil de construir, pero introduce penalidades de performance.
Utilizar la descomposicin para estructurar componentes jerrquicamente
Minimizar las llamadas entre componentes.

3) Validacin

Es probar la arquitectura.
Ayuda a incrementar la confianza del equipo de diseo en que la arquitectura cumpla su propsito.
Debe realizarse con las restricciones de tiempo y presupuesto del proyecto.
Es un desafo validar la arquitectura, ya que finalmente es un diseo y no puede ejecutarse ni probarse para
ver si cumple con los requerimientos.

Hay dos tcnicas principales para la validacin:

Uso de escenarios: consiste en un testeo manual de la arquitectura usando casos de prueba.

Prototipos: implica la construccin de un prototipo que crea un arquetipo simple de la aplicacin deseada.
Tiene la capacidad de evaluar los requerimientos en forma detallada. Los prototipos son versiones mnimas,
restringidas de la aplicacin creados especficamente para probar algn aspecto riguroso o pobremente
comprendido en el diseo. Son utilizados para dos propsitos:
o Prueba de conceptos.
o Prueba de tecnologa.

El objetivo de las dos tcnicas es identificar potenciales defectos y debilidades en el diseo para que puedan ser
mejoradas antes de la fase de implementacin.

Documentar la arquitectura
Para qu se usa?

Expresin del sistema y su evolucin.

Comunicacin entre los involucrados.
Evaluacin y comparacin de la arquitectura de una forma consistente.
Planificacin, administracin y ejecucin de las actividades del desarrollo del sistema.
Expresin de las caractersticas persistentes y soporte de los principios que guan un cambio aceptable.
Verificacin de la implementacin del sistema.

PATRONES ARQUITECTNICOS
Introduccin
Un patrn arquitectnico se puede considerar como una descripcin abstracta estilizada de buena prctica, que se
ensay y puso a prueba en diferentes sistemas y entornos. Un patrn arquitectnico debe describir una organizacin
de sistema que ha tenido xito en sistemas previos. Debe incluir informacin sobre cundo es y cundo no es
adecuado usar dicho patrn, as como las fortalezas y debilidades del patrn.
- 40 -

Existen patrones para distintos niveles de solucin:

Patrones de bajo nivel y detallados: idiomas (lenguajes de programacin).

Patrones de nivel medio: patrones de diseo (objetos comunes y patrones de clases).
Patrones de alto nivel: patrones arquitectnicos (componentes y mdulos).

Patrones arquitectnicos vs. Estilos arquitectnicos

Suele ser difcil distinguirlos. A veces se los ve como sinnimos.

Patrn: los patrones estn a una escala menor que los estilos. Mltiples patrones pueden aparecer en un
diseo.
Estilo: en contraste, un sistema usualmente, tiene un nico estilo arquitectnico dominante.

Platnicos vs. Embebidos

Platnicos: son patrones idealizados, los que se ven en los libros y rara vez de igual forma en el cdigo.
Embebidos: se los ve en sistemas reales y suelen violar las restricciones estrictas de los platnicos. Esta
violacin implica una gran compensacin.

Patrones
1.
2.
3.
4.
5.
6.
7.
8.
9.

Layered (estructura en capas).

Repositorio (o modelo centrado, Repository).
Modelo Vista Controlador (MVC, Model View Controller).
Publicar y Suscribir (Publish-Suscribe).
Messaging.
Tubera y Filtro (Pipe & Filter).
Lote-Secuencial (Batch-Sequential).
Agente (Broker).
Coordinador de Proceso (Process Coordinator).

Layered (capas o estratificado)

Consiste en una pila de capas, donde cada capa acta como una mquina virtual de
la capa de arriba.
En una forma de lograr la separacin y la independencia. Aqu, la funcionalidad del
sistema est organizada en capas separadas, y cada capa se apoya solo en las
facilidades y los servicios ofrecidos por la capa inmediatamente debajo de ella (las
capas solo pueden usar a las capas que se encuentran directamente debajo de ellas).
Calidad resultante: trata directamente los atributos de modificabilidad, portabilidad
y reusabilidad. Mientras su interfaz no vare, una capa puede sustituirse por otra
equivalente; o cuando las interfaces de capa cambian o se agregan nuevas
facilidades a una capa, slo resulta afectada la capa adyacente.
Variantes:

Algunas evitan la restriccin de modo que las capas puedan comunicarse con capas de ms abajo.
Otra variante es el uso de capas compartidas, donde cada capa puede usar estas capas verticales.

Notas: el estilo estratificado puede variar considerablemente en su forma platnica de su forma embebida. En la
prctica se pueden saltar capas hacia capas inferiores, lo cual provoca negar los atributos de calidad que son su
beneficio. Aun as es beneficiosa dado que las capas agrupan mdulos de funcionalidad coherente.

- 41 -

Descripcin
Cuando se usa
Ventajas
Desventajas

Organiza el sistema en capas con funcionalidad relacionada con cada capa. Una capa da
servicios a la capa de encima.
Se usa al construirse nuevas facilidades encima de los sistemas existentes, cuando el
desarrollo se dispersa a travs de varios equipos de trabajo, cuando existe un requerimiento
de capa multinivel.
Permite la sustitucin de capas completas (mientras se conserve la interfaz).
En la prctica suele ser difcil ofrecer una separacin limpia entre capas, donde posiblemente
una capa de nivel superior tenga que interactuar con capas del nivel inferior directamente. El
rendimiento suele ser un problema debido a los mltiples niveles.

Repositorio (modelo centrado)

Consiste en un conjunto de componentes independientes que interactan con un modelo central (llamado tambin
almacenamiento de datos o repositorio) en vez de interactuar unos con otros.
Est relacionado con el patrn MVC.
Calidad resultante: los sistemas repositorio son altamente modificables, debido a la independencia de los
componentes; son extensibles, ya que es muy fcil agregar componentes.

Descripcin

Cuando se usa

Ventajas

Desventajas

Todos los datos de un sistema se gestionan en un repositorio central, accesible a todos los
componentes del sistema. Los componentes no interactan directamente, sino tan slo a
travs del repositorio.
Se usa cuando se tiene un sistema donde los grandes volmenes de informacin generados
deban almacenarse durante mucho tiempo. Puede usarse tambin en sistemas dirigidos por
datos, en los que la inclusin de datos en el repositorio active alguna accin.
Los componentes pueden ser independientes, no necesitan conocer la existencia de otros
componentes. Los cambios hechos por un componente se pueden propagar hacia todos los
componentes. La totalidad de datos se puede gestionar de una manera consistente (todo est
en un solo lugar). Es extensible, se pueden agregar vistas y controladores ms tarde.
El repositorio es un punto de falla nico (los problemas en el repositorio afectan a todo el
sistema). Puede ser ineficiente la organizacin de la comunicacin a travs del repositorio.
Difcil de distribuir en forma eficiente.

MVC (Model View Controller)

Descripcin

Cuando se usa
Ventajas
Desventajas

Separa presentacin e interaccin de los datos del sistema. El sistema se estructura en tres
componentes lgicos que interactan entre s. El modelo maneja los datos del sistema y las
operaciones asociadas a esos datos. La vista define y gestiona como se presentaran los datos
al usuario (refleja el estado del modelo). El controlador dirige la interaccin del usuario y pasa
esas interacciones a vista y modelo (recibe peticiones de la vista sobre el modelo, interacciona
con el modelo, devuelve el resultado a la vista).
Se usa cundo existen mltiples formas de interactuar con los datos. Tambin se utiliza
cuando se desconocen los requerimientos futuros para la interaccin y presentacin.
Permite que los datos cambien de manera independiente de su representacin y viceversa.
Soporta diferentes representaciones de los mismos datos, y los cambios en una
representacin se muestra en todos ellos. Incrementa flexibilidad y reutilizacin.
Puede implicar cdigo adicional y complejidad de cdigo cundo el modelo de datos y las
interacciones son simples.

- 42 -

Publicar y Suscribir (Publish-Suscribe)

Consiste en componentes que publican eventos y otros se suscriben a ellos.
Los publicantes ignoran el motivo global por el cual el evento es publicado, los suscriptores ignoran porque o quien
publica el evento y dependen slo del evento, no de quin lo publica. A su vez, los publicantes son inconscientes del
consumo de los eventos.
Cada tpico puede tener ms de un publicante
y los publicantes pueden aparecer y
desaparecer dinmicamente, lo que le da
flexibilidad sobre configuraciones estticas.
Los suscriptores pueden suscribirse y dessuscribirse dinmicamente a un tpico.
Mensajera muchos a muchos: los mensajes publicados son enviados a todos los suscriptores que estn registrados
en el tpico. Muchos publicantes pueden publicar en el mismo tpico, y muchos suscriptores pueden escuchar en el
mismo tpico.
Los buses de eventos varan en las propiedades que soportan:

Durables: garantizan que cualquier mensaje que aceptan no se perder durante una falla (los eventos se
escriben en un almacenamiento confiable).
Entrega en orden: garantizan la entrega en orden o priorizada de eventos.
Entrega en lotes: los eventos se acumulan en lotes para evitar cmulos de eventos similares.

Descripcin
Cuando se usa

Ventajas

Desventajas

Componentes independientes publican eventos y otros se suscriben a ellos.

En arquitecturas muy flexibles y adecuadas para aplicaciones que requieren mensajes
asncronos uno-a-muchos, muchos-a-uno, muchos-a-muchos componentes.
No hay vnculo directo entre publicantes y suscriptores. Los publicantes no saben quin recibe
su mensaje, y los suscriptores no saben qu publicante enva el mensaje. Desacopla los
componentes que producen los eventos de quienes los consumen, haciendo que la
arquitectura sea mantenible y evolucionable.
El bus de eventos agrega una capa de indireccin entre productores y consumidores,
pudiendo afectar la performance del sistema.

Messaging
Esta arquitectura desacopla emisores de receptores utilizando una cola de mensajes intermedia.
El emisor enva un mensaje al receptor y sabe que eventualmente ser entregado, aunque la red est cada o el
receptor no est disponible.

Propiedades claves:

Comunicaciones asncronas: clientes envan pedidos a una cola, donde se almacenan hasta que una
aplicacin los remueve, luego el cliente contina sin esperar la respuesta.
Bajo acoplamiento: no hay vnculo directo entre emisores y receptores. El cliente es inconsciente de cual
servidor recibe el mensaje y, el servidor es inconsciente del cliente que enva el mensaje.
- 43 -

Descripcin
Cuando se usa

Ventajas
Desventajas

Emisores envan mensajes a receptores, donde los mensajes son almacenados en una cola.
Provee una solucin resistente para aplicaciones en las cuales la conectividad es transitoria,
tanto debido a la red como a la poca confiabilidad de los servidores.
Es apropiada cuando el cliente no necesita una respuesta inmediata despus de enviar el
mensaje.
Promueve el bajo acoplamiento, permitiendo alta modificabilidad, dado que emisores y
receptores no se conectan.
El bus de eventos agrega una capa de indireccin entre productores y consumidores,
pudiendo afectar la performance del sistema.

Tubera y filtro (Pipe & Filter)

Los datos fluyen de un componente a otro (filtros), a travs de una tubera, y se transforman conforme se desplazan
en la secuencia. Cada paso de procesamiento se implementa como un transformador. Los datos de entrada fluyen
por medio de dichos transformadores hasta que se convierten en salida.
Una caracterstica clave es que toda la red de tuberas est continua e incrementalmente procesando datos.

Descripcin

Cuando se usa

Ventajas

Desventajas

Los datos fluyen (como en una tubera) de un componente a otro para su procesamiento. El
procesamiento de datos se organiza de forma que cada componente de procesamiento
(filtro) sea discreto y realice un tipo de transformacin de datos.
Se suele utilizar en aplicaciones de procesamiento de datos (ya sean Batch en lotes- o en
transacciones), donde las entradas se procesan en etapas separadas para generar salidas
relacionadas.
Es fcil de entender y soporta reutilizacin de transformacin. El estilo de flujo de trabajo
coincide con la estructura de muchos procesos empresariales. La evolucin al agregar
transformaciones es directa. Puede implementarse como sistema secuencial o como uno
concurrente.
El formato para transferencia de datos debe acordarse entre las transformaciones que se
comunican. Cada transformacin debe analizar sus entradas y sintetizar sus salidas al formato
acordado. Esto aumenta la carga del sistema y dificulta la reutilizacin de transformaciones
funcionales que usen estructuras de datos compatibles. Son inapropiadas para aplicaciones
interactivas.

Lote-Secuencial (Batch-Sequential)
Los datos fluyen de una etapa a otra y es procesado incrementalmente.
A diferencia del Pipe & Filter, cada etapa completa todo su procesamiento antes de escribir su salida.
Los datos fluyen entre etapas en una cadena, pero es ms comn escribir en un archivo o disco.

- 44 -

Tiene restricciones similares al Pipe & Filter:

Cada etapa o paso es independiente y depende de los datos que toma, no de la etapa anterior.
Las etapas no interactan entre s excepto a travs de la cadenas de entradas o salidas de archivos.
Es una serie de pasos lineales.
No se hace trabajo en los conectores, salvo el paso de datos.

Descripcin
Ventajas
Desventajas

Los datos fluyen de una etapa a otra y es procesado incrementalmente.

Alta modificabilidad, ya que cada etapa es independiente de las otras. Buen rendimiento.
Conceptualmente simple dado que una etapa est ejecutndose por vez.
La salida final est completamente terminada o ausente, lo que impacta en la usabilidad del
sistema (a diferencia del Pipe & Filter). No se puede ejecutar trabajo en paralelo a menos que
fluyan mltiples trabajos a travs del sistema.

Agente (Broker)
Propiedades clave del patrn:

Arquitectura Hub-and-spoke: el agente acta como concentrador de mensajes y los remitentes y receptores
se conectan como rayos. Las conexiones al agente son por medio de puertos asociados a un formato
especfico de mensaje.
Realiza ruteo de mensajes: el agente incrusta la lgica de procesamiento para entregar un mensaje recibido
en un puerto de entrada en el puerto de salida.
Realizar transformacin de mensajes: el agente lgico transforma el tipo de mensaje de origen recibido en
el puerto de entrada en el tipo de mensaje de destino requerido por el puerto de salida.

Cuando se usa
Ventajas

Son adecuados para aplicaciones en las cuales los componentes intercambian mensajes que
requieren grandes transformaciones entre los formatos de origen y destino.
El agente desacopla el remitente del receptor, permitindoles producir o consumir su formato
nativo, y centraliza la definicin de la transformacin lgica en el agente para facilitar la
comprensin y modificacin.

Coordinador de procesos (Process Coordintator)

Propiedades clave del patrn:

Encapsulamiento de proceso: el coordinador de proceso encapsula la secuencia de pasos necesarios para

completar un proceso de negocio. Recibe un requerimiento de inicio de proceso, llama a los servidores en
el orden definido por el proceso y emite los resultados.
- 45 -

Bajo acoplamiento: los componentes del servidor son inconscientes de su rol en el proceso de negocio
general, y del orden de los pasos del proceso. Los servidores simplemente definen un conjunto de servicios
que pueden ejecutar y el coordinador los llama cuando es necesario.
Comunicaciones flexibles: las comunicaciones entre el coordinador y los servidores pueden ser sincrnicas
o asincrnicas. Para las comunicaciones sincrnicas, el coordinador espera hasta que el servidor responda.
Para las comunicaciones asincrnicas, el coordinador provee una llamada o respuesta cola/tpico, y espera
hasta que el servidor responde utilizando el mecanismo definido.

Cuando se usa
Ventajas

Es utilizado comnmente para implementar procesos de negocio complejos que deben

publicar requerimientos a algunos componentes servidores diferentes.
Encapsulando la lgica de proceso en un lugar, es ms fcil cambiar, administrar y monitorear
la performance del proceso.

ARQUITECTURA DE SISTEMAS DISTRIBUIDOS

Tipos de sistemas

Sistemas personales: no son distribuidos y han sido diseados para ejecutarse en una computadora personal
o estacin de trabajo.
Sistemas embebidos: se ejecutan en un nico procesador o en un grupo integrado de procesadores.
Sistemas distribuidos: el sistema de software se ejecuta en un grupo de procesadores cooperativos
integrado conectados por una red.

Introduccin
Prcticamente todos los sistemas basados en computadoras son ahora sistemas distribuidos. Un sistema distribuido
es aquel que implica numerosas computadoras, en contraste con los sistemas centralizados en que todos los
componentes del sistema se ejecutan en una sola computadora. Es una coleccin de computadoras independientes
que aparecen al usuario como un solo sistema coherente.
Un sistema distribuido debe ser transparente. Esto significa que los usuarios ven el sistema como un solo sistema
cuyo comportamiento no resulta afectado por la forma en que se distribuye el sistema. En la prctica, es imposible
hacer un sistema por completo transparente (demoras en la red, fallas del nodo remoto, etc.).

Caractersticas de los sistemas distribuidos

1. Comparticin de recursos: permiten compartir recursos de hardware y software a travs de una red.
2. Apertura: son abiertos, lo que significa que se disean sobre protocolos estndares que combinan software
y equipos de diferentes vendedores.
3. Concurrencia: varios procesos pueden estn operando al mismo tiempo sobre diferentes computadoras de
la red.

- 46 -

4. Tolerancia a fallas: la disponibilidad de muchas computadoras y el potencial de reproducir informacin

significa que los sistemas distribuidos pueden tolerar fallas de hardware y software.
5. Escalabilidad: los sistemas pueden crecer incrementando recursos para cubrir nuevas demandas. La
escalabilidad de un sistema refleja su disponibilidad para entregar una alta calidad de servicio conforme
aumentan las demandas del sistema. Hay tres dimensiones de escalabilidad:
o Tamao: debe ser posible agregar ms recursos.
o Distribucin: dispersar los recursos sin reducir su rendimiento.
o Manejabilidad: debe poder administrarse un sistema conforme aumenta su tamao, incluso si
partes del sistema se ubican en organizaciones diferentes.

Desventajas de los sistemas distribuidos

1. Complejidad: son ms difciles de comprender y probar.
2. Seguridad: dificulta asegurar la integridad y la degradacin del servicio.
3. Manejabilidad: los defectos pueden propagarse de una mquina a otra, lo que implica que es ms difcil de
gestionar y administrar.
4. Impredecibilidad: la respuesta depende de la carga total del sistema, de la organizacin y de la red.

Ataques de los que deben defenderse los sistemas distribuidos

1. Intercepcin: un atacante intercepta comunicaciones entre partes del sistema, provocando que haya poca
confidencialidad.
2. Interrupcin: los servicios son atacados y no pueden entregarse como se esperaba. Se bombardea al servicio
con peticiones ilegitimas para que no pueda atender las legtimas.
3. Modificacin: el atacante cambia los datos o el servicio del sistema.
4. Fabricacin: el atacante genera informacin que no debe existir y luego la usa para conseguir ciertos
privilegios. Adems, hace que el sistema maneje informacin poco confiable o fuera de la realidad.

Modelos de interaccin en sistemas distribuidos

Interaccin procedimental: una computadora solicita un servicio conocido a otra computadora y espera que
la otra computadora le responda. Sincrnico.
Interaccin basada en mensajes: la computadora emisora define en un mensaje la informacin y lo enva a
otra computadora. No es necesario esperar la respuesta. Normalmente se implementa con un componente
que crea un mensaje, el cual detalle los servicios requeridos por otro componente. Asincrnico.

Middleware
Es el software que permite gestionar y garantizar que las diversas partes de un sistema distribuido puedan
comunicarse e intercambiar datos.
Se llama middleware porque se encuentra en el centro de las partes del sistema distribuido.
Por lo general, se implementa como un conjunto de libreras, que se instala en cada computadora distribuida.
El middleware es software de propsito general (enlatado) que se consigue, en lugar de que los desarrolladores de
aplicacin los escriban especialmente.
Ejemplos: comunicacin con bases de datos, gestores de transacciones, convertidores de datos y controladores de
comunicacin.
En un sistema distribuido brinda dos tipos de soporte:

Soporte de interaccin: el middleware coordina las interacciones entre diferentes componentes del sistema.
- 47 -

Provisin de servicios comunes: el middleware proporciona implementaciones de reutilizacin de servicios

que pueden requerir varios componentes en el sistema distribuido.

Patrones arquitectnicos para sistemas distribuidos

Los diseadores de sistemas distribuidos deben organizar sus diseos de sistema para encontrar un equilibrio entre
rendimiento, confiabilidad, seguridad y manejabilidad del sistema. Cuando se disea una aplicacin distribuida, se
deber elegir un estilo arquitectnico que soporte los requerimientos no funcionales crticos del sistema. Cinco
estilos arquitectnicos de sistemas distribuidos:
1. Arquitectura maestro-esclavo (master-slave)
2. Arquitectura cliente-servidor
a. De dos niveles
b. Multinivel
3. Arquitectura de componentes distribuidos
4. Arquitectura Peer-to-peer
5. Arquitectura Map-Reduce

Arquitectura Maestro-Esclavo (Master-Slave)

Se usan en sistemas de tiempo real donde es importante cumplir con los tiempos de procesamiento, donde puede
haber procesadores separados para la adquisicin de datos del entorno del sistema, procesamiento de datos y
actuador de gestin.
El proceso maestro es el responsable de la computacin, coordinacin, comunicacin y control de los procesos
esclavos. Los procesos esclavos se dedican a acciones especficas, como adquisicin de datos de sensores.
Se usa cuando es posible predecir el procesamiento distribuido que se requiere y cuando se puede asignar fcilmente
el procesamiento a los procesadores esclavos. Esta situacin es comn en los sistemas de tiempo real.

Arquitecturas cliente-servidor
La aplicacin es modelada como un conjunto de servicios que son
provistos por servidores y un conjunto de clientes que usan esos
servicios. Los clientes piden servicios a los servidores.
Los clientes conocen los servicios y deben saber cmo buscarlos, pero
los servidores no necesitan conocer a los clientes.
Los que inician la comunicacin son los clientes. Los servidores no
conocen la identidad de los clientes hasta que se han contactado.
Los servidores se pueden replicar, esto es til cuando la carga de un sistema es variable.
- 48 -

Si bien es una arquitectura distribuida, puede implementarse tambin en una sola computadora.
Los sistemas clientes-servidor dependen de que exista una clara separacin entre la presentacin de la informacin
y los clculos que crea y procesa esa informacin. En consecuencia, se debe disear la arquitectura de los sistemas
distribuidos cliente-servidor para que se estructuren en varias capas lgicas, con interfaces claras entre dichas capas.
Esto permite que cada capa se distribuya en diferentes computadoras.
Variantes:

Los conectores pueden ser sincrnicos o asincrnicos.

Puede haber lmites en el nmero de clientes y servidores.
Las conexiones pueden ser con o sin estado (sesiones).
Las topologas del sistema pueden ser esttica o dinmica.

Arquitectura cliente-servidor de dos niveles

Es la forma ms simple de la arquitectura cliente servidor. El sistema se implementa en un solo servidor ms un
nmero indefinido de clientes que usan dicho servidor.

Modelo cliente ligero: la capa de presentacin se implementa en el cliente, y todas las otras capas (de
procesamiento, gestin de datos, etc.) se implementan en el servidor. Puede ser un programa de escritorio,
pero es ms comn usar un navegador web.
La ventaja del cliente ligero consiste en que es simple de manejar por los clientes. Puede ser costoso instalar
y difcil instalar un software en cada uno de ellos si existe un nmero considerable de clientes. La solucin
es utilizar un navegador web, haciendo que no sea necesario instalar el software cliente.
La desventaja de este enfoque es que se puede provocar una fuerte carga de procesamiento en el servidor
como en la red, ya que el servidor realiza toda la computacin.
Modelo cliente pesado: parte o todo el procesamiento de la aplicacin se realiza en el cliente. Utiliza el
poder de procesamiento disponible en la mquina cliente. Las funciones de gestin de datos y base de datos
se implementan en el servidor.
La ventaja es que se distribuye el procesamiento, aliviando la carga de procesamiento del servidor y de la
red.
La desventaja es que requiere gestin de sistema adicional para implementar y mantener el software en la
computadora del cliente. Una nueva versin debe ser instalada en todos los clientes.

El problema fundamental de este enfoque, es que las capas lgicas del sistema deben mapearse en dos sistemas de
cmputo: el cliente y el servidor. Esto puede producir problemas con la escalabilidad y rendimiento si se elige el
modelo de cliente ligero, o problemas de gestin de sistema si se usa el modelo de cliente pesado. Para ello se utiliza
una arquitectura C/S multinivel.
Arquitectura cliente-servidor multinivel
En esta arquitectura, las diferentes capas del sistema (presentacin, gestin de datos, procesamiento de aplicacin
y base de datos) son procesos separados que pueden ejecutarse en diferentes procesadores.
El modelo cliente-servidor de tres niveles puede extenderse a una variante multinivel, donde se agregan servidores
adicionales al sistema. Esto podra implicar el uso de un servidor web para gestin de datos y servidores separados
para procesamiento de aplicacin (lgica de negocio) y servicios de bases de datos.
Los sistemas cliente-servidor multinivel que distribuyen el procesamiento de aplicacin a travs de varios servidores
son inherentemente ms escalables que las arquitecturas de dos niveles.
Arquitectura cliente-servidor N-Tier
Propiedades clave:
- 49 -

Separacin de intereses: capas diferentes y claramente divididas para presentacin, negocios y manejo de
datos.
Comunicaciones sincrnicas: la comunicacin entre niveles es pedido-respuesta sincrnica. Las peticiones
emanan en una nica direccin: del nivel de cliente a los niveles web y de la lgica de negocio al nivel EIS.
Cada nivel espera la respuesta del otro nivel antes de proseguir.
Distribucin flexible: no hay restricciones para la distribucin multi capas de la aplicacin. En aplicaciones
web, el cliente usualmente corre en un browser de una PC, comunicndose remotamente con internet con
componentes a nivel web.

Calidad resultante:

Mejora la mantenibilidad: soporta cambios en las reglas de negocio cambiando el servidor, en lugar de
hacerlo en mltiples clientes.
Puede enmascarar sistemas legados y tratarlos como servidores.

Arquitectura de componentes distribuidos

Consiste en disear el sistema como un conjunto de servicios, sin tratar de asignar dichos servicios a capas en el
sistema. Cada servicio, o grupo de servicios relacionados, se implementa usando un componente separado. El
sistema est organizado como un conjunto de componentes u objetos en interaccin, que proporcionan una interfaz
a un conjunto de servicios que ofrecen. Otros componentes solicitan dichos servicios a travs de middleware.
Estos sistemas dependen del middleware que gestiona las interacciones entre los componentes. Ejemplo de
middleware: CORBA.
Ventajas:

Permite al diseador del sistema demorar las decisiones acerca de dnde y cmo deben proporcionarse los
servicios.
Permite adicionar nuevos recursos segn se requiera.
El sistema es flexible y escalable.
Es posible reconfigurar dinmicamente el sistema con componentes que migran a travs de la red.

Desventajas:

Son ms complejos de disear que los sistemas cliente-servidor.

El middleware estandarizado para sistemas de componentes distribuidos nunca se ha aceptado en la
comunidad. Ejemplo: Microsoft y Sun han desarrollado middleware diferentes e incompatibles.

Arquitectura Peer-to-Peer (P2P)

Los sistemas entre pares (peer-to-peer, p2p) son sistemas descentralizados en los que los clculos pueden realizarse
en cualquier nodo de la red. No se hacen distinciones entre clientes y servidores. En este tipo de sistemas, el sistema
global est diseado para sacar ventaja del poder computacional y de almacenamiento disponible en una red de
computadoras potencialmente enorme. Aqu cada nodo, tiene la habilidad (no la obligacin) de comportarse como
cliente o como servidor. El resultado es un conjunto de nodos operando como pares donde cada nodo puede pedir
o proveer servicios a cualquier otro nodo de la red.
Calidad resultante:

Disponibilidad promovida por el acceso a un archivo o parte de l desde cualquier nodo.

Es altamente escalable y extensible.
Aprovechan capacidad de procesamiento no utilizada de computadoras locales.

- 50 -

Desventajas:

Muchos nodos pueden procesar la misma bsqueda.

Excesiva carga de trabajo al replicar comunicaciones entre pares.
Preocupaciones por la seguridad y la confianza.

Cuando se usa:

Donde el sistema es de cmputo intensivo y es posible separar el procesamiento requerido en un gran

nmero de clculos independientes.
Donde el sistema implica el intercambio de informacin entre computadoras individuales en una red y no
hay necesidad de que esta informacin se almacene o gestione de manera centralizada.

Arquitectura Map-Reduce

Apropiado para el procesamiento de grandes conjuntos de datos, tales como los motores de bsqueda de
internet o las redes sociales.
Conceptualmente, simples programas deben ejecutar poco a poco grandes conjuntos de datos como si se
hubiera utilizado una sola computadora.
Este estilo permite la computacin extendida entre mltiples computadoras. Dado que el riesgo de falla
incrementa con la cantidad de computadoras utilizadas, este estilo permite recuperacin frente a fallas.
Los grandes conjuntos de datos se dividen en conjuntos ms pequeos y son almacenados en un sistema de
ficheros global. Uno o ms de estos conjuntos de datos son procesados por un map worker produciendo
resultados intermedios almacenados en sistemas de archivos locales.
Los desarrolladores solo necesitan razonar sobre la correccin de cmo cada mquina procesa un nico
fragmento de datos.
Se realiza mucho procesamiento paralelo que es transparente para el desarrollador.
Solo debe asegurarse que cada trabajador (map o reduce) implemente su funcin correctamente.
Debe distribuirse los fragmentos equitativamente dado que la performance general del sistema se degrada
si algn map worker se demora ms que los otros.
Un reduce worker lee los resultados de los ficheros locales, los combina para producir el resultado final y
almacenarlo en el sistema de fichero global.

Calidad resultante:

Escalabilidad: si el programa se escribi para este estilo puede correr en un clster de una o mil mquinas.
Disponibilidad: se recupera de fallas re-agendando el trabajo a otra mquina.
Performance: tareas pueden distribuirse en varias mquinas.

Arquitecturas de la vista de distribucin

1. Arquitectura Espejada (Mirrored).
2. Arquitectura Rack.
3. Arquitectura Granja de Servidores (Farm).

Arquitectura Mirrored

En este estilo se duplica hardware idntico, que corre en paralelo.

Generalmente opera en lock-step, lo que duplica el esfuerzo, pero si uno falla el otro puede continuar por
su cuenta. Realiza la misma operacin varias veces en paralelo.
El software puede actualizarse en forma separada uno de otro.
La disponibilidad aumenta porque la probabilidad de que ambas fallen simultneamente es baja.

- 51 -

Arquitectura Rack

En este estilo los servidores se acomodan en pilas, para utilizar menos espacio del piso.
Todas las computadoras de la pila se conectan con la misma red.
La red en cambio puede tener varias conexiones a internet.
La conexin a red para el rack es a menudo ms rpida o la restriccin de ancho de banda es menor, por lo
que la comunicacin entre computadoras de mismo rack es mucho ms rpida.

Arquitectura granja de servidores (Farm)

En este estilo muchas computadoras (usualmente idnticas) son ubicadas en la misma habitacin (granja).
La interconexin de las computadoras puede variar y la granja puede componerse de varios racks.
Se las piensa como un recurso masivo que puede alojar cualquier aplicacin.
Es fcilmente escalable agregando ms hardware del mismo tipo.
Usos comunes para las granjas: capa de interfaz de usuario y capa intermedia de un sistema de tres capas
donde cada granja aloja una capa diferente.

ARQUITECTURA ORIENTADA A SERVICIOS

Introduccin
Basadas en la nocin de servicio Web.
Al usar un servicio web, las organizaciones que quieran hacer accesible su informacin para otros programas pueden
lograrlo al definir y publicar una interfaz de servicio web.

Servicio: una accin ofrecida por una parte a otra. Aunque el proceso puede ser atado a un producto fsico,
la performance es esencialmente intangible y normalmente no resulta en posesin de alguno de los factores
de produccin.
Servicio web: es un enfoque estndar para hacer un componente reusable, disponible y accesible a travs
de la web.

La particularidad de un servicio es que el hecho de proveer el servicio es independiente de la aplicacin que usa el
servicio.
Las arquitecturas orientadas a servicios (SOA, Service Oriented Architecures) son una forma de desarrollar sistemas
distribuidos en la que los componentes del sistema son servicios independientes y se ejecutan en computadoras
distribuidas geogrficamente. Los servicios son independientes de la plataforma y del lenguaje de implementacin.
Los sistemas de software pueden componerse de servicios locales y servicios externos de diferentes proveedores
con interaccin uniforme con los servicios del sistema.

Estndares
Los servicios estn basados en estndares XML, acordados tal que pueden ser provistos en cualquier plataforma y
escritos en cualquier lenguaje de programacin. Estndares claves:

SOAP (Simple Objetc Access Protocol): estndar de intercambio de mensajes que soporta la comunicacin
entre servicios. Es un protocolo estndar que define cmo dos objetos en diferentes procesos pueden
comunicarse por medio de intercambio de datos XML.
WSDL (Web Service Definition Language): estndar para la definicin de interfaz de servicio. Establece como
deben definirse las operaciones de servicios y los enlaces de servicio. WSDL describe la interfaz pblica a los
servicios Web (operaciones y parmetros). Est basado en XML y describe la forma de comunicacin, es
decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios
- 52 -

listados en su catlogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan despus
al protocolo concreto de red y al formato del mensaje.
WW-BPEL: estndar para un lenguaje de flujo de trabajo que se usa para definir programas de proceso que
implican varios servicios diferentes.
UDDI (Universal Description Discovery and Integration): define los componentes de una especificacin de
servicio, que puede usarse para descubrir la existencia de un servicio. Desplazado por los motores de
bsqueda.

Construir aplicaciones con base en servicios permite a las compaas y otras organizaciones cooperar y usar de
manera mutua las funciones empresariales.

Ingeniera de servicio
La ingeniera de servicio es el proceso de desarrollo de servicios para reutilizacin en aplicaciones orientadas a
servicios. Los ingenieros de servicios deben garantizar que el servicio represente una abstraccin de reutilizacin
que podra ser til en diferentes sistemas. Deben documentar el servicio de modo que puedan descubrir y
comprender los usuarios potenciales.
Existen tres etapas lgicas en el proceso de ingeniera de servicio:
1. Identificacin de candidatos a servicio: se identifican los posibles servicios que se podran implementar y
se definen los requerimientos del servicio.
2. Diseo del servicio: se disean las interfaces lgica y de servicio WSDL.
3. Implementacin y despliegue del servicio: se implementa el servicio, se prueba y se pone a disposicin del
usuario.

Identificacin de candidatos a servicio

La identificacin de candidatos a servicio, implica comprender y analizar los procesos empresariales de la
organizacin para decidir cules servicios de reutilizacin podran implementarse para soportar dichos procesos.
Hay tres tipos de servicios fundamentales que pueden identificarse:

Servicios utilitarios: se trata de servicios que implementan alguna funcionalidad general que pueden usar
diferentes procesos empresariales (por ejemplo la conversin de divisas).
Servicios empresariales: se trata de servicios asociados con una funcin empresarial especfica (por ejemplo
la inscripcin de un estudiante a un curso).
Servicios de coordinacin o proceso: se trata de servicios que soportan un proceso empresarial ms general
que por lo general implican diferentes actores y actividades (por ejemplo la gestin de pedidos, donde
participan proveedores, bienes y pagos realizados.

Los servicios pueden considerarse orientados a tareas u orientados a entidades.

Servicios orientados a tareas: servicios asociados con una actividad

Servicios orientados a entidades: son como objetos. Se asocian a una entidad empresarial.

Los servicios utilitarios o empresariales pueden orientarse a entidades o a actividades, pero los servicios de
coordinacin siempre son orientados a tareas.
No hay frmulas mgicas para decidir cules son los mejores servicios y, por lo tanto, la identificacin de servicios
es un proceso basado en habilidad y experiencia.

- 53 -

Diseo de interfaces de servicio

Esto implica definir operaciones asociadas con el servicio y sus parmetros. Su meta consiste en minimizar el nmero
de intercambios de mensajes que deben tener lugar para completar la peticin.
Tambin hay que recordar que los servicios no tienen estado y que la gestin del estado de la aplicacin especfica
del servicio es responsabilidad del usuario del servicio, y no del servicio en s. Existen tres etapas en el diseo de
interfaz de servicio:

Diseo de interfaz lgica: identifican las operaciones asociadas al servicio, sus entradas y salidas y sus
excepciones.
Diseo de mensajes: se disea la estructura de los mensajes que enva y recibe el servicio.
Desarrollo WSDL: el diseo lgico y de mensajes se traducen a una descripcin de interfaz abstracta escrita
en WSDL.

Implementacin y despliegue del servicio

Puede implicar la programacin del servicio usando un lenguaje de programacin estndar como Java o C#.
Una vez implementado un servicio, tiene que probarse antes de desplegarse. Se tratan de generar excepciones
durante la prueba para comprobar que el servicio puede hacer frente a entradas invlidas.
El despliegue del servicio, la etapa final del proceso, implica poner a disposicin el servicio para su uso en un servidor
Web.

Servicios de sistemas heredados

Los sistemas heredados son sistemas de software antiguos que emplea una organizacin. Dependen de tecnologa
obsoleta, pero todava son esenciales para la empresa. Tal vez no sea efectivo en trminos de costo reescribir o
sustituir dichos sistemas, y muchas organizaciones quisieran usarlos en conjuncin con sistemas ms modernos.
Uno de los usos ms importantes de los servicios es implementar envolturas (wrappers) para sistemas heredados
que brinden acceso a las funciones y datos de un sistema. Entonces se puede acceder a dichos sistemas a travs de
la web e integrarlos con otras aplicaciones.

VISTAS ARQUITECTNICAS

- 54 -

Vista: las vistas son representaciones del sistema de acuerdo a una perspectiva. El interesado ve lo que
necesita/quiere ver y se oculta la dems informacin. Las vistas se utilizan para representar la arquitectura con el
uso de UML 2.0.

Tipos de vistas

Vista de mdulo: contiene vistas de los elementos que se pueden ver en tiempo de compilacin. Vista
esttica de cmo organizamos el cdigo. Definiciones de tipos de componentes, puertos y conectores, clases
e interfaces.
o Patrn Layered
Vista de ejecucin: contiene vistas de los elementos que se pueden ver en tiempo de ejecucin. Incluye
escenarios de funcionalidad, listas de responsabilidad y ensambles de componentes. Instancias de
componentes, conectores y puertos.
o Patrn Publish-Suscribe
o Patrn Broker
o Patrn Messaging
o Patrn Process Coordinator
o Patrn N-Tier
o Patrn Pipe & Filter
o Patrn Batch-Sequential
o Patrn Modelo Repositorio
o Patrn MVC
o Patrn Peer-to-Peer
o Patrn Map-Reduce
Vista de distribucin: contiene vistas de elementos relacionados con la distribucin del software en el
hardware.
o Patrn N-Tier
o Patrn Map-Reduce
o Mirrored, Farm (granja) y Rack
Vista de spanning: contiene cuestiones de confiabilidad, seguridad, performance, etc.

Los tipos componentes existen en el tipo de vista de mdulo y las instancias de componentes (objetos) existen en la
vista de ejecucin, tal como ocurre con las clases y objetos.
Proveer vistas separadas ayuda a comprender cada asunto en forma aislada, pero tambin es necesario comprender
la arquitectura como un todo.

Vistas en el Proceso Unificado de Desarrollo (PUD)

- 55 -

No todos los sistemas requieren todas las vistas. Por ejemplo:

Un solo procesador: saltear la vista de despliegue.

Procesos simples: saltear la vista de procesos.
Programas muy pequeos: saltear la vista de implementacin.

Tambin se pueden agregar otras vistas como: vista de los datos, vista de seguridad.

REUTILIZACIN DE SOFTWARE
Introduccin
La ingeniera de software basada en la reutilizacin es una estrategia en la que se engrana el proceso de desarrollo
para reutilizar el software existente.
El movimiento hacia el desarrollo basado en la reutilizacin fue en respuesta a las demandas para reducir los costos
de produccin y mantenimiento del software, entregar los sistemas con mayor rapidez y aumentar la calidad del
software.
La disponibilidad de software reutilizable aument drsticamente. Se dispone de una enorme base de cdigo de
reutilizacin a bajo costo. Esto puede ser en la forma de libreras de programas o aplicaciones completas. Los
estndares, como los estndares de servicios web, han facilitado el desarrollo de servicios generales y su reutilizacin
a travs de varias aplicaciones.
Las unidades de software que se reutilizan pueden ser de tamaos sustancialmente diferentes:

Reutilizacin del sistema de aplicacin: todo un sistema de aplicacin puede reutilizarse al incorporarlo sin
cambios en otros sistemas o al configurar la aplicacin para diferentes clientes.
Reutilizacin de componentes: los componentes de una aplicacin (desde subsistemas a objetos
individuales) pueden reutilizarse.
Reutilizacin de objetos y funciones: pueden reutilizarse los componentes de software que implementan
una sola funcin, tal como una funcin matemtica o una clase de objeto. Muchas libreras de funciones y
clases estn disponibles gratuitamente. Este enfoque es particularmente efectivo en reas como algoritmos
matemticos y grficas, donde se necesita experiencia especializada para desarrollar objetos y funciones
eficientes.

Una forma complementaria de reutilizacin es la reutilizacin de concepto en la que, en vez de reutilizar un

componente de software, se reutiliza una idea, una va, un funcionamiento o un algoritmo. El concepto que se
reutiliza se representa en una notacin abstracta, que no incluye detalles de implementacin. Por lo tanto, puede
adaptarse y configurarse para varias situaciones.
Una ventaja evidente de la reutilizacin de software es que deberan reducirse los costos totales de desarrollo. No
obstante, existen costos y problemas asociados con la reutilizacin. Hay un costo significativo asociado con entender
si un componente es adecuado o no para su reutilizacin en una situacin particular, y probar dicho componente
para garantizar su confiabilidad.
En particular, debe haber una etapa de correccin de requerimientos en la que se modifiquen los requerimientos
del sistema para reflejar el software de reutilizacin disponible.
La reutilizacin de software es ms efectiva cuando se planea como parte de un programa de reutilizacin de toda
la organizacin.

- 56 -

Ventajas de la reutilizacin

Confiabilidad creciente: el software de reutilizacin, que se experiment y ensay en sistemas operativos,

debe ser ms confiable que el software nuevo.
Reduccin de riesgo de proceso: se conoce ya el costo del software existente, mientras que el de desarrollo
siempre es una cuestin de juicio.
Uso efectivo de especialistas: en lugar de hacer el mismo trabajo una y otra vez, los especialistas de
aplicacin pueden desarrollar software de reutilizacin que encapsule conocimientos.
Cumplimiento de estndares: algunos estndares como los de interfaz de usuario, pueden implementarse
como un conjunto de componentes de reutilizacin.
Desarrollo acelerado: la reutilizacin de software puede acelerar la produccin del sistema, ya que pueden
reducirse los tiempos de desarrollo y validacin.

Desventajas de la reutilizacin

Costos crecientes de mantenimiento: si no est disponible el cdigo fuente de un sistema o componente

de software de reutilizacin, entonces los costos de mantenimiento podran ser superiores, porque los
elementos reutilizados del sistema pueden volverse cada vez ms incompatibles con los cambios del
sistema.
Falta de apoyo de herramientas: algunas herramientas de software no apoyan el desarrollo con
reutilizacin. Tal vez sea difcil o imposible integrar dichas herramientas con un sistema de librera de
componentes.
Sndrome de no se invent aqu: algunos ingenieros de software prefieren rescribir los componentes,
porque consideran que pueden mejorarlos. Escribir software original se observa como ms desafiante que
reutilizar el software de alguien ms.
Creacin, mantenimiento y uso de una librera de componentes: hay que adaptar procesos de desarrollo
para asegurar que se use la librera.
Descubrimiento, comprensin y adaptacin de componentes de reutilizacin: deben descubrirse
componentes de software en una librera, entenderse y, en ocasiones, adaptarse para trabajar en un nuevo
entorno.

Panorama de la reutilizacin
Durante los ltimos 20 aos, se han desarrollado muchas tcnicas para apoyar la reutilizacin de software. Dichas
tcnicas aprovechan el hecho de que los sistemas en el mismo dominio de aplicacin son similares y tienen potencial
de reutilizacin.
Los factores clave que deben considerarse al planear la reutilizacin son:
1. El calendario de desarrollo para el software: si el software debe desarrollarse rpidamente, se debe tratar
de reutilizar sistemas comerciales en vez de componentes individuales.
2. La vida esperada del software: para un sistema de prolongada duracin, hay que enfocarse en la capacidad
de mantenimiento del sistema.
Durante su vida til, se podr adaptar el sistema a nuevos requerimientos, lo que significar hacer cambios
a partes del sistema. Si no se tiene acceso al cdigo fuente, es preferible evitar los componentes COTS y los
sistemas de proveedores externos.
3. Los antecedentes, las habilidades y la experiencia del equipo de desarrollo: todas las tecnologas de
reutilizacin son bastante complejas, y es necesario mucho tiempo para entenderlas y usarlas de manera
efectiva.
4. La criticidad del software y sus requerimientos no funcionales: para un sistema crtico que deba certificarse
mediante un regulador externo, quiz se deba crear un caso de confiabilidad para el sistema. Eso es difcil si
no se tiene acceso al cdigo fuente del software.
- 57 -

5. El dominio de la aplicacin: en algunos dominios de aplicacin existen muchos productos genricos que
pueden reutilizarse al configurarlos para una situacin local.
6. La plataforma en la que operar el sistema: sistemas genricos de aplicacin pueden ser especificados de
plataforma y slo podrn reutilizarse si el sistema est diseado para la misma plataforma.

Frameworks de aplicacin
Ahora se ha vuelto claro que la reutilizacin orientada a objetos tiene mejor apoyo en un proceso de desarrollo
orientado a objetos a travs de abstracciones de grano grueso, llamadas frameworks (estructuras).
Framework: un conjunto integrado de artefactos de software (tales como clases, objetos y componentes), que
colaborarn en la facilitacin de una arquitectura de reutilizacin para una familia de aplicaciones relacionadas.
Los frameworks brindan soporte para caractersticas genricas que es probable que sean utilizadas en todas las
aplicaciones de un tipo similar.
Los frameworks apoyan la reutilizacin de diseo en la que ofrecen una arquitectura que sirve de esqueleto para la
aplicacin, as como la reutilizacin de clases especficas en el sistema. La arquitectura se define por las clases de
objetos y sus interacciones. Las clases se reutilizan directamente y pueden extenderse utilizando caractersticas
como la herencia.
Los frameworks se implementan como una coleccin de clases de objetos concretos y abstractos en un lenguaje de
programacin orientado a objetos. Por lo tanto, los frameworks son especficos del lenguaje. Es posible usar un
framework para crear una aplicacin completa o implementar parte de una aplicacin (como la GUI por ejemplo).

Clases de frameworks
Hay tres clases de frameworks:

Frameworks de infraestructura de sistema: apoyan el desarrollo de infraestructura de sistema como

comunicaciones, interfaces de usuario y compiladores.
Frameworks de integracin de middleware: consisten en un conjunto de estndares y clases de objetos
asociados que soportan comunicacin de componentes e intercambio de informacin (ejemplo EJB).
Frameworks de aplicacin empresarial: se ocupan de dominios de aplicacin especficos, tales como los
sistemas de telecomunicaciones o financieros.

Para extender un framework no es necesario cambiar el cdigo de ste. En vez de ello, nosotros agregamos clases
concretas que heredan operaciones de clases abstractas en el framework. Adems, quiz sea necesario definir
callbacks (comunicaciones de regreso). Los callbacks son mtodos que se solicitan en respuesta a eventos
reconocidos por el framework. A esto se lo denomina Inversin de Control. Los objetos framework, y no los objetos
especficos de aplicacin, son los responsables del control en el sistema.
Los frameworks son un enfoque efectivo para la reutilizacin, aunque costosos para introducirse en procesos de
desarrollo de software. Se consideran inherentemente complejos, y aprender a usarlos es una actividad que tal vez
dure muchos meses. Depurar las aplicaciones basadas en frameworks resulta complicado, porque tal vez no se
comprenda cmo interactan los mtodos del framework.

Lneas de productos de software

Uno de los enfoques ms efectivos para la reutilizacin es la creacin de lneas de productos de software o familias
de aplicacin.
Una lnea de productos de software es un conjunto de aplicaciones con una arquitectura comn y componentes
compartidos, con cada aplicacin especializada para reflejar diferentes requerimientos. El sistema central se disea
para configurarse y adaptarse a las necesidades de los diferentes clientes del sistema.
- 58 -

Las lneas de producto de software surgen por lo general de aplicaciones existentes. Esto es, una organizacin
desarrolla una aplicacin y, luego, cuando se requiere un sistema similar, el cdigo de sta se reutiliza de manera
informal en la nueva aplicacin. Sin embargo, el cambio tiende a corromper la estructura de la aplicacin, as que, a
medida que se desarrollan ms instancias nuevas, se vuelve cada vez ms difcil crear una nueva versin. Por ello, se
puede disear una lnea de productos genricos. Esto implica identificar la funcionalidad comn en instancias de
producto e incluirlas en una aplicacin base, que despus se usa para desarrollo futuro. Esta aplicacin base se
estructura deliberadamente para simplificar la reutilizacin y la reconfiguracin.

Frameworks vs lneas de productos de software

Los frameworks y las lneas de productos de software tienen mucho en comn, pero las principales diferencias entre
estos enfoques son las siguientes:

Los frameworks de aplicacin se apoyan en caractersticas orientadas a objetos, como herencia y

polimorfismo, para implementar extensiones al framework. El cdigo framework no se modifica. Las lneas
de producto de software no necesariamente se crean mediante un enfoque orientado a objetos. Los
componentes de aplicacin cambian, se borran o rescriben.
Los frameworks de aplicacin se enfocan principalmente en brindar apoyo tcnico antes que dominio
especifico. Una lnea de productos de software por lo general incrusta informacin detallada de dominio y
de plataforma.
Las lneas de producto de software generalmente son aplicaciones de control para equipo. Los frameworks
de aplicacin con frecuencia estn orientados al software, y pocas veces ofrecen soporte para interfaz de
hardware.

Reutilizacin de productos COTS

Un producto COTS (Comercial-Off-The-Shelf) es un sistema de software que puede adaptarse a las necesidades de
diferentes clientes sin cambiar el cdigo fuente del sistema.
Los productos COTS se adaptan al usar mecanismos de configuracin internos que permiten que la funcionalidad del
sistema se adecue a necesidades especficas del cliente.
Otras caractersticas de configuracin permiten al sistema aceptar plug-ins que extiendan la funcionalidad o
comprueben las entradas del usuario para garantizar que son vlidas.

Ventajas de los productos COTS

Es posible la implementacin ms rpida de un sistema fiable.

Es posible ver qu funcionalidad ofrece la aplicacin, de manera que es ms fcil juzgar si es probable que
sea adecuada o no.
Se evitan algunos riesgos de desarrollo al usar software existente.
Las empresas pueden enfocarse en su actividad central sin tener que dedicar muchos recursos al desarrollo
de sistemas TI.

Desventajas de los productos COTS

Tienen que adaptarse los requerimientos para reflejar la funcionalidad y el modo de operacin del producto
COTS.
El producto COTS puede basarse en suposiciones que sean casi imposibles de cambiar. Por lo tanto, el cliente
debe adaptar su empresa para reflejar dichas suposiciones.
Elegir el sistema COTS correcto para una empresa puede ser un proceso difcil, en especial porque muchos
productos COTS no estn debidamente documentados.
Los proveedores de productos COTS controlan el soporte y la evolucin del sistema. Pueden salir del negocio,
perder el control o incluso hacer cambios que ocasionen dificultados a los clientes.
- 59 -

Tipos de reutilizacin de productos COTS

Sistemas de solucin COTS: consisten en una aplicacin genrica de un solo proveedor que se configura de
acuerdo con los requerimientos del cliente.
Sistemas integrados COTS: implican la integracin de dos o ms sistemas COTS (quiz de diferentes
proveedores) para crear un sistema de aplicacin.

INGENIERA DE SOFTWARE BASADA EN COMPONENTES (ISBC)

Introduccin
Para el software personalizado, la ingeniera de software basada en componentes es una forma efectiva orientada
a la reutilizacin para desarrollar nuevos sistemas empresariales.
La ingeniera de software basada en componentes (ISBC, CBSE Component-Based-Software-Engineering) surgi a
finales de los 90 como un enfoque al desarrollo de sistemas de software basada en la reutilizacin de componentes
de software. Su creacin fue motivada por la frustracin de los diseadores al percatarse de que el desarrollo
orientado a objetos no conduca a una reutilizacin extensa. Las clases de objetos individuales eran muy detalladas
y especficas. Por consiguiente, era casi imposible vender o distribuir objetos como componentes de reutilizacin
individuales.
Los componentes son abstracciones de alto nivel en comparacin con los objetos y se definen mediante interfaces.
La ISBC es el proceso de definir, implementar e integrar o componer los componentes independientes e imprecisos
en los sistemas.
El desarrollo de software basado en componentes permite reutilizar piezas de cdigo preelaborado que permiten
realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reduccin del ciclo de
desarrollo y el mayor retorno sobre la inversin.

Fundamentos de la ISBC
1. Componentes independientes que se especifican por completo mediante sus interfaces. La implementacin
de un componente puede sustituirse por otra, sin cambiar otras partes del sistema.
2. Estndares de componentes que facilitan la integracin de estos. Definen, a un nivel mnimo, cmo deben
especificarse las interfaces de componentes y cmo se comunican estos ltimos. Si los componentes se
conforman a los estndares, entonces su ejecucin es independiente de su lenguaje de programacin.
3. Middleware que brinda soporte para integracin de componentes. Para hacer que componentes
independientes distribuidos trabajen en conjunto, es necesario soporte de middleware que maneje las
comunicaciones de componentes. El middleware para soporte de componentes maneja eficientemente los
conflictos de bajo nivel y permite enfocarse en problemas relacionados con la aplicacin.
4. Un proceso de desarrollo que se engrana con la ingeniera de software basada en componentes. Se necesita
de un proceso de desarrollo que permita la evolucin de requerimientos, dependiendo de la funcionalidad
de los componentes disponibles.

Principios de diseo en la ISBC

1. Los componentes son independientes, de manera que sus ejecuciones no interfieren entre s.
2. Se ocultan los detalles de la implementacin. La implementacin de componentes pueden cambiar sin
afectar el resto del sistema.
3. Los componentes se comunican a travs de interfaces bien definidas, donde es posible sustituir un
componente por otro.
4. Las infraestructuras de componentes ofrecen varios servicios estndar que pueden usarse en sistemas de
aplicacin. Esto recude la cantidad de cdigo nuevo que debe desarrollarse.
- 60 -

Componentes como servicios

Para apoyar esta visin de componente, se han desarrollado muchos y diferentes protocolos y estndares, como el
Enterprise JavaBeans (EJB) de Sun, COM y .NET de Microsoft, y CCM de CORBA.
En la prctica, era imposible que componentes desarrollados mediante estos diferentes enfoques funcionaran
juntos.
En respuesta a estos problemas, se desarroll la nocin de componente como un servicio, y se propusieron
estndares para apoyar la ingeniera de software orientada a servicios.
La diferencia ms significativa entre un componente como servicio y la nocin original de componente es que los
servicios son entidades independientes externas a un programa que los usa. Cuando se construye un sistema
orientado al servicio, se hace referencia al servicio externo en vez de incluir en nuestro sistema una copia de dicho
servicio.
Por lo tanto, la ingeniera de software orientada al servicio es un tipo de ingeniera de software basada en
componentes.

Problemas de la ISBC

Confiabilidad de los componentes: los componentes suelen ser cajas negras y el cdigo no est disponible.
Certificacin de componentes: se deberan certificar los componentes para asegurar su confiabilidad, pero
Quin pagara su certificacin?
Prediccin de propiedades emergentes: al ser los componentes opacos, predecir sus propiedades
emergentes es difcil. El sistema podra tener propiedades no deseadas.
Equilibro de requerimientos: equilibro entre requerimientos ideales y componentes disponibles se hace
intuitivamente. Se necesita de un mtodo ms estructurado y sistemtico que ayude a seleccionar y
configurar componentes.

Componentes
Un componente es:
-

una unidad de software independiente que puede organizarse con otros componentes para crear un sistema
de software.
un elemento de software que se conforma a un modelo de componentes estndar y puede desplegarse y
componerse independientemente sin modificacin, de acuerdo con un estndar de composicin.
una unidad de composicin con interfaces especificadas contractualmente y slo con dependencias de
contexto explcitas. Un componente de software puede implementarse independientemente y est sujeto a
composicin por terceras partes.

Lo que tienen en comn estas definiciones es que concuerdan en que los componentes son independientes, y los
consideran la unidad fundamental de composicin de un sistema.
Componente: es una pieza de cdigo preelaborado que encapsula alguna funcionalidad expuesta a travs de
interfaces estndar.

Caractersticas de los componentes

Estandarizado: debe ajustarse a un estndar, que define interfaces, metadatos, documentacin,

composicin e implementacin.
Independiente: debe ser factible componerlo e implementarlo sin usar otros componentes.
Componible: todas las interacciones externas deben darse mediante interfaces definidas pblicamente.
Debe permitir acceso a informacin sobre s mismo.
- 61 -

Implementable: debe ser autocontenido. Capaz de ejecutarse como una entidad independiente. El
componente es binario y no tiene que compilarse antes de su implementacin.
Documentado: deben implementarse de forma completa. Debe especificarse su sintaxis y la semntica de
todas las interfaces de componente. As los usuarios pueden decidir si el componente satisface sus
necesidades.

Una forma til de pensar en un componente es como un proveedor de uno o ms servicios. Cuando un sistema
necesita un servicio, llama a un componente que brinde ese servicio sin importar donde se est ejecutando o su
lenguaje de programacin.
1. El componente es una unidad ejecutable independiente definida mediante sus interfaces. Para usarlo no
necesita conocimiento alguno de su cdigo fuente. Puede hacerse referencia a l como un servicio externo
o incluirse directamente en un programa.
2. Los servicios ofrecidos por un componente se ponen a disposicin mediante una interfaz, y todas las
interacciones por dicha interfaz. La interfaz del componente se expresa en trminos de operaciones
parametrizadas y nunca se expone su estado interno.

Una diferencia entre un componente como servicio y un componente como elemento de un programa es que los
servicios son entidades independientes por completo. No tienen una interfaz requiere. Diferentes programas
pueden usar dichos servicios sin necesidad de implementar soporte adicional requerido ara el servicio.

Modelos de componentes
Un modelo de componentes es una definicin de estndares para implementacin, documentacin y despliegue de
componentes. Se establecen con la finalidad de que los desarrolladores de componentes se aseguren de que stos
pueden interoperar.
Los modelos ms importantes son el modelo de Web Services, el modelo Java Enterprise JavaBeans y el modelo .NET
de Microsoft.
Los elementos de un modelo de componentes definen las interfaces de componentes, la informacin que necesita
usar el componente en un programa y cmo debe implementarse un componente.

Interfaces: el modelo de componentes especifica cmo deben definirse las interfaces y los elementos, tales
como los nombres de operacin, los parmetros y las excepciones que deben incluirse en la definicin de la
interfaz.
Uso: para que los componentes se distribuyan y se acceda a ellos de manera remota, deben tener un nombre
nico asociado.
Los metadatos de un componente son datos acerca del componente en s, tales como informacin acerca
de sus interfaces y atributos. Los metadatos son importantes porque permiten a los usuarios del
componente determinar qu servicios se proporcionan y requieren. Tambin puede especificar como
pueden personalizarse los componentes binarios para un entorno de implementacin particular.
Implementacin: el modelo de componentes incluye una especificacin de cmo deben empacarse los
componente para su implementacin como entidades ejecutables independientes.
- 62 -

Middleware
Para componentes que se implementen como unidades de programa y no como servicios externos, el modelo de
componentes establece los servicios a ofrecer por parte del middleware que apoye los componentes de ejecucin.
Los servicios brindados por una implementacin de modelo de componentes se dividen en dos categoras:

Servicios de plataforma: permiten a los componentes comunicarse e interoperar en un entorno distribuido.

Servicios de soporte: son servicios comunes que probablemente requieran muchos componentes diversos.

El middleware implementa los servicios de componentes y ofrece interfaces a dichos servicios. Para usar los servicios
ofrecidos por la infraestructura de un modelo de componentes, se puede considerar a los componentes como
implementados en un contenedor. Un contenedor es una implementacin de los servicios de soporte ms una
definicin de las interfaces que debe proporcionar un componente para integrarlo en el contenedor. Cuando se
usan otros componentes, no acceden directamente a las interfaces del componente, en vez de eso, se accede a
stas a travs de una interfaz de contenedor que recurre al cdigo para acceder a la interfaz del componente
embebido.

Procesos ISBC
Los procesos ISBC son procesos de software que brindan soporte a la ingeniera de software basada en componentes.
Existen dos tipos de procesos ISBC:

Desarrollo para reutilizacin: se ocupa del desarrollo de componentes o servicios que se reutilizaran en
otras aplicaciones.
Desarrollo con reutilizacin: proceso para desarrollar nuevas aplicaciones usando los componentes y
servicios existentes.

Dichos procesos tienen diferentes objetivos y, por consiguiente, incluyen distintas actividades. En el proceso de
desarrollo para reutilizacin, el objetivo es producir uno o ms componentes reutilizables. En el desarrollo con
reutilizacin, no sabe cules estn disponibles, as que se necesita descubrir dichos componentes y disear un
sistema para utilizarlos de la manera ms efectiva. No puede tener acceso al cdigo fuente del componente.
1. Adquisicin de componentes es el proceso de adquirir componentes para reutilizacin o desarrollo en un
componente reutilizable.
2. La gestin de componentes se ocupa de catalogar los componentes y almacenarlos y organizarlos para su
uso.
3. La certificacin de componentes comprueba componentes para asegurar que cumplen su especificacin.

ISBC para reutilizacin

La ISBC para reutilizacin es el proceso de desarrollar componentes reutilizables y ponerlos a disposicin para
reutilizarlos a travs de un sistema de gestin de componentes.
Para elaborar componentes de reutilizacin, deben adaptarse y extenderse componentes especficos de aplicacin
para crear versiones ms genricas y, por lo tanto, ms reutilizables.
Los cambios que se pueden hacer a un componente para volverlo ms reutilizable, incluye:

Eliminar mtodos especficos de aplicacin.

Cambiar los nombres para hacerlos ms generales.
Agregar mtodos para brindar cobertura funcional ms completa.
Hacer manejadores de excepcin consistentes para todos los mtodos.

- 63 -

Adicionar una interfaz de configuracin para permitir la adaptacin de los componentes a diferentes
situaciones.
Integrar los componentes requeridos para aumentar la independencia.

Conforme se agrega generalidad a un componente, aumenta la probabilidad de su reutilizacin. No obstante, esto

por lo regular significa que el componente tiene ms operaciones y ms complejidades, las cuales lo hacen difcil de
entender y de usar.
Hacer un componente reutilizable significa ofrecer una interfaz simple y mnima, que sea fcil de entender. En
consecuencia, cuando se disea un componente de reutilizacin, debe encontrar un compromiso entre la
generalidad y comprensibilidad.

ISBC con reutilizacin

La ISBC con reutilizacin debe incluir actividades que encuentren e integren componentes reutilizables.

El proceso de identificacin de componentes

La validacin de componentes consiste en probar los componentes para asegurarse de que se comportan como se
espera. Consiste en desarrollar un conjunto de casos de prueba para un componente.

Composicin de componentes
La composicin de componentes es el proceso de integrar componentes uno con otro y con cdigo pegamento
especialmente escrito para crear un sistema u otro componente.

Composicin secuencial (a): se requiere cdigo de pegamento adicional para llamar a los servicios del
componente en el orden correcto y asegurar que los resultados entregados por el componente A sean
compatibles con las entradas esperaras por el componente B. Este tipo de composicin puede usarse con
componentes que son elementos de programa o con componentes que son servicios.
Composicin jerrquica (b): ocurre cuando un componente llama directamente a los servicios que ofrece
otro componente. El componente llamado proporciona los servicios que requiere el componente que llama.
Este modo de composicin no se usa cuando se implementan componentes como servicios web.

- 64 -

Composicin aditiva (c): ocurre cuando dos o ms componentes se juntan (se suman) para crear un nuevo
componente, lo que combina su funcionalidad. Este tipo de componente puede usarse con componentes
que son unidades de programa o con componentes que son servicios.

Incompatibilidad de interfaces

Incompatibilidad de parmetros: las operaciones de cada lado de la interfaz tiene el mismo nombre, pero
sus tipos de parmetro o el nmero de parmetros son diferentes.
Incompatibilidad de operacin: los nombres de las operaciones en las interfaces proporciona y requiere
son diferentes.
Operacin incompleta: la interfaz proporciona de un componente es un subconjunto de la interfaz
requiere de otro componente o viceversa.

Beneficios

Estudios informan que el ensamblaje de componentes lleva a :

o Una reduccin del 70% del tiempo de ciclo de desarrollo.
o Un 84% del costo del proyecto.
o Un ndice de productividad del 26,2 comparado con la norma de industria del 19,9.
Aunque estos resultados estn en funcin de la robustez de la biblioteca de componentes, no hay duda que
el ensamblaje de componentes proporciona ventajas significativas para los ingenieros de software.

Ventajas

Aumento de reutilizacin de software.

Simplifica las pruebas. Pruebas unitarias antes de probar el conjunto completo de componentes
ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes, el
desarrollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras partes
del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un
experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso del
tiempo.

- 65 -

ESTRATEGIAS DE PROTOTIPADO
Conceptos
Estrategia de prototipado
Una estrategia de prototipado es una eleccin de modelo de proceso (ciclo de vida) que se recomienda elegir a la
hora de implementar un proyecto complejo, con dominio no familiar, que utilizar una tecnologa desconocida.
Por ello se requiere el uso de prototipos en el diseo y la implementacin, adems de utilizarlos durante la validacin
de requerimientos.

Prototipo
Un prototipo consiste en una primera versin de un nuevo tipo de producto, en el que se han incorporado slo
algunas caractersticas del sistema final, o no se han realizado completamente.
Es un modelo o maqueta del sistema que se construye para comprender mejor el problema y sus posibles soluciones:
evaluar mejor los requerimientos y probar opciones de diseo.
Un prototipo se puede utilizar de diferentes maneras en el proceso de desarrollo:

En el proceso de ingeniera de requerimientos: ayuda a obtener y validar los requerimientos del sistema.
En el proceso de diseo del sistema: ayuda a explorar soluciones de software particulares y para apoyar a
diseo de interfaces de usuario.
En el proceso de pruebas: se puede utilizar para ejecutar pruebas back-to-back con el sistema que se
entregar al cliente (se envan las mismas pruebas al sistema y al prototipo):

Permiten a los usuarios ver como el sistema apoya a su trabajo. Pueden adquirir nuevas ideas para los
requerimientos y encontrar reas fuertes y dbiles en el software. Puede revelar errores y omisiones en los
requerimientos propuestos.
Caractersticas
Funcionalidad limitada.
Poca fiabilidad.
Caractersticas de operacin pobres.
Pocos das de desarrollo.

Beneficios de los prototipos

Mejora la usabilidad del sistema.

Una mejor concordancia entre el sistema y las necesidades del usuario.
Ayuda al cliente a establecer claramente los requerimientos.
Mejora la calidad del diseo.
Mejora el mantenimiento.
Reduccin en el esfuerzo de desarrollo.
Aumentan la productividad.
Planifican el desarrollo.
Entusiasmo de los usuarios respecto a los prototipos.

- 66 -

Proceso de desarrollo de prototipos

1. Establecer objetivos del prototipo: los objetivos del prototipo deben ser claros desde el principio, ya que se
puede malinterpretar la funcin del prototipo y no se obtengan los beneficios esperados.
2. Definir funcionalidad del prototipo: decidir que incluir y que excluir del prototipo. Se podra dejar a un lado
los requerimientos no funcionales y centrarse en la funcionalidad, reducir estndares, obviar manejo de
errores, etc. aunque depende del tipo de prototipo que se est haciendo.
3. Desarrollar prototipo: construir el prototipo.
4. Evaluar prototipo: analizar los resultados del uso del prototipo.

Cundo son interesantes los prototipos?

SIEMPRE!, pero especialmente cuando:

Dominio riesgoso (bien por dificultad o por falta de tradicin en su aplicacin).

Se usan nuevos mtodos, tcnicas, tecnologas.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organizacin.
El costo de rechazo por parte de los usuarios, por no cumplir sus expectativas, es muy alto.

Clasificacin de prototipos
Prototipos segn su propsito

Prototipado de interfaz de usuario: modelos de pantallas.

Prototipado funcional (operacional): implementa algunas funciones, y a medida que se comprueba que son
las apropiadas, se corrigen, refinan y se aaden otras.
Prototipos arquitectnicos: sirven para evaluar decisiones arquitectnicas de infraestructura, tecnologa e
integracin.
Modelos de rendimiento: evalan el rendimiento de una aplicacin crtica (no sirven al anlisis de
requerimientos).

Prototipos segn su utilidad

Prototipos rpidos o desechables

o Sirve al anlisis y a la validacin de requerimientos.
o Despus se redacta la especificacin del sistema y se desecha el prototipo.
o La aplicacin se desarrolla siguiendo un paradigma diferente.
o Problema: cuando el prototipo no se desecha y termina convirtindose en el sistema final.
Prototipos evolutivos
o Comienza con un sistema relativamente simple que implementa los requerimientos ms importantes o mejor
conocidos.
o El prototipo se aumenta o cambia en cuanto se descubren nuevos requerimientos.
o Finalmente, se convierte en el sistema requerido.
o Se usa en el desarrollo Web y en aplicaciones de comercio electrnico.

- 67 -

Prototipos segn su alcance

Vertical: desarrolla completamente alguna de las funciones.

Horizontal: desarrolla parcialmente todas las funciones.

DISEO DE INTERFACES DE USUARIO

Introduccin
Un buen diseo de la interfaz de usuario es crtico para la confiabilidad del sistema. Muchos de los llamados errores
de usuario son causados por el hecho de que las interfaces de usuario no consideran las habilidades de los usuarios
reales y su entorno de trabajo. Una interfaz de usuario mal diseada significa que los usuarios probablemente no
podrn acceder a algunas caractersticas del sistema, cometern errores y sentirn que el sistema les dificulta en vez
de ayudarlos a conseguir cualquier objetivo para el que utilizan el sistema.

Factores humanos en el diseo de GUIs

1. Las personas tienen una memoria limitada a corto plazo: los humanos podemos recordar hasta siete
elementos de informacin. Si a los usuarios se les presenta demasiada informacin al mismo tiempo, es
posible que no puedan asimilarla.
2. Las personas cometen errores: especialmente cuando manejamos mucha informacin o estamos
estresados. Cuando los sistemas fallan y emiten mensajes de aviso y alarmas, a menudo aumentan el estrs
de otros usuarios, incrementando as la posibilidad de cometer errores.
3. Las personas son diferentes: muchas personas tienen diferentes capacidades fsicas. No se debe disear para
sus propias cualidades fsicas y suponer que todos los usuarios sern capaces de adaptarse.
4. Las personas tienen diferentes preferencias de interaccin: a algunas personas les gustan las imgenes
mientras que a otras el texto.

Principios de diseo de GUIs

1. Familiaridad del usuario: la interfaz debe utilizar trminos familiares para los usuarios, y los objetos que el
sistema manipula deben estar directamente relacionados con el entorno de trabajo del usuario.
2. Uniformidad: significa que los comandos y mens del sistema deben tener el mismo formato, los parmetros
deben pasarse a todos los comandos de la misma forma, y la puntuacin de los comandos debe ser similar.
Esto reduce el tiempo de aprendizaje del usuario.
3. Mnima sorpresa: es apropiado debido a que las personas se irritan demasiado cuando el sistema se
comporta de forma inesperada. Los usuarios no deberan sorprenderse por el comportamiento del sistema.
4. Recuperabilidad: los usuarios inevitablemente cometen errores cuando utilizan un sistema. Por eso, se
deben incluir recursos que permitan a los usuarios recuperarse de sus errores:
a. Confirmacin de acciones destructivas: cuando un usuario va a realizar una accin crtica o
potencialmente destructiva, el sistema deber pedirle que confirme que esto es realmente lo que
desea antes de destruir cualquier informacin.
b. Proporcionar un recurso para deshacer: restablece el sistema al estado previo antes de que ocurriera
la accin.
c. Generar puntos de control: implica grabar el estado de un sistema en intervalos peridicos y permitir
que el sistema se restaure desde el ltimo punto de control.
5. Asistencia al usuario: las interfaces deben proporcionar asistencia al usuario o caractersticas de ayuda.
Estas se deben integrar en el sistema y proporcionar diferentes niveles de ayuda y asesoramiento.
6. Diversidad de usuarios: para un sistema pueden existir diferentes tipos de usuarios. Por ejemplo, usuarios
casuales usaran asistentes, y usuarios potenciales usaran mtodos abreviados de forma que puedan
interactuar con el sistema lo ms rpido posible.

- 68 -

Interaccin de usuario
Cinco formas de interaccin:
1. Manipulacin directa: el usuario interacta directamente con los objetos de la pantalla.
a. Ventajas
i. Interaccin rpida e intuitiva
ii. Fcil de aprender
b. Desventajas
i. Puede ser difcil de implementar
ii. Adecuado nicamente cuando hay una metfora visual para tareas y objetos
c. Ejemplo
i. Videojuegos y sistemas CAD
2. Seleccin de mens: el usuario selecciona un comando de una lista de posibilidades.
a. Ventajas
i. Evita errores del usuario
ii. Se requiere poco tipeo
b. Desventajas
i. Lento para usuarios experimentados
ii. Puede ser complejo si hay muchas opciones
c. Ejemplo
i. La mayora de sistemas de propsito general
3. Llenado de formularios: el usuario rellena los campos de un formulario.
a. Ventajas
i. Ingreso de datos simple
b. Desventajas
i. Ocupa mucho espacio en la pantalla
ii. Causa problemas cuando la opcin del usuario no coincide con los campos del formulario
c. Ejemplo
i. Control de stock, sistemas generales, etc.
4. Lenguaje de comandos: el usuario emite un comando especial y los parmetros asociados para indicar al
sistema que hacer. Es la tpica consola.
a. Ventajas
i. Poderoso y flexible
b. Desventajas
i. Difcil de aprender
ii. Manejo de errores pobre
c. Ejemplo
i. Sistemas operativos, sistemas de control de comandos
5. Lenguaje natural: el usuario emite un comando en lenguaje natural.
a. Ventajas
i. Accesible a usuarios casuales
ii. Fcilmente extensible
b. Desventajas
i. Requiere ms tipeo.
c. Ejemplo
i. Buscadores
Estos estilos de interaccin se pueden mezclar, utilizando varios estilos en la misma aplicacin.

- 69 -

Presentacin de la informacin
Todos los sistemas interactivos tienen que proporcionar alguna forma de presentar la informacin a los usuarios. La
presentacin de la informacin puede ser simplemente una representacin directa de la informacin de entrada
(texto) o presentar informacin grficamente. Una buena pauta de diseo es mantener separado el software
requerido para la presentacin de la informacin misma. Separar el sistema de presentacin de los datos nos
permite cambia la representacin en la pantalla del usuario sin tener que cambiar el sistema de clculo subyacente.
El enfoque MVC es una forma efectiva para permitir representaciones mltiples de datos. Por lo tanto, un modelo
que representa datos numricos puede tener una vista que represente los datos como un histograma y una vista
que presente los datos como una tabla.
Cuando se decide como presentar la informacin, deben tenerse en cuenta las siguientes cuestiones:

El usuario est interesado en informacin precisa o en las relaciones entre los valores de los datos?
Con que frecuencia cambian los valores de la informacin?
El usuario debe tomar alguna accin en respuesta a un cambio de informacin?
Existe una interfaz de manipulacin directa?
La informacin a mostrar es textual o numrica?

Grficos vs texto
Los grficos muestran la informacin ms directamente, pero ocupan un valioso espacio en la pantalla y pueden
tardar bastante tiempo en descargarse si el usuario est trabajando con una conexin lenta.
La precisin textual ocupa menos espacio en la pantalla, pero no puede ser vista de un vistazo.

Texto: se debe usar cuando la informacin tiene que ser precisa y cambie de forma relativamente lenta.
Grfico: se debe usar cuando los datos cambian rpidamente o si las relaciones entre los datos son ms
importantes que los valores exactos.

Las vistas digitales que cambian constantemente pueden ser confusas y molestas ya que los lectores no pueden leer
y asimilar la informacin antes de que cambie. Por lo tanto, la informacin numrica que vara dinmicamente se
representa mejor grficamente utilizando una representacin analgica. Si es necesario, las vistas grficas pueden
complementarse con una vista digital precisa.
Tipos de informacin
Informacin esttica: inicializada al principio de la sesin. No cambia durante la sesin. Puede ser numrica
o textual.
Informacin dinmica: cambiar durante la sesin y los cambios deben ser comunicados al usuario del
sistema. Puede ser numrica o textual.
Tipos de presentacin
Presentacin digital: es compacta. Necesita poco espacio en pantalla. Se utiliza para comunicar valores
precisos.
Presentacin anloga: ms fcil para obtener una impresin a primera vista de un valor. Es posible mostrar
valores relativos. Ms fcil de ver valores excepcionales de los datos. Ejemplo: grficos, reloj analgico,
termmetro, etc.

Colores
Tambin, se debe pensar detenidamente en los colores utilizados en la interfaz. El color puede mejorar las interfaces
de usuario ayudando a los usuarios a comprender y manejar la complejidad. Sin embargo, es fcil utilizar el color de
forma errnea para crear interfaces visualmente poco atractivas y propensa a errores.

- 70 -

A tener en cuenta:
1. Limitar el nmero de colores utilizados y ser conservador en la forma de utilizarlos: no deben utilizarse
ms de cuatro o cinco colores diferentes en una ventana y no ms de siete en una interfaz de sistema.
2. Utilizar un cambio de color para mostrar un cambio en el estado del sistema: si una vista cambia de color,
debe significar que ha ocurrido un evento importante.
3. Utilizar el cdigo de colores para apoyar la tarea que los usuarios estn tratando de llevar a cabo: si los
usuarios tienen que identificar instancias anmalas, se deben resaltar estas instancias; si tambin tiene que
descubrir similitudes, se deben resaltar stas utilizando un color diferente.
4. Utilizar el cdigo de colores de una forma consistente y uniforme: si una parte de un sistema muestra los
mensajes de error en rojo, todas las dems partes deben mostrarlos de igual forma. El rojo no se debe utilizar
para nada ms. Si se hace, es posible que el usuario interprete la vista en rojo como un mensaje de error.
5. Ser cuidadoso al utilizar pares de colores: hay combinaciones de colores que pueden ser visualmente
molestas o difciles de leer.
En general, se debe utilizar el color para la accin a resaltar, pero no se deben asociar significados con colores
particulares.

Mensajes de error
Los sistemas se comunican con los usuarios a travs de mensajes que proporcionan informacin sobre los errores y
estados del sistema.
Factores que deben tenerse en cuenta a la hora de disear mensajes del sistema:
1. Contexto: los mensajes generados por el sistema deben reflejar el contexto actual del usuario. El sistema
debe ser consciente de lo que est haciendo el usuario y generar mensajes relacionados con su actividad
actual.
2. Experiencia: debera proveerse mensajes para usuarios experimentados y para usuarios principiantes, y
permitirle al usuario que elija que tan conciso es el tipo de mensaje que desea.
3. Nivel de habilidad: los mensajes se deben adaptar a las habilidades del usuario. Los mensajes para diferentes
clases de usuarios deberan presentar diferentes terminologas dependiendo de lo que es familiar para el
usuario.
4. Estilo: los mensajes deberan ser positivos en lugar de negativos. Deberan estar escritos en modo activo y
no pasivo. No deben ser insultantes o tratar de ser graciosos.
5. Cultura: cada vez que sea posible, el diseador de mensajes debe estar familiarizado con la cultura del pas
donde se utilizar el sistema. Un mensaje adecuado para una cultura puede ser inadecuado para otras.
Los mensajes de error siempre deben ser formales, concisos, uniformes y constructivos. No deben ser ofensivos ni
tener sonidos asociados u otro tipo de ruidos que pueden desconcertar al usuario. En la media de lo posible, el
mensaje debe sugerir cmo se podra corregir el error. El mensaje de error debe vincularse a un sistema de ayuda
en lnea sensible al contexto.

El proceso de diseo de interfaces de usuario

El diseo de la GUI es un proceso iterativo donde los usuarios interactan con los diseadores y prototipos de la
interfaz para decidir las caractersticas, organizacin, apariencia y funcionamiento de la interfaz de usuario del
sistema.
Antes de que empiece la programacin, debe haber desarrollado, e idealmente, probado algunos diseo en papel.

- 71 -

Existen tres actividades en este proceso:

1. Anlisis del usuario: se desarrolla una comprensin de las tareas que ste realiza, su entorno de trabajo, los
otros sistemas que utiliza, cmo interactan con el resto de las personas en su trabajo, etc.
2. Prototipado del sistema: se deben desarrollar prototipos del sistema y exponerlos a los usuarios, quienes
pueden entonces guiar la evolucin de la interfaz.
3. Evaluacin de la interfaz: actividad de evaluacin donde se recopila informacin sobre las experiencias
reales de los usuarios con la interfaz.

Anlisis del usuario

Si no se entiende lo que los usuarios quieren hacer con el sistema, no se podr llevar a cabo un diseo real y eficaz
de la interfaz de usuario. Para desarrollar esta comprensin, se pueden utilizar tcnicas como el anlisis de tareas,
estudios etnogrficos, entrevistas de usuarios, cuestionarios y observaciones, o una mezcla de todas.

Prototipado de la interfaz de usuario

El prototipado evolutivo o exploratorio con la implicacin de los usuarios finales es la nica forma prctica de disear
y desarrollar interfaces grficas de usuario para sistemas software. Implicar al usuario en el proceso de diseo y
desarrollo es un aspecto fundamental del diseo centrado en el usuario.
El propsito del prototipado es permitir a los usuarios adquirir una experiencia directa con la interfaz.
Cuando se est construyendo el prototipo de una interfaz de usuario se debe adoptar un proceso de prototipado en
dos etapas:
1. Al principio del proceso, hay que desarrollar prototipos de papel y mostrrselos a los usuarios finales.
2. Entonces, se perfecciona el diseo y se desarrollan prototipos automatizados cada vez ms sofisticados, y
se ponen a disposicin de los usuarios para realizar pruebas y simulacin de actividades.
La construccin de prototipos en papel es un proceso poco costoso y sorprendentemente efectivo para el desarrollo
de prototipos.
Como alternativa, se puede utilizar una tcnica basada en storyboards para presentar el diseo de interfaz. Un
storyboard es una serie de esbozos que ilustran una secuencia de interacciones.
Enfoques de prototipado
Enfoque dirigido por secuencias de comandos: se crean pantallas con elementos visuales, como botones y
mens, y se asocia una secuencia de comandos con estos elementos.
Lenguajes de programacin visuales: lenguajes como Visual Basic, incorporan un potente entorno de
desarrollo de GUIs que permite crear interfaces rpidamente.
Prototipado basado en internet: basadas en navegadores web (HTML).

Evaluacin de la interfaz
La evaluacin de la interfaz es el proceso de evaluar la forma en que se utiliza una interfaz y verificar que cumple
con los requerimientos del usuario.
Una evaluacin se debe llevar a cabo contra una especificacin de la usabilidad basada en atributos de la usabilidad.
Atributos:

Aprendizaje: Cunto tiempo tarda un usuario nuevo en ser productivo con el sistema?
Velocidad de funcionamiento: Cmo responde el sistema a las operaciones de trabajo del usuario?
Robustez: Qu tolerancia tienen el sistema a los errores del usuario?
Recuperacin: Cmo se recupera el sistema a los errores del usuario?
- 72 -

Adaptacin: Est muy atado el sistema a un nico modelo de trabajo?

La evaluacin sistemtica del diseo de la interfaz puede ser muy costosa. Existen varias tcnicas menos costosas y
sencillas en la evaluacin de interfaces que pueden identificar deficiencias especficas en el diseo de interfaces:

Cuestionarios que recopilan informacin de lo que opinan los usuarios de la interfaz.

La observacin de los usuarios cuando trabajan con el sistema y piensan en voz alta de cmo tratan de
utilizar el sistema para llevar a cabo alguna tarea.

Consideraciones

Interaccin general
o Ser consistente
o Ofrecer respuestas significativas
o Pedir verificacin de cualquier accin destructiva
o Permitir volver atrs en la mayora de las acciones
o Reducir la cantidad de informacin que se debe memorizar entre acciones
o Perdonar los errores
o Buscar la eficiencia en el dilogo, el movimiento y el pensamiento
o Categorizar las actividades por funcin y organizar la pantalla de acuerdo a esto
o Proporcionar ayudas sensibles al contexto
o Usar verbos de accin sencillos o frases verbales cortas para nombrar las rdenes
Visualizacin de la informacin
o Mostrar informacin que sea relevante en el contexto actual
o No abrumar al usuario con datos. Permitirle una rpida asimilacin de la informacin
o Usar etiquetas consistentes, abreviaciones estndar y colores predecibles
o Permitir al usuario mantener el contexto visual (scroll, wizard)
o Producir mensajes de error significativos
o Usar maysculas y minsculas, tabulaciones y agrupamiento de texto
o Usar ventanas para compartimentar diferentes tipos de informacin
o Usar presentaciones analgicas para representar informacin que es ms fcilmente asimilable
o Estudiar la distribucin disponible en la pantalla y usarla eficientemente
Entrada de datos
o Minimizar el nmero de entrada de datos que necesita realizar el usuario
o Mantener la consistencia entre la visualizacin y la introduccin de datos
o Permitir al usuario personalizar la entrada
o La interaccin debera ser flexible pero tambin sintonizarse al modo preferido del usuario de
entrada
o Desactivar las rdenes que son inapropiadas en el contexto de las acciones actuales
o Dejar al usuario controlar el flujo interactivo
o Proporcionar ayuda en todas las acciones de entrada
o Eliminar entradas innecesarias

Las ocho reglas de Shneiderman

1.
2.
3.
4.
5.
6.
7.
8.

Buscar siempre la coherencia.

Permitir el uso de shortcuts.
Dar realimentacin de informacin.
Disear dilogos que tengan un fin.
Permitir los manejos simples de los errores.
Permitir deshacer acciones con facilidad.
Permitir que el centro de control sea interno.
Reducir la carga de la memoria intermedia.
- 73 -

Productos del diseo de interfaz externa

DISEO ORIENTADO A OBJETOS

Caractersticas de un buen diseo

Independencia de los componentes.

Identificacin y tratamiento de excepciones.
Prevencin y tolerancia de defectos.

Independencia de componentes
En la mayora de los diseo se trata que los componentes sean independientes unos de otros. Para medir el grado
de independencia de los componentes de un diseo se aplican dos conceptos: Acoplamiento y Cohesin.
Acoplamiento
Dos componentes estn altamente acoplados cuando existe mucha dependencia entre ellos.
Los componentes poco acoplados, tienen algunas dependencias, pero las interconexiones entre ellos son
dbiles.
Los componentes no acoplados no tienen interconexiones con el resto, son completamente independientes.
Poco probable en un sistema.
Cohesin
Se refiere al grado de interconexin interna con el que se ha construido el componente.
Un componente es cohesivo si todos sus elementos estn orientados a la realizacin de una nica tarea y
son esenciales para llevarla a cabo.

Principios de diseo
Un principio de diseo es una tcnica o herramienta bsica que puede ser aplicada para disear o construir software,
para hacer ms flexible, extensible y mantenible.

Principios de diseo bsicos

Flexibilidad: el software puede cambiar y crecer sin un constante re-trabajo. Evita la fragilidad del software.
Encapsulamiento: mantiene las partes del software que son estables, lejos de las partes que cambian,
entonces es fcil hacer cambios sin necesidad de romper todo.
- 74 -

Funcionalidad: sin esto no importa que bien est hecho el diseo, el cliente no estar feliz.
Uso de patrones de diseo: se trata de reso y de no tratar de resolver un problema que ya resolvi alguien
ms.

Principios
N

Principio

Abierto-Cerrado

No te repitas (DRY)

Responsabilidad nica

Sustitucin de Liskov

Descripcin
Es para permitir el cambio, y para permitirlo sin modificar lo
existente.
Clases abiertas para extensin.
Clases cerradas para modificacin.
Es a cerca de la flexibilidad.
Evitar duplicaciones, abstrayendo cosas comunes y
ubicndolas en un nico lugar.
Se trata de ubicar un requerimiento en un nico lugar.
Tener cada pieza de informacin y comportamiento en un
nico lugar.
Cada objeto del sistema debera tener una nica
responsabilidad.
Todos los servicios del objeto deberan focalizarse en ejecutar
esa nica responsabilidad.
Se cumple si cada objeto tiene una nica razn para cambiar
(cohesin).
Los subtipos deben ser utilizados por sus tipos base.
Se refiere a la herencia bien diseada.
Este principio revela problemas con la estructura de la
herencia, si existieran.

Clases anidadas
Algunos lenguajes como Java permiten situar una definicin de clase dentro de otra definicin de clase. Esto crea lo
que se conoce como una clase anidada (nested class). Una clase anidada se declara dentro del espacio de nombres
de su clase externa y es slo accesible por esa clase o por los objetos de esa clase. En Java se conoce como clase
interna (inner class).

Agregacin
Es un tipo de relacin todo-parte en la que el conjunto se compone de muchas partes. Es una relacin todo-parte,
un objeto (el todo) utiliza los servicios de otro objeto (la parte). La parte ni siquiera sabe que es parte de un todo.
La agregacin es asimtrica. Esto significa que un objeto nunca puede ser, directa o indirectamente, parte de s
mismo.

- 75 -

Composicin
La composicin es una forma ms fuerte de agregacin y tiene semntica similar. Al igual que la agregacin, es una
relacin todo-parte. La diferencia clave entre agregacin y composicin es que en composicin las partes no tienen
vida independiente fuera del todo. En la composicin, cada parte pertenece al menos a un y slo a un todo, mientras
que en agregacin una parte se puede compartir entre los todos.

Las partes pueden solamente pertenecer a un conjunto cada vez.

El conjunto tiene responsabilidad nica para la deposicin de todas sus partes (creacin y destruccin).
El conjunto puede liberar partes, siempre y cuando la responsabilidad para ellas se asuma por otro objeto.
Si se destruye el conjunto, debe destruirse todas sus partes.

La forma de reconocer a la agregacin y a la composicin es hacer la siguiente pregunta: El objeto cuyo

comportamiento quiero usar, existe fuera del objeto que usa ese comportamiento?. Si el objeto tiene sentido de
existencia por si solo se debe usar agregacin, de lo contrario usar composicin.

Encapsulamiento
Los programas orientados a objetos estn formados de objetos . Un objeto encapsula tanto datos como los
procedimientos que operan sobre estos datos (mtodos u operaciones). Un objeto realiza una operacin cuando
recibe una peticin (mensaje) de un cliente.
Las peticiones son el nico modo de lograr que un objeto ejecute una operacin. Las operaciones son la nica forma
de cambiar los datos internos de un objeto. Debido a estas restricciones, se dice que el estado interno de un objeto
est encapsulado; no puede accederse a l directamente, y su representacin no es visible desde el exterior del
objeto.

Herencia
En la etapa de diseo la herencia se considera mucho ms que en el anlisis.
La herencia tiene ciertas caractersticas no deseables:

Es la mayor forma de acoplamiento posible entre dos clases.

El encapsulamiento es dbil dentro de una jerarqua de clases. Los cambios en la clase base provocan
cambios en las subclases.
Es un tipo muy inflexible de relacin. Las relaciones de herencia no se pueden cambiar en tiempo de
ejecucin. Cuando se necesita esto, se usa agregacin.

Ejemplo (Herencia vs Agregacin/Composicin)

En el primer caso el objeto :john es Programador, pero si quisiera despus pasar a ser Director, habra que crear un nuevo
objeto Director, copiar todos los datos de john:Programador y luego eliminar el objeto john:Programador para
mantener la consistencia de la aplicacin.
En cambio, en el segundo caso, utilizando agregacin se obtiene un modelo con semntica correcta, permitiendo cambiar a John
a director en tiempo de ejecucin. Para ello hay que cambiar el vnculo entre john:Empleado - :Programador a
john:Empleado - :Director.

- 76 -

Herencia mltiple
Algunas veces es posible que se desee heredar de ms de un padre. Esto es herencia mltiple y no es soportado en
todos los lenguajes de programacin orientados a objetos. Por ejemplo, Java y C# solamente permiten herencia
simple.
Esta restriccin de los lenguajes es importante porque una vez que aplicamos herencia a una clase, la subclase no va
a poder heredar de otra si lo necesitamos. Suele sustituirse por el uso de interfaces.

La herencia no es la nica opcin

Delegacin: delegar comportamiento a otra clase cuando no quiere cambiar el comportamiento, pero no es
su responsabilidad de sus objetos implementar ese comportamiento por s mismos.
Composicin: puede reusar el comportamiento de una o ms clases, y en particular de una familia de clases,
con composicin. El objeto posee completamente a los objetos compuestos y ellos no existen fuera del uso
del objeto.
Agregacin: cuando se requieren los beneficios de la composicin pero se utiliza el comportamiento de un
objeto que existe ms all del objeto que lo uso.

Clase abstracta
Son clases que tiene algunos (o todos) sus mtodos abstractos, o sea sin implementar. Esos mtodos deben ser
implementados por las clases hijas. Las clases abstractas no se pueden instanciar. Las clases que no son abstractas
se denominan concretas.

Interfaz
Una interfaz especifica un conjunto de caractersticas pblicas. La idea es separar la especificacin de funcionalidad
(la interfaz) de su implementacin por un clasificador como una clase o subsistema. Una interfaz no se puede
instanciar; simplemente declara un contrato que se puede realizar por cero o ms clasificadores.

Herencia vs composicin
Herencia: permite definir una implementacin en trminos de otra. A esto se lo denomina reutilizacin de caja
blanca. Este trmino se refiere a la visibilidad con la herencia, ya que las interioridades de las clases padres suelen
hacerse visibles a las subclases.
Composicin: la funcionalidad se obtiene ensamblando o componiendo objetos para obtener funcionalidad ms
compleja. La composicin se objetos requiere que los objetos a componer tengan interfaces bien definidas. A este
tipo de reutilizacin se lo denomina reutilizacin de caja negra, porque los detalles internos de los objetos no son
visibles.

- 77 -

HERENCIA
COMPOSICIN
Ventajas
Ventajas
Se define en tiempo de compilacin.
Se define en tiempo de ejecucin (con objetos
que hacen referencia a otros objetos).
Es sencilla de utilizar (se implementa
directamente en el lenguaje de programacin).
Requiere objetos con interfaces bien
diseadas, dado que a los objetos se accede a
Fcil modificar la implementacin que est
travs de sus interfaces.
siendo utilizada.
No rompe el encapsulamiento (por lo del punto
Desventajas
anterior, las interfaces).
No se pueden cambiar las implementaciones
Cualquier objeto puede ser reemplazado por
heredades de las clases padre en tiempo de
otro en tiempo de ejecucin siempre que sean
ejecucin (se define en tiempo de compilacin).
del mismo tipo.
Rompe el encapsulamiento (lo detalles del

Las dependencias de implementacin son

padre son expuestos a las subclases).
menores.
Alto acoplamiento (los cambios en las clases
Se mantiene el encapsulamiento y cada clase se
padre obliga a cambiar las subclases).
centra en una tarea.
El comportamiento del sistema depende de las
relaciones en vez de estar definido en las clases.

Herencia de clases vs herencia de interfaces

Clase: la clase de un objeto define como se implementa el objeto.

Tipo: el tipo de un objeto slo se refiere a su interfaz (al conjunto de peticiones que puede responder).

Un objeto puede tener muchos tipos, y objetos de clases diferentes pueden tener el mismo tipo.
Herencia de clases (generalizacin): define la implementacin de un objeto en trminos de la implementacin de
otro objeto. Es un mecanismo para compartir cdigo y representacin.
Herencia de interfaces (realizacin): describe cuando se puede usar un objeto en lugar de otro.

Programar para interfaces, no para una implementacin

La herencia de clases no es ms que un mecanismo para extender la funcionalidad de una aplicacin reutilizando la
funcionalidad de las clases padres. Define rpidamente un nuevo tipo de objeto basndose en otro.
Tambin es importante la capacidad de la herencia para definir familias de objetos con interfaces idnticas, al ser
esto en lo que se basa el polimorfismo.
Cuando la herencia se usa con cuidado, todas las clases que derivan de una clase abstracta compartirn su interfaz.
Esto implica que las subclases aaden o redefinen operaciones y no ocultan operaciones de la clase padre. Todas las
subclases pueden entonces responder a las peticiones en la interfaz de su clase abstracta, convirtindose as todas
ellas en subtipos de la clase abstracta.
Manipular los objetos solamente en trminos de la interfaz definida por las clases abstractas tiene dos ventajas:
1. Los clientes no tienen que conocer los tipos especficos de los objetos que usan, basta que con stos se
adhieran a la interfaz que esperan los clientes.
2. Los clientes desconocen las clases que implementan dichos objetos; slo conocen las clases abstractas que
definen la interfaz.
Esto reduce las dependencias de implementacin entre subsistemas, llevando al principio Programe para una
interfaz, no para su implementacin. Es decir, no se deben declarar variables como instancias de clases concretas.
En vez de eso, se ajustarn a la interfaz definida por una clase abstracta (o interfaz).
Los patrones de creacin aseguran que el sistema se escriba en trminos de interfaces, no de implementaciones.
- 78 -

Delegacin
La delegacin es un modo de lograr que la composicin sea tan potente para la reutilizacin
como lo es la herencia. Dos son los objetos encargados de tratar una peticin: un objeto
receptar delega operaciones a su delegado.

class Herencia

La principal ventaja de la delegacin es que se hace que sea fcil combinar

comportamientos en tiempo de ejecucin y cambiar la manera en que stos se combinan.

Rectangulo
-

ancho: int
alto: int

area() : int

Se utiliza mejor cuando se quiere usar la funcionalidad de una clase tal cual es, sin cambiar
su comportamiento para nada.
Es una alternativa a la herencia que no viola el principio de sustitucin.

Ventana

La delegacin tiene un inconveniente: el software dinmico y altamente parametrizado es

ms difcil de entender que el esttico. Hay tambin ineficiencias en tiempo de ejecucin.
La delegacin es una buena eleccin de diseo solo cuando simplifica ms de lo que complica.
Varios patrones de diseo utilizan la
delegacin, algunos son el State, Stretegy y
Visitor.

Rectangulo

En la delegacin, un objeto le delega la

totalidad de la tarea a un objeto distinto
para que la realice. Ejemplo: patrn State y
Strategy.

area() : int

class Dlegacion

Ventana

Delegacin vs. Colaboracin

area() : int

return rectangulo.area()

rectangulo

1 -

ancho: int
alto: int

area() : int

return ancho * alto

En la colaboracin, un objeto le pide a otro

objeto que haga una parte de la tarea (este a su vez puede pedirle a otro y as sucesivamente, formando una
cadena), entregndole un valor de retorno al objeto que invoc la tarea (y a travs de la cadena si hay) hasta
retornar un valor en el primer objeto. Ejemplo: cuando un gestor tiene que hacer algo, y pide a otro objeto que haga
algo (y este a otros), pero siempre termina el valor de retorno en el gestor. Esto se ve claramente en el diagrama de
comunicacin.

PATRONES DE DISEO
Introduccin
Disear software orientado a objetos es difcil, y an lo es ms disear software orientado a objetos reutilizable.
Nuestro diseo debe ser especfico del problema que estamos manejando, pero tambin lo suficientemente general
para adecuarse a futuros requerimientos y problemas. Tambin queremos evitar el rediseo, o al menos
minimizarlo.
Lo que no hay que hacer es resolver cada problema partiendo de cero. Por el contrario, hay que reutilizar soluciones
que ya han sido tiles en el pasado. Cuando se encuentra una solucin buena, se usa una y otra vez.
Los patrones resuelven estos problemas concretos de diseo y hacen que los diseos orientados a objetos sean ms
flexibles, elegantes y reutilizables. Los patrones ayudan a los diseadores a reutilizar buenos diseos al basar los
nuevos diseos en la experiencia previa.
Cada patrn nomina, explica y evala un diseo importante y recurrente en los sistemas orientados a objetos. El
objetivo, es representar esa experiencia de diseo de forma que pueda ser reutilizada de manera efectiva por otras
personas.
- 79 -

Los patrones de diseo hacen que sea ms fcil reutilizar buenos diseos y arquitecturas.
Los patrones de diseo nos ayudan a elegir alternativas de diseo que hacen que un sistema sea reutilizable,
y a evitar fallas que dificultan dicha reutilizacin.
Pueden mejorar la documentacin y mantenimiento de sistemas existentes.
Los patrones de diseo ayudan a lograr un buen diseo ms rpidamente.

Qu es un patrn de diseo
Patrn: cada patrn describe un problema que ocurre una y otra vez en un determinado entorno, as como la
solucin a ese problema, de tal modo que se pueda aplicar esta solucin un milln de veces, sin hacer lo mismo dos
veces.

Elementos de un patrn de diseo

1. Nombre: describe con una o dos palabras un problema de diseo junto con sus soluciones y consecuencias.
o Incrementan el vocabulario de diseo: nos permite hablar con otros colegas, mencionarlos en
documentacin y tenerlos en cuenta. Ms fcil pensar diseos y transmitirlos a otros.
o Nos permiten disear con abstraccin de un nivel ms alto.
2. Problema: describe cuando aplicar el patrn. Explica el problema y su contexto.
3. Solucin: describe los elementos que forman el diseo, sus relaciones, responsabilidades y colaboraciones.
o No describe ningn diseo concreto.
o Es como una plantilla que puede aplicarse en muchas situaciones diferentes.
4. Consecuencias: son los resultados as como las ventajas e inconvenientes de aplicar el patrn.
o Son crticas para evaluar el patrn y entender los costos y beneficios de aplicarlo.
o Suele relacionar el equilibrio entre el espacio y el tiempo.
o Puede tratar asuntos de lenguajes e implementaciones.

Descripcin de los patrones de diseo (plantilla de definicin)

Cada patrn se divide en secciones de acuerdo a la siguiente plantilla:

Nombre del patrn y clasificacin

o El nombre del patrn transmite su esencia.
Propsito
o Frase que responde a lo siguiente: Qu hace este patrn? En qu se basa? Cul es el problema
concreto que resuelve?
Tambin conocido como (sinnimos)
o Otros nombres
Motivacin
o Escenario que ilustra un problema particular y cmo el patrn lo resuelve.
Aplicabilidad
o En qu situaciones se puede aplicar? Cmo se reconocen? Ejemplos de diseos que pueden
mejorarse.
Estructura
o Diagrama de clases es ilustra la estructura.
Participantes
o Clases que participan y sus responsabilidades.
Colaboraciones
o Diagramas de interaccin que muestran cmo colaboran los participantes.
Consecuencias
o Cmo alcanza los objetivos el patrn? Ventajas e inconvenientes, alternativas.
Implementacin
- 80 -

o Dificultades, trucos o tcnicas que deberamos tener en cuenta al aplicar el patrn.

Ejemplo de cdigo
o El patrn implementado en algn lenguaje de programacin como Java, C++, etc.
Usos conocidos
o Ejemplos del patrn en sistemas reales.
Patrones relacionados
o Patrones estrechamente relacionados con el patrn analizado. Diferencias, alternativas, etc.

A qu ayudan los patrones?

1.
2.
3.
4.
5.
6.

Encontrar los objetos apropiados.

Determinar la granularidad de los objetos.
Especificar interfaces de objetos.
Especificar implementaciones de objetos.
Favorecer reutilizacin.
Disear para el cambio.

Encontrar los objetos apropiados

Lo ms complicado del diseo orientado a objetos es descomponer un sistema en objetos. Es difcil porque entran
en juego muchos factores: encapsulamiento, granularidad, dependencia, flexibilidad, rendimiento, reutilizacin, etc.
Muchos objetos de un diseo proceden del modelo de anlisis. Pero los diseos orientados a objetos suelen acabar
teniendo clases que no tienen su equivalente en el mundo real. Algunas de ellos son de bajo nivel como los arrays,
otras son de mucho ms alto nivel, estas son clases de fabricacin pura. Las abstracciones que surgen durante el
diseo son fundamentales para lograr un diseo flexible.
Los patrones de diseo ayudan a identificar abstracciones menos obvias y los objetos que las expresan. Algunos son:
Strategy y State.

Determinar la granularidad de los objetos

Los objetos pueden variar enormemente de tamao y nmero. Pueden representar cualquier cosa. Cmo
decidimos entonces qu debera ser un objeto? Los patrones de diseo tambin se encargan de sta cuestin.
Ejemplos: Facade, Flyweight, Builder, etc.

Especificar las interfaces de los objetos

Cada operacin declarada por un objeto especifica el nombre de la operacin, los objetos que toma como
parmetros y el valor de retorno de la operacin. Esto se lo conoce como signatura o firma. Al conjunto de todas las
firmas definidas por las operaciones de un objeto se le denomina interfaz del objeto. Dicha interfaz caracteriza el
conjunto de peticiones que se puede enviar al objeto.
Las interfaces son fundamentales en el diseo orientado a objetos, ya que los objetos slo se conocen a travs de
su interfaz. La interfaz de un objeto no dice nada acerca de su implementacin (dos objetos con implementaciones
diferentes pueden tener interfaces idnticas).
Objetos diferentes que soportan peticiones idnticas pueden tener distintas implementaciones de las operaciones
que satisfacen esas peticiones. La asociacin en tiempo de ejecucin entre una peticin a un objeto y una de sus
operaciones es lo que se conoce como enlace dinmico.
El enlace dinmico significa que para enviar una peticin no nos liga a una implementacin particular hasta el tiempo
de ejecucin. Esto no permite escribir programas que esperen un objeto con una determinada interfaz, sabiendo
que cualquier objeto que tenga la interfaz correcta aceptar la peticin. El enlace dinmico nos permite sustituir
objetos en tiempo de ejecucin por otros que tengan la misma interfaz (polimorfismo). El polimorfismo simplifica
- 81 -

las defunciones de los clientes, desacopla unos objetos de otros y permite que varen las relaciones entre ellos en
tiempo de ejecucin.
Los patrones de diseo nos ayudan a definir interfaces identificando sus elementos clave y los tipos de datos que se
envan a la interfaz. Un patrn de diseo tambin puede decir qu no debemos poner en la interfaz. Ejemplo:
Memento.
Los patrones de diseo tambin especifican relaciones entre interfaces. Ejemplo: Decorator, Proxy.

Especificar las implementaciones de los objetos

La implementacin de un objeto queda definida por su clase. La clase especifica los datos, la representacin interna
del objeto y define las operaciones que puede realizar. Definimos implementaciones a partir de otras (herencia).

Programar para interfaces, no para una implementacin.

Herencia de clases vs Herencia de interfaces.
No declarar variables de clases concretas sino abstractas (o interfaces).
Patrones de creacin permiten que un sistema est basado en trminos de interfaces y no en
implementaciones.
Favorece reutilizacin.
Delegacin.

Favorecer reutilizacin

Herencia vs composicin.
Delegacin.
Tipos parametrizados (generics en Java). Ejemplo: List<Integer> enteros; Set<Persona> personas;

Disear para el cambio

La clave para maximizar la reutilizacin reside en anticipar nuevos requerimientos y cambios en los requerimientos
existentes, y en disear los sistemas de manera que puedan evolucionar en consecuencia.
Un diseo que no tenga en cuenta el cambio sufre el riesgo de tener que ser rediseado por completo en el futuro.
Los patrones de diseo ayudan a evitar esto al asegurar que un sistema pueda cambiar de formas concretas.
Toolkits
Un toolkit es un conjunto de clases relacionadas y reutilizables diseadas para proporcionar funcionalidad til de
propsito general. Los toolkits no imponen un diseo particular en una aplicacin, solo proporcionan funcionalidad
que puede ayudar a que la aplicacin haga su trabajo. Nos permiten evitar recodificar funcionalidad comn. Los
toolkits se centran en la reutilizacin de cdigo.
Frameworks
Un framework es un conjunto de clases cooperantes que constituyen un diseo reutilizable para una clase especfica
de software.
El framework determina la arquitectura de nuestra aplicacin. Definir la estructura general, su particin en clases
y objetos, las responsabilidades clave, como colaboran las clases y objetos y el hilo de control.
Los frameworks hacen hincapi en la reutilizacin del diseo frente a la reutilizacin de cdigo. La reutilizacin a
este nivel lleva a una inversin de control (IoC) entre la aplicacin y el software en el que se basa.
Como resultado, no slo se pueden construir aplicaciones ms rpidamente, sino que las aplicaciones tienen
estructuras parecidas, por lo que son ms fciles de mantener y resultan ms consistentes para los usuarios. Por
- 82 -

otro lado, perdemos algo de libertad creativa, puesto que muchas decisiones de diseo ya han sido tomadas por
nosotros.
Frameworks vs patrones
1. Los patrones de diseo son ms abstractos que los frameworks. Los frameworks pueden plasmarse en
cdigo mientras que en los patrones solo los ejemplos pueden plasmarse en cdigo.
2. Los patrones de diseo son elementos arquitectnicos ms pequeos que los frameworks. Un framework
contiene varios patrones de diseo, pero lo contrario nunca es cierto.
3. Los patrones de diseo estn menos especializados que los frameworks. Los frameworks siempre tienen un
dominio de aplicacin concreto.

Cmo seleccionar un patrn de diseo?

Considera de qu forma los patrones resuelven problemas de diseo.

Lee la seccin que describe el propsito de cada patrn.
Estudia las interrelaciones entre patrones.
Analiza patrones con el mismo propsito.
Examina las causas de redisear.
Considera que debera ser variable en tu diseo.

Cmo usar un patrn?

Lee el patrn, todos sus apartados.

Obtenga una visin global.
Estudia la estructura, participantes y colaboraciones.
Mira el ejemplo de cdigo.
Asocia a cada participante del patrn un elemento software de tu aplicacin.
Implementa las clases y mtodos relacionados con el patrn.

Clasificacin
PROPSITO

MBITO

Clase

Creacin

Estructural

Comportamiento

Factory Method

Adapter (de clases)

Abstract Factory
Builder
Prototype
Singleton

Adapter (de objetos)

Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Interpreter
Template Method
Chain of Responsability
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Objeto

Patrones de creacin
Los patrones de diseo de creacin abstraen el proceso de creacin de instancias (de objetos). Ayudan a hacer un
sistema independiente de cmo se crean, se componen y se representan sus objetos.
Dos tipos:

Patrn de creacin de clase: usa la herencia para cambiar la clase que es instanciada.
Patrn de creacin de objeto: delega la creacin de la instancia a otro objeto.
- 83 -

Hay dos temas recurrentes en estos patrones:

Todos encapsulan el conocimiento sobre las clases concretas que usa el sistema.
Todos ocultan como se crean y se asocian las instancias de estas clases.

Todo lo que el sistema conoce de los objetos son sus interfaces. Por lo tanto, da mucha flexibilidad a qu es lo que
se crea, quin lo crea y cuando.

Patrones de creacin
1. Abstract Factory: proporciona una interfaz para crear familias de objetos relacionados o que dependen
entre s, sin especificar sus clases concretas.
2. Factory Method: define una interfaz para crear un objeto, pero deja que las subclases decidan qu clase
instanciar. Delega en las subclases la creacin de objetos.
3. Singleton: garantiza que una clase tenga una nica instancia y proporciona un punto de acceso global a ella.
4. Builder: separa la construccin de un objeto complejo de su representacin, de forma que el mismo proceso
de construccin pueda crear diferentes representaciones.
5. Prototype: especifica los tipos de objeto a crear por medio de una instancia prototpica, y crea nuevos
objetos copiando de este prototipo.

Patrones de estructura
Los patrones estructurales se ocupan de cmo se combinan las clases y objetos para formar estructuras ms grandes
y complejas.
Dos tipos:

Patrones estructurales de clase: hacen uso de la herencia ara componer interfaces o implementaciones.
Patrones estructurales de objeto: describen formas de componer objetos para obtener nueva
funcionalidad. Hacen uso de la composicin.

Patrones de estructura
1. Adapter: convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permite que
cooperen clases que de otra forma no podran por tener interfaces incompatibles.
2. Bridge: desacopla una abstraccin de su implementacin, de manera que ambas puedan variar de forma
independiente.
3. Composite: combina (compone) objetos en estructuras de rbol para representar jerarquas de todo-parte.
Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
4. Decorator: aade dinmicamente nuevas responsabilidades a un objeto, proporcionando una alternativa
flexible a la herencia para extender funcionalidad.
5. Facade: proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una
interfaz de alto nivel que hace que el subsistema sea ms fcil de usar.
6. Flyweight: usa comportamiento para permitir un gran nmero de objetos de granularidad fina de forma
eficiente.
7. Proxy: proporciona un sustituto o representante de otro objeto para controlar el acceso a ste.

Patrones de comportamiento
Los patrones de comportamiento tienen que ver con algoritmos y con la asignacin de responsabilidades a objetos.
No slo describen patrones de clases y objetos, sino tambin patrones de comunicacin entre ellos.
Dos tipos:

Patrones de comportamiento de clase: usan la herencia para distribuir el comportamiento entre clases.
- 84 -

Patrones de comportamiento de objeto: usan la composicin de objetos en vez de la herencia.

Las claves son cooperaciones entre objetos para realizar tareas complejas que por s solos no podran realizar,
reduciendo la dependencia entre objetos (Iterator, Observer, etc.); y, asociar comportamiento a objetos e invocar
su ejecucin (Command, Strategy, etc.).

Patrones de comportamiento
1. Chain of responsability: evita acoplar el emisor de una peticin a su receptor, dando a ms de un objeto la
posibilidad de responder la peticin. Crea una cadena con los objetos receptores y pasa la peticin a travs
de la cadena hasta que sta sea tratada por algn objeto.
2. Command: encapsula una peticin en un objeto, permitiendo as parametrizar a los clientes con diferentes
peticiones, encolar o llevar un registro de las peticiones y poder deshacer las operaciones.
3. Interpreter: dado un lenguaje, define una representacin de su gramtica junto con un intrprete que usa
dicha representacin para interpretar sentencias del lenguaje.
4. Iterator: proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin
exponer a su representacin interna.
5. Mediator: define un objeto que encapsula cmo interactan una serie objetos. Promueve un bajo
acoplamiento al evitar que los objetos se refieran unos a otros explcitamente, y permite variar la interaccin
entre ellos de forma independiente.
6. Memento: representa y externaliza el estado interno de un objeto sin violar el encapsulamiento, de forma
que ste pueda volver a dicho estado ms tarde.
7. Observer: define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie
de estado se notifique y se actualicen automticamente todos los objetos que dependen de l.
8. State: permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
Parecer que cambia la clase del objeto.
9. Strategy: define una familia de algoritmos, encapsula cada uno de ellos y los hace intercambiables. Permite
que un algoritmo vare independientemente de los clientes que lo usan.
10. Template Method: define en una operacin el esqueleto de un algoritmo, delegando en las subclases
algunos de sus pasos. Permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su
estructura.
11. Visitor: representa una operacin sobre los elementos de una estructura de objetos. Permite definir una
nueva operacin sin cambiar las clases de los elementos sobre los que opera.
(Para ms detalles ver el libro de patrones de diseo de Gamma y/o las filminas de la Meles)

DISEO DE PERSISTENCIA (BASES DE DATOS)

Introduccin
La necesidad de usar una base de datos proviene de la capacidad limitada de la memoria primaria (RAM). Las bases
de datos se almacenan frecuentemente sobre almacenamiento secundario (discos rgidos), proveyendo maneras
eficientes de acceder a los datos. Otra necesidad proviene de almacenar objetos mayores que una ejecucin de
programa (que el objeto sobreviva a la ejecucin que lo cre). Esta capacidad se llama persistencia. La persistencia
frecuentemente significa que los objetos se copian desde una memoria primaria rpida y voltil a una memoria
secundaria, lenta y persistente.

DBMS
Necesitamos un sistema de gestin de bases de datos (DBMS) que maneje el almacenamiento en la base de datos.
El programador solo quiere una vista lgica de la base de datos y no tomar decisiones sobre cmo se hace el
almacenamiento fsico.
- 85 -

Un DBMS debera proveer:

Concurrencia: permite a mltiples usuarios trabajar con una base de datos comn simultneamente.
Recuperacin: si ocurre una falla (hardware o software), el DBMS debera ser capaz de volver la base de
datos a un estado uniforme de datos.
Facilidad de consulta: el DBMS debera soportar una manera fcil de acceso a los datos en la base de datos.

Propiedades tpicas que indican necesidad de un DBMS

La informacin necesita ser persistente.

Ms de una aplicacin compartiendo (parte de) los datos.
La estructura de la informacin con un gran nmero grande de instancias.
Bsquedas complejas en la estructura de informacin.
Generacin avanzada de informes desde la informacin almacenada.
Manipulacin de transacciones de usuario.
Un registro para el reinicio de sistema.

Qu objetos necesitan persistencia

Los modelos de anlisis y de requerimientos pueden estudiarse para decidir qu objetos van a ser persistentes. Los
objetos de entidad son los candidatos importantes para el almacenamiento persistente.

Modelos de datos
Los DBMSs han evolucionado mediante un nmero de generaciones incluyendo modelos de datos jerrquicos, de
red, relacionales y orientados a objetos. El modelo de datos dominante en aplicaciones industriales en la actualidad
es el modelo relacional.

Modelo relacional y problema de impedancia

En una base de datos relacional, los datos se almacenan en tablas. Los tipos a ser usados en las tablas son
mayormente los tipos primitivos (caracteres, enteros, reales, etc.). Esto trae problemas a la hora de almacenar
objetos.

Problema de impedancia
Se refiere al problema de guardar objetos en un modelo relacional:

En una base de datos relacional solo se guardan los datos, no el comportamiento.

En una base de datos relacional solo se pueden almacenar datos primitivos y no objetos complejos.

Como se trabaja en un lenguaje de programacin orientado a objetos, toda nuestra informacin se almacena en
objetos, por lo tanto, necesitamos transformar nuestra estructura de informacin de objeto a una estructura
orientada a tablas (modelo relacional). Este problema se denomina problema de impedancia.
El problema principal viene con los objetos complejos (objetos que tienen comportamiento, y poseen atributos que
adems de poder ser primitivos, pueden ser complejos, o sea atributos que hacen referencia a otros objetos). Todos
estos tipos deben convertirse a los tipos de datos primitivos del RDBMS (Modelo de Bases de Datos Relacional).
El problema de impedancia trata an otro problema: crea un fuerte acoplamiento entre la aplicacin y el DBMS. Para
ello, pocas partes de nuestro sistema (lo mnimo posible) deberan saber sobre la interface del DBMS.
Un tercer problema es cmo expresar la herencia en la base de datos.
Otros problemas que provienen incluyen como almacenar operaciones, la vista de transaccin, bloqueo de datos
durante transacciones ms largas y distribucin.
- 86 -

En resumen:

Problema al almacenar objetos complejos (comportamiento y atributos con referencia a otros objetos). Los
datos deben ser primitivos.
Problema para representar la herencia.
Fuerte acoplamiento entre la aplicacin y el DBMS.

Objetos en tablas
La primera cosa para hacer es determinar que clases y variables de la clase deben almacenarse en la base de datos.
Cada una de estas clases entonces ser representada por una tabla (por lo menos una) en la base de datos.
Una clase se mapea en tablas de la siguiente manera:
1. Asignar una tabla para la clase.
2. Cada atributo primitivo se transformar en una columna en la tabla. Si el atributo es complejo, agregamos
una tabla adicional para el atributo, o distribuimos el atributo en varias columnas de la tabla de la clase.
3. La columna de la clave primaria ser el identificador nico de la instancia. El identificador debe ser
preferentemente invisible al usuario y generadas automticamente por mquina.
4. Cada instancia de la clase ser representada por una fila en la tabla.
5. Cada asociacin de conocimiento con una cardinalidad mayor que 1 (0..N por ejemplo)se transformar en
una nueva tabla. Esta nueva tabla conectar las tablas que representan los objetos que van a ser asociados
mediante el identificador de la clave primaria. En algunos casos, podemos tener la relacin representada
como una columna (atributo) en la tabla del objeto asociado.

Normalizacin
La normalizacin de la base de datos consiste en el hecho de eliminar redundancia en la base de datos y evitar ciertas
anomalas en la actualizacin. En la mayora de los casos es suficiente con alcanzar la tercera forma normal (3FN)
para el diseo de bases de datos. Un diseo de bases de datos basado en un modelo de objetos acabar
normalmente en 3FN desde el comienzo. La 3FN afirma que, si y solo si para todas las veces, cada fila consiste de un
nico objeto identificador junto con un nmero de valores de atributos mutuamente independientes, entonces la
tabla est en 3FN.
Cuando la base de datos est normalizada, el problema de la baja performance ocurre. La baja performance puede
resolverse en muchos casos con tablas de indexado especial. Si es no es posible, el problema verdadero es
desnormalizar la base de datos para aumentar su performance. En este caso podemos tener problemas de
redundancia en la base de datos.

class modelo de obj etos

Calificacion

Elenco

Pelicula
calificacion

nombre: String
descripcion: String 1

elenco
-

1..* -

nombre: String
aoEstreno: int

nombre: String
animado: boolean

pelicula

Programacion

Funcion
funcion
-

fecha: Date
horaInicio: int

- 87 -

1..*

fechaInicio: Date
fechaFin: Date

Herencia
Si las clases se heredan unas a otras, hay principalmente tres maneras diferentes de resolver esto:
1. Tablas nicas para los objetos hijos. Se copian todos los atributos de la clase padre. Ninguna tabla representa
la clase abstracta.
o Es ms rpida ya que los datos estn en una sola tabla (no hay que hacer JOIN)
o El tamao de la base de datos aumenta ya que se duplican columnas.
o Puede traer problemas de consistencia y redundancia.
2. La clase abstracta est en su propia tabla y las tablas de los hijos hacen referencia a ella.
o Reduce la redundancia.
o Requiere hacer JOINs que pueden reducir la performance.
3. Eliminar hijos y poner los atributos de todas las clases hijas en una sola tabla (no recomendado).
Ejemplo

class temp

Persona
-

dni
nombre
apellido

Alumno
-

Docente

legajo
carrera
tituloSecundario

- 88 -

profesion
legajo
materiaDicta

Segn el primer caso quedara:

Aqu siempre hay que mantener la

consistencia en caso de que un
Alumno sea tambin Docente.

Segn el segundo caso:

En este caso siempre hay que hacer JOIN.

Deberamos usar un DBMS que tenga buena
performance en JOIN.

Segn el tercer caso (no debera ser usado):

Si se quiere almacenar un alumno se dejan los datos

de docente en null o viceversa.

Materializacin y Desmaterializacin

Materializacin: una o varias filas de tablas (registros) de la base de datos son convertidos a objetos en
memoria.
o Materializacin inmediata: recupera los objetos al instante.
o Materializacin perezosa: recupera los objetos cuando se los necesita realmente.
Desmaterializacin: proceso inverso, un objeto se graba en la base de datos en forma de uno o varios
registros (filas) de tablas.

DBMSs Orientados a Objetos

La idea de un DBMS orientado a objetos (ODBMS) es almacenar a los objetos como tales. De esta manera no tenemos
que realizar ninguna unin lenta para conseguir el acceso a un objeto especfico.
La mayora de los ODBMSs comerciales no usan un lenguaje de manipulacin de datos especfico para almacenar y
recobrar informacin, sino que usan el lenguaje de programacin directamente. O sea que no es necesaria una
interfaz especifica con el DBMS. As el problema de impedancia se elimina completamente. Esto tambin significa
que el diseo de la base de datos se integra durante el anlisis y el diseo de la aplicacin.
- 89 -

Qu criterios debe cubrir un DBMS orientado a objetos

1.
2.
3.
4.
5.
6.
7.
8.

Objetos complejos: debera soportar la nocin de objetos complejos.

Identidad de objetos: cada objeto debe tener una identidad independientemente de sus valores internos.
Encapsulamiento: debe soportar el encapsulamiento de datos y comportamiento de objetos.
Tipos o clases: debera soportar un mecanismo de estructuracin, en forma de tipos o clases.
Jerarqua: debera soportar la nocin de herencia.
Ligadura tarda: debera soportar sobreescritura y ligadura tarda.
Completitud: el lenguaje de manipulacin debera ser capaz de expresar cada funcin calculable.
Extensibilidad: debera ser posible agregar nuevos tipos.

Dado que los DBMSs relacionales se han usado desde hace mucho tiempo, estos productos son ms maduros y
tambin tienen un soporte extensivo a muchos puntos complejos incluido en el uso de bases de datos.

Ventajas de un DBMS orientado a objetos

Los objetos se almacenan en la base de datos como tales.

No se necesita ninguna conversin del tipo de sistema de DBMS; las clases definidas por el usuario se usan
como tipos en el DBMS.
El lenguaje del DBMS puede integrarse con un lenguaje de programacin orientado a objetos.

Diseo de persistencia
Un esquema de persistencia es un conjunto reutilizable (y, generalmente expansible)
de clases que prestan servicios a los objetos persistentes. Por lo general, un esquema
de persistencia debe traducir los objetos a registros y guardarlos en una base de
datos; despus traduce los registros a objetos cuando los recupera de una base.

Frameworks de persistencia

Es un conjunto extensible de clases e interfaces que colaboran para

proporcionar servicios de la parte central e invariable de un subsistema
lgico.
Contiene clases concretas y (especialmente) abstractas que definen las interfaces a las que ajustarse,
interacciones de objetos en las que participar, y otras variantes.
Pueden requerir que el usuario del framework defina subclases del framework para utilizar, adaptar y
extender los servicios del framework.
Tiene clases abstractas que podran contener tanto mtodos abstractos como concretos.
Confa en el Principio de Hollywood No nos llame, nosotros lo llamaremos.
Ofrecen un alto grado de reutilizacin, mucho ms que con clases individuales.

Debera proporcionar funciones para:

Almacenar y recuperar objetos en un mecanismo de almacenamiento persistente.

Confirmar y deschacer (commit y rollback) las transacciones.

Sper Objeto Persistente

Dado que cada objeto que debe almacenarse en la base de datos debe tener una funcionalidad de persistencia
comn, creamos un bloque abstracto que tiene esta funcionalidad. Las clases en este bloque abstracto forman un
framework. Este bloque es heredado por todos los bloques que deben poder almacenar informacin en la base de
datos y el framework se especializa para cada bloque particular.
Se corresponde con enfoque de correspondencia directa.
- 90 -

class temp

SuperObj etoPersistente
+
+
+
+

materializar()
desmaterializar()
buscar()
grabar()

Pedido
+
+
+
+

materializar()
desmaterializar()
buscar()
grabar()

La realizacin reemplaza a la
herencia (en rojo). Convirtiendo al
SuperObjetoPersistente en una
interfaz.

Cliente
+
+
+
+

Articulo

materializar()
desmaterializar()
buscar()
grabar()

+
+
+
+

Ventajas
Es rpida.
Es sencilla.

materializar()
desmaterializar()
buscar()
grabar()

Desventajas
Como la mayora de los lenguajes de
programacin OO slo permiten herencia
simple, impide que las clases hereden de otra.
Esto se soluciona mediante una realizacin
(implementacin de interfaz) haciendo al
SuperObjetoPersistente una interfaz.
Se abren las clases de domino para darles una
responsabilidad que naturalmente no les
corresponde (la persistencia, hacen SELECT,
INSERT, UPDATE, etc.). Esto disminuye la
cohesin.
Genera fuerte acoplamiento.

Detallado en el libro UML y Patrones de Craig

Larman. O si no en filminas de Judith Meles.

Esquema de persistencia
Ideas a desarrollar
1. Correspondencia (mapping): entre clases y tablas, ente atributos y campos. Es decir, correspondencia de
esquemas.
2. Identidad de objeto: identificador nico que vincula objetos con registros evitando duplicados.
3. Materializacin y desmaterializacin: transformar registros en objetos y objetos en registros.
4. Conversor de bases de datos: es el responsable de la materializacin y desmaterializacin de los objetos.
5. Cach: almacn de objetos materializados en esta memoria por cuestiones de rendimiento.
6. Estado de transaccin de los objetos: el estado de los objetos para saber si se modificaron en funcin de su
estado almacenado.
7. Operaciones de transaccin: confirmar y deshacer (commit y rollback).
8. Materializacin perezosa: no todos los objetos se materializan a la vez, se hace bajo demanda, es decir,
cuando se los necesita.
9. Proxies virtuales: referencia inteligente utilizada para la materializacin perezosa.

Patrn Identificador de Objetos

Es necesario contar con una forma consistente de relacionar objetos con registros y asegurar que la
materializacin repetida no de cmo resultado objetos duplicados.
El patrn propone asignar un identificador de objeto (OID, Object ID) a cada registro y objeto (o proxy de
objeto).
Sirve para identificar al objeto (al registro que los representa) en una tabla sin equivocacin.

Acceso al servicio de persistencia mediante Fachada

Patrn fachada: proporciona una interfaz uniforme a un subsistema.

Se necesita una operacin para recuperar un objeto dado un OID.
- 91 -

Tambin se necesita conocer el tipo del objeto que se va a materializar, por tanto, se debe proporcionar el
tipo de la clase a la que pertenece el objeto.
La fachada no hace el trabajo, solo lo delega en objetos del subsistema.

Patrn Conversor (Mapper) o Intermediario (Broker)

Enfoque de correspondencia indirecta.

Utiliza objetos para establecer la correspondencia con los objetos persistentes.
Propone crear una clase responsable de materializar y desmaterializar los objetos.
Se agrega un intermediario por cada clase de dominio (genera muchas clases, el doble).

Materializacin con el mtodo plantilla

La estructura bsica para materializar un objeto es:

if (objeto est en cach)
return objeto
else
crear objeto a partir de su representacin en el almacenamiento
guardar objeto en cach
return objeto

El punto de variacin es la manera de crear el objeto a partir del almacenamiento.

Con el patrn Template Method encapsulamos en una sola clase el comportamiento comn de la
materializacin.

Patrn Gestin de Cach

Es conveniente mantener los objetos materializados en una cach local para mejorar el rendimiento de y
dar soporta a las operaciones de gestin de transacciones.
Al materializar los objetos, quedan en la cach con su OID como clave.
El conversor primero busca en la cach para evitar materializaciones innecesarias.

Estados transaccionales y el Patrn State

Los objetos persistentes pueden insertarse, eliminarse o modificarse.

Operar sobre un objeto persistente no provoca una actualizacin inmediata sobre la base de datos, ms bien
debe ejecutar una operacin commit explcita.
Adems considerar que la respuesta a una operacin depende del estado de la transaccin del objeto.

- 92 -

Ejemplo
Un objeto sucio viejo debera actualizarse en la base de datos. Un viejo limpio no debera hacer nada porque no
ha cambiado.

Diseo de una transaccin con Patrn Command

Transaccin: unidad de trabajo (conjunto de tareas) cuya terminacin es atmica (se realizan todas las tareas
o ninguna).
En los servicios de persistencia se incluyen: insercin, actualizacin, eliminacin de objetos.
Una transaccin puede incluir por ejemplo: dos inserciones, una actualizacin, y tres eliminaciones.
Las tareas necesitan que se ordenen justo antes de la ejecucin.
La idea clave es representar cada tarea o accin de la transaccin como un objeto con un mtodo ejecutar()
polimrfico.

Lo que se busca con el patrn Command es crear un objeto por cada operacin a realizar en la transaccin, as se
puede crear una cola de operaciones (cola de objetos) permitiendo si es necesario hacer un rollback (deshacer los
cambios).

Materializacin perezosa mediante un Proxy Virtual

A veces es conveniente diferir la materializacin de los objetos hasta que sea absolutamente necesario, por
cuestiones de rendimiento.
La materializacin diferida de objetos se denomina materializacin perezosa.
Esta materializacin se puede implementar utilizando un Proxy Virtual.
Un Proxy Virtual es un proxy para otro objeto (el sujeto al que se quiere acceder realmente) que materializa
el sujeto real cuando se referencia por primera vez.
Este diseo se basa en la suposicin de que los proxies conocen el OID de sus sujetos reales, y cuando se
requiere la materializacin, se utiliza el OID para ayudar a identificar y recuperar el sujeto real.

WORKFLOW DE IMPLEMENTACIN
Introduccin
En la implementacin se comienza con el resultado del diseo e implementamos el sistema en trminos de
componentes, es decir, archivos de cdigo fuente, scripts, archivos de cdigo binario, ejecutables y similares.
El propsito fundamental de la implementacin es desarrollar la arquitectura el sistema como un todo.
El resultado principal de la implementacin es el modelo de implementacin.

- 93 -

Propsitos de la implementacin

Planificar las integraciones de sistema necesarias en cada iteracin. Se sigue un enfoque incremental, dando
lugar a un sistema que se implementa en una sucesin de pasos pequeos y manejables.
Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue.
Implementar las clases y subsistemas encontrados durante el diseo.
Probar los componentes individualmente, y a continuacin integrarlos compilndolos y enlazndolos a uno
o ms ejecutables.

El papel de la implementacin en el ciclo de vida del software

La implementacin es el centro durante las iteraciones de construccin, aunque tambin se lleva a cabo trabajo de
implementacin durante la fase de elaboracin, para crear la lnea base ejecutable de la arquitectura, y durante la
fase de transicin, para tratar defectos tardos.

Artefactos de la implementacin
1.
2.
3.
4.
5.
6.

Modelo de implementacin.
Componente.
Subsistema de implementacin.
Interfaz.
Descripcin de la arquitectura (vista del modelo de implementacin).
Plan de integracin de construcciones.

Modelo de implementacin
El modelo de implementacin describe cmo los elementos del modelo de diseo, como las clases, se implementan
en trminos de componentes, como ficheros de cdigo fuente, ejecutables, etc. Describe tambin cmo se organizan
los componentes de acuerdo con los mecanismos de estructuracin y modularizacin disponibles en el entorno de
implementacin y en el lenguaje o lenguajes de programacin utilizados, y cmo dependen los componentes unos
de otros.

Componente
Un componente es el empaquetamiento fsico de los elementos de un modelo, como son las clases en el modelo de
diseo. Algunos estereotipos estndar son:

<<executable>> es un programa que puede ser ejecutado en un nodo.

<<file>> es un fichero que contiene cdigo fuente o datos.
<<library>> es una librera esttica o dinmica.
- 94 -

<<table>> es una tabla de base de datos.

<<document>> es un documento.

Subsistema de implementacin
Los subsistemas de implementacin proporcionan una forma de organizar los artefactos del modelo de
implementacin en trozos ms manejables. Puede estar formado por componentes, interfaces, y otros subsistemas
(recursivamente).
Un subsistema de implementacin se manifiesta a travs de un mecanismo de empaquetamiento concreto en un
entorno de implementacin determinado, como

Un paquete en Java.
Un proyecto es Visual Basic.
Un directorio de ficheros en un proyecto de C++.
Un paquete en una herramienta de modelado como Rational Rose.

La semntica de la nocin de subsistema de implementacin se refinar ligeramente cuando se manifieste en un

entorno de implementacin determinado.
Los subsistemas de implementacin estn muy relacionados con los subsistemas de diseo en el modelo de diseo.
Los subsistemas de implementacin deberan seguir la traza uno a uno de sus subsistemas de diseo
correspondientes.

El subsistema de implementacin debera definir dependencias anlogas hacia otros subsistemas de

implementacin o interfaces.
El subsistema de implementacin debera proporcionar las misma interfaces.
El subsistema de implementacin debera definir qu componentes o, recursivamente, qu otros
subsistemas de implementacin dentro del subsistema deberan proporcionar las interfaces proporcionales
por el subsistema.

Interfaz
Utilizadas en el modelo de implementacin para especificar las operaciones implementadas por componentes y
subsistemas de implementacin.
Un componente que implementa (y por tanto proporciona) una interfaz ha de implementar correctamente todas las
operaciones definidas por la interfaz. Un subsistema de implementacin que proporciona una interfaz tiene que
tambin que contener componentes que proporcionen la interfaz u otros subsistemas (recursivamente) que
proporcionan la interfaz.

Descripcin de la arquitectura (vista del modelo de implementacin)

La descripcin de la arquitectura contiene una visin del modelo de implementacin, el cual representa sus
artefactos significativos arquitectnicamente.
Artefactos considerados significativos para la arquitectura en el modelo de implementacin:

La descomposicin del modelo en subsistemas, sus interfaces y las dependencias entre ellos.
Componentes clave, como los componentes que siguen la traza de las clases de diseo significativas
arquitectnicamente, los componentes ejecutables y los componentes que son generales, centrales, que
implementan mecanismos de diseo genricos de los que dependen muchos otros componentes.

Plan de integracin de construcciones

Es importante construir el software incrementalmente en pasos manejables, de forma que cada paso d lugar a
pequeos problemas de integracin o prueba. El resultado de cada paso es llamado construccin, que es una
- 95 -

versin ejecutable del sistema. Cada construccin es entonces sometida a pruebas de integracin antes de que se
cree ninguna otra construccin. Para prepararse ante un fallo de una construccin se lleva un control de versiones
de forma que se pueda volver atrs a una construccin anterior.
Cada iteracin resultara en al menos una construccin. Sin embargo, la funcionalidad a ser implementada en una
iteracin determinada es a menudo demasiado compleja para ser integrada en una sola construccin. En lugar de
esto, puede que se cree una secuencia de construcciones dentro de una iteracin, cada una de las cuales
representar un paso manejable en el que se hace un pequeo incremento al sistema.
Un plan de integracin de construcciones describe la secuencia de construcciones necesarias en una iteracin.
Describe lo siguiente para cada construccin:

La funcionalidad que se espera que sea implementada en dicha construccin.

Las partes del modelo de implementacin que estn afectadas por la construccin.

Trabajadores de la implementacin
1. Arquitecto.
2. Ingeniero de componentes.
3. Integrador de sistemas.

Arquitecto
El arquitecto es responsable de la integridad del modelo de implementacin y asegura que el modelo como un todo
es correcto, completo y legible.
El modelo es correcto cuando implementa la funcionalidad descrita en el modelo de diseo y en los requerimientos
adicionales, y solo esa funcionalidad.
El arquitecto es responsable tambin de la arquitectura del modelo de implementacin, es decir, de la existencia de
sus partes significativas arquitectnicamente.
Un resultado importante de la implementacin es la asignacin de componentes ejecutables a nodos. El arquitecto
es responsable de esta asignacin, la cual se representa en la vista de la arquitectura del modelo de despliegue.

Ingeniero de componentes
El ingeniero de componentes define y mantiene el cdigo fuente de uno o varios componentes, garantizando que
cada componente implementa la funcionalidad correcta.
A menudo, el ingeniero de componentes tambin mantiene la integridad de uno o varios subsistemas de
implementacin. Ya que los subsistemas de implementacin siguen la traza uno a uno a los subsistemas de diseo.,
necesita garantizar que los contenidos de los subsistemas de implementacin son correctos, que sus dependencias
con otros subsistemas o interfaces son correctas y que implementan correctamente las interfaces que proporciona.
Un ingeniero de componentes debera, disear e implementar las clases bajo su responsabilidad.

Integrador de sistemas
Entre sus responsabilidades se incluye planificar la secuencia de construcciones necesarias en cada iteracin y la
integracin de cada construccin cuando sus partes han sido implementadas. La planificacin da lugar a un plan de
integracin de construcciones.

- 96 -

Flujo de trabajo (actividades)

1. Este proceso es iniciado por el arquitecto esbozando los componentes clave en el modelo de
implementacin.
2. El integrador de sistemas planea las integraciones de sistema necesarias en la presente iteracin como una
secuencia de construcciones. Para cada construccin, el integrador de sistemas describe la funcionalidad
que debera ser implementada y que partes del modelo de implementacin se vern afectadas.
3. Los ingenieros de componentes implementan los requerimientos sobre los subsistemas y componentes en
la construccin.
4. Los componentes son probados y pasados al integrador de sistemas para su integracin. El integrador de
sistemas integra los nuevos componentes en una construccin y pasa a los ingenieros de pruebas de
integracin para llevar a cabo pruebas de integracin.
5. Los desarrolladores inician la implementacin de la siguiente construccin, tomando en consideracin los
defectos de la construccin anterior.

Implementacin de la arquitectura (por arquitecto)

Es esbozar el modelo de implementacin y su arquitectura mediante:

La identificacin de componentes significativos arquitectnicamente, tales como componentes ejecutables.

La asignacin de componentes a los nodos en las configuraciones de redes relevantes.

La identificacin de los subsistemas de implementacin y sus interfaces es ms o menos trivial y por lo tanto no se
trata aqu (traza uno a uno con los subsistemas de diseo y proporcionan las mismas interfaces).

- 97 -

Durante esta actividad, arquitecto mantiene, refina y actualiza la descripcin de la arquitectura y las vista de la
arquitectura de los modelos de implementacin y de despliegue.

Integrar el sistema (por integrador de sistemas)

Los objetivos de la integracin del sistema son:

Crear un plan de integracin de construcciones que describa las construcciones necesarias en una iteracin
y los requerimientos de cada construccin.
Integrar cada construccin antes de que sea sometida a pruebas de integracin.

Planificacin de una construccin

Se discute como planificar los contenidos de una construccin, independientemente de que partamos de una
construccin previa o de no partamos de ninguna. Suponemos que tenemos un nmero de casos de uso o
escenarios y otros requerimientos que han de ser implementados en la iteracin actual.
Criterios para crear una construccin:

Una construccin debera aadir funcionalidad a la construccin previa implementando casos de uso
completos o escenarios de stos.
Una construccin no debera incluir demasiados componentes nuevos o refinados. Si no es as, puede
ser muy difcil integrar la construccin y llevar a cabo las pruebas de integracin.
Una construccin debera estar basada en la construccin anterior, y debera expandirse hacia arriba y
hacia los lados en la jerarqua de subsistemas. Esto significa que la construccin inicial debera empezar
en capas inferiores; las construcciones subsiguientes se expanden entonces hacia arriba a las capas
generales de aplicacin. Esto es porque es difcil implementar componentes en las capas superiores
antes de que estn colocados y funcionando los componentes necesarias en las capas inferiores.

Los resultados deberan estar recogidos en el plan de integracin de la construccin y ser comunicados a los
ingenieros de componentes responsables de los subsistemas y componentes de implementacin afectados. Los
ingenieros de componentes pueden entonces empezar a implementar los requerimientos de los subsistemas y
componentes de implementacin en la construccin actual y llevar a cabo las pruebas individuales de cada
unidad.
Integracin de una construccin
Esto se hace recopilando las versiones correctas de los subsistemas de implementacin y de los componentes
compilndolos y enlazndolos para generar una construccin.

- 98 -

Implementar un subsistema (por ing. de componentes)

El propsito de implementar un subsistema es el de asegurar que un subsistema cumple su papel en cada
construccin, tal y como se especifica en el plan de integracin de la construccin. Esto quiere decir que se asegura
que los requerimientos implementados en la construccin y aquellos que afectan al subsistema son implementados
correctamente por componentes o por otros subsistemas (recursivamente) dentro del subsistema.

Implementar una clase (por ing. de componentes)

El propsito de la implementacin de una clase es implementar una clase de diseo en un componente fichero.
Esbozo de los componentes fichero
Es normal implementar varias clases de diseo en un mismo componente fichero. Sin embargo, el tipo de
modularizacin y convenciones de los lenguajes de programacin restringen la forma en que los componentes
fichero son esbozados.
Generacin de cdigo a partir de una clase de diseo
Solo se genera la signatura (la firma) de las operaciones (mtodos) las cuales todava deben ser implementadas.
Implementacin de operaciones
Cada operacin definida por la clase de diseo ha de ser implementada, a no ser que sea virtual (o abstracta) y
sta sea implementada por descendientes de la clase.
La implementacin de una operacin incluye la eleccin de un algoritmo y unas estructuras de datos apropiadas,
y la codificacin de las acciones requeridas por el algoritmo.
- 99 -

Los componentes han de proporcionar las interfaces apropiadas

El componente resultante debera proporcionar las mismas interfaces que las clases de diseo que ste
implementa.

Realizar prueba de unidad (por ing. de componentes)

Probar los componentes implementados como unidades individuales. Dos tipos de prueba de unidad:

Prueba de especificacin (prueba de caja negra): se verifica el comportamiento de la unidad observable

externamente.
Se realiza para verificar el comportamiento del componente sin tener en cuenta cmo se implementa dicho
comportamiento en el componente. Tienen en cuenta la salida que el componente devolver cuando se le
da una determinada entrada en un determinado estado.
Prueba de estructura (prueba de caja blanca): verifica la implementacin interna de la unidad. Se fija en
el cdigo.
Se realizan para verificar que un componente funciona internamente como se quera. El ingeniero de
componentes debera tambin de asegurarse de probar todo el cdigo durante las pruebas de estructura,
lo que quiere decir que cada sentencia ha de ser ejecutada al menos una vez. Debera tambin asegurarse
de probar los caminos ms importantes en el cdigo.

- 100 -

WORKFLOW DE PRUEBA
Introduccin
En el flujo de trabajo de la prueba verificamos el resultado de la implementacin probando cada construccin,
incluyendo tanto construcciones internas como intermedias, as como las versiones finales del sistema a ser
entregadas a los clientes.

Propsitos de la prueba

Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y las pruebas de
sistema. Las pruebas de integracin son necesarias para cada construccin dentro de la iteracin, mientras
que las pruebas de sistema son necesarias slo al final de la iteracin.
Disear e implementar las pruebas creando los casos de prueba que especifican qu probar.
Realizar las diferentes pruebas y manejar los resultados de cada prueba simultneamente.

El papel de la prueba en el ciclo de vida del software

La realizacin de pruebas se centra en las fases de elaboracin, cuando se prueba la lnea base ejecutable de la
arquitectura, y de construccin cuando el grueso del sistema est implementado. Durante la fase de transicin el
centro se desplaza hacia la correccin de defectos durante los primeros usos y las pruebas de regresin.

Artefactos de la prueba
1.
2.
3.
4.
5.
6.

Modelo de pruebas.
Caso de prueba.
Procedimiento de prueba.
Plan de prueba.
Defecto.
Evaluacin de prueba.

Modelo de pruebas
El modelo de pruebas describe principalmente cmo se prueban los componentes ejecutables en el modelo de
implementacin con pruebas de integracin y de sistema. Puede describir tambin como han de ser probados
aspectos especficos del sistema; por ejemplo; si la interfaz de usuario es utilizable y consistente o si el manual de
usuario del sistema cumple su cometido. El modelo de pruebas es una coleccin de casos de prueba, procedimientos
de prueba y componentes de prueba.

- 101 -

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.
Casos de prueba comunes:

Un caso de prueba que especifica cmo probar un caso de uso o un escenario especfico de un caso de uso
(verificacin del resultado de la interaccin ente actores y el sistema, si se cumplen las precondiciones y
postcondiciones y que se siguen la secuencia de acciones especificadas en el caso de uso). Prueba de sistema
como caja negra, es decir, una prueba del comportamiento observable del sistema.
Un caso de prueba que especifica cmo probar una realizacin de caso de uso de diseo o un escenario
especfico de la realizacin (verificacin de la interaccin entre componentes que implementan el caso de
uso). Prueba de sistema como caja blanca, es decir, una prueba de la interaccin interna entre los
componentes del sistema.

Se pueden especificar otros casos de prueba para probar el sistema como un todo. Por ejemplo:

Pruebas de instalacin: verifican que el sistema puede ser instalado en la plataforma del cliente y que
funcionar correctamente cuando sea instalado.
Pruebas de configuracin: verifican que el sistema funciona correctamente en diferentes configuraciones.
Pruebas negativas: intentan provocar que el sistema falle para poder as revelar sus debilidades. Consiste
en utilizar el sistema en formas para los que no sido diseado (usar mal el sistema a propsito).
Pruebas de tensin o de estrs: identifican problemas con el sistema cuando hay recursos insuficientes o
cuando hay competencia por recursos.

Procedimiento de prueba
Un procedimiento de prueba especifica cmo realizar uno a varios casos de pruebas o partes de stos.

Componente de prueba
Un componente de prueba automatiza uno o varios procedimientos de prueba o partes de ellos.
Se utilizan para probar los componentes en el modelo de implementacin, proporcionando entradas de prueba,
controlando y monitorizando la ejecucin de los componentes a probar y, posiblemente, informando de los
resultados de las pruebas.

Plan de prueba
El plan de prueba describe las estrategias, recursos y planificacin de la prueba. La estrategia de prueba incluye la
definicin del tipo de pruebas a realizar para cada iteracin y sus objetivos.

Defecto
Un defecto es una anomala en el sistema.

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

Trabajadores de la prueba
1.
2.
3.
4.

Diseador de pruebas (ingeniero de prueba).

Ingeniero de componentes.
Ingeniero de pruebas de integracin.
Ingeniero de pruebas de sistema.

- 102 -

Diseador de pruebas
Un diseador de pruebas es responsable de la integridad del modelo de pruebas, asegurando que el modelo cumple
con su propsito. Tambin planean las pruebas, lo que significa que deciden los objetivos apropiados y la
planificacin de las pruebas. Adems, seleccionan y describen los casos de prueba y los procedimientos de prueba
correspondientes que se necesitan, y son responsables de la evaluacin de pruebas de integracin y de sistema
cuando stas se ejecutan.

Ingeniero de componentes
Los ingenieros de componentes son responsables de los componentes de prueba que automatizan algunos
procedimientos de prueba.

Ingeniero de pruebas de integracin

Los ingenieros de pruebas de integracin son los responsables de realizar las pruebas de integracin que se
necesitan para cada construccin producida en el flujo de trabajo de la implementacin. Las pruebas de integracin
se realizan para verificar que los componentes integrados en una construccin funcionan correctamente juntos.
El ingeniero de pruebas de integracin se encarga de documentar los defectos en los resultados de las pruebas de
integracin.

Ingeniero de pruebas de sistema

Un ingeniero de pruebas de sistema es responsable de realizar las pruebas de sistema necesarias sobre una
construccin que muestra el resultado (ejecutable) de una iteracin completa.
Las pruebas de sistema se llevan a cabo principalmente para verificar las interacciones entre los actores y el sistema,
por eso suelen derivarse de los casos de prueba que especifican como probar los casos de uso.
El ingeniero de pruebas de sistema se encarga de documentar los defectos en los resultados de las pruebas de
sistema.

Flujo de trabajo (actividades)

1. Los ingenieros de pruebas determinar el objetivo de la prueba a realizar planificando el esfuerzo de prueba
a realizar en cada iteracin
2. Describen entonces los casos de prueba necesarios y los procedimientos de prueba correspondientes para
llevar a cabo las pruebas.
3. Si es posible, los ingenieros de componentes crean a continuacin los componentes de prueba para
automatizar algunos procedimientos de prueba.
4. Con estos casos, procedimientos y componentes de prueba como entrada, los ingenieros de pruebas de
integracin y de sistema prueban cada construccin y detectan cualquier defecto que encuentren en ellos.

- 103 -

5. Los defectos sirven como retroalimentacin tanto para otros flujos de trabajo, como el diseo y el de
implementacin, como para los ingenieros de pruebas para que lleven a cabo una evaluacin sistemtica de
los resultados de las pruebas.

Planificar prueba (ing. de pruebas)

El propsito de la planificacin de prueba es planificar los
esfuerzos de prueba en una iteracin llevando a cabo las siguientes
tareas:

Describiendo una estrategia de prueba.

Estimando los requerimientos para el esfuerzo de la
prueba (ejemplo: recursos humanos y sistemas
necesarios).
Planificando el esfuerzo de la prueba.

En general, se crea el plan de prueba estableciendo las estrategias

y recursos.

Disear prueba (ing. de pruebas)

Propsitos de disear las pruebas:

Identificar y describir los casos de prueba para cada construccin.

Identificar y estructurar los procedimientos de prueba especificando cmo realizar los casos de prueba.

Diseo de los casos de prueba de integracin

La mayora de los casos de prueba de integracin pueden ser derivados de las realizaciones de casos de uso de
diseo, ya que las realizaciones de casos de uso describen cmo interaccionan las clases y los objetos, y por
tanto cmo interaccionan los componentes. Se consideran como entrada los diagramas de interaccin de las
realizaciones de casos de uso.
Diseo de los casos de prueba de sistema
Las pruebas de sistema se usan para probar que el sistema funciona correctamente como un todo. Cada prueba
de sistema prueba principalmente combinaciones de casos de uso instanciados bajo condiciones diferentes
- 104 -

(diferentes configuraciones de hardware, diferentes

cargas del sistema, diferentes nmeros de actores y
diferentes tamaos de la base de datos).
Diseo de los casos de prueba de regresin
Algunos casos de prueba de construcciones
anteriores pueden ser usados para pruebas de
regresin en construcciones subsiguientes, aunque
no todos los casos de prueba son adecuados para
pruebas de regresin.
Identificacin y estructuracin de los procedimientos
de prueba
Se intenta reutilizar procedimientos de prueba
existentes tanto como sea posible. Los diseadores
de pruebas tambin intentan crear procedimientos
de prueba que puedan ser reutilizados en varios casos
de prueba.

Implementar prueba (ing. de componentes)

El propsito de la implementacin de las pruebas es
automatizar los procedimientos de prueba creando
componentes de prueba si esto es posible, ya que no todos
los procedimientos de prueba pueden ser automatizados.

Realizar pruebas de integracin (ing. de pruebas de

integracin)
En esta actividad se realizan las pruebas de integracin
necesarias para cada una de las construcciones creadas en una iteracin y se recopilan los resultados de las pruebas.

Realizar prueba de sistema (ing. de pruebas de sistema)

El propsito de la prueba de sistema es el realizar las pruebas de sistema.
La prueba de sistema puede empezar cuando las pruebas de integracin indican que el sistema satisface los objetivos
de calidad de integracin fijados en el plan de pruebas de la iteracin actual.

- 105 -

Evaluar la prueba (ing. de pruebas)

El propsito de la evaluacin de la prueba es el
evaluar los esfuerzos de prueba de una iteracin.
Los diseadores de pruebas evalan los
resultados de la prueba comparando los
resultados obtenidos con los objetivos esbozados
en el plan de prueba. stos preparan mtricas que
les permiten determinar el nivel de calidad del
software y qu cantidad de pruebas es necesario
hacer.

PRUEBA
Introduccin
Las pruebas intentan demostrar que un programa hace lo que se intenta que haga, as como descubrir defectos en
el programa antes de usarlo.
El proceso de prueba tiene dos metas distintas:
1. Demostrar al desarrollador y al cliente que el software cumple con los requerimientos.
2. Encontrar situaciones donde el comportamiento del software sea incorrecto, indeseable o no est de
acuerdo con su especificacin.
La primera meta conduce a la prueba de validacin; en ella, se espera que el sistema se desempee de manera
correcta mediante un conjunto dado de casos de prueba, que refleje el uso previsto del sistema. La segunda meta
se orienta a pruebas de defectos, donde los casos de prueba se disean para presentar los defectos.
Las pruebas no pueden demostrar que el software est exento de defectos o que se comportar como se especifica
en cualquier circunstancia.
Las pruebas pueden mostrar slo la presencia de errores, ms no su ausencia.
El propsito de la prueba es ENCONTRAR FALLAS. El testing exitoso es el que encuentro defectos.
Las pruebas pueden dividirse en:

Validacin: construimos el producto correcto?

Verificacin: construimos bien el producto?

La finalidad de la verificacin es comprobar que el software cumpla con su funcionalidad y con los requerimientos
no funcionales establecidos. Sin embargo, la validacin es un proceso ms general. La meta de la validacin es
garantizar que el software cumpla las expectativas del cliente. La validacin es esencial pues, las especificaciones de
requerimientos no siempre reflejan los deseos o las necesidades reales de los clientes y usuarios del sistema.
El objetivo final de los procesos de verificacin y validacin es establecer confianza de que el sistema de software es
adecuado.

- 106 -

Prueba e inspeccin
Al igual que las pruebas de software, el proceso de verificacin y validacin implicara inspecciones y revisiones de
software. Estas ltimas analizan y comprueban los requerimientos del sistema, los modelos de diseo, el cdigo
fuente, y las pruebas propuestas para el sistema. stas son las llamadas tcnicas estticas.
Tcnicas estticas: donde no es necesario ejecutar el software para verificarlo.
Las inspecciones se enfocan principalmente en el cdigo del sistema.

Ventajas de la inspeccin sobre las pruebas

1. Durante las pruebas, los errores pueden enmascarar (ocultar) otras fallas. Cuando un error lleva a salidas
inesperadas, nunca se podr asegurar si las anomalas de salida posteriores se deben a un nuevo error o son
defectos colaterales del error original.
2. Las versiones incompletas de un sistema se pueden inspeccionar sin costos adicionales.
3. Una inspeccin puede considerar tambin atributos ms amplios de calidad de un programa, como el
cumplimiento con estndares, la portabilidad y la mantenibilidad. Pueden buscarse inferencias, algoritmos
inadecuados y estilos de programacin imitados que hagan al sistema difcil de mantener y actualizar.
Las inspecciones no sustituyen las pruebas del software, ya que no son eficaces para descubrir defectos que surjan
por interacciones inesperadas entre diferentes partes de un programa, problemas de temporizacin o dificultades
con el rendimiento del sistema.
Casos de prueba: son especificaciones de las entradas a las pruebas y la salida esperada del sistema (los resultados
de la prueba).
Es posible automatizar la ejecucin de pruebas. Los resultados provistos se comparan automticamente con los
resultados establecidos, de manera que no haya necesidad de que un individuo busque errores y anomalas al correr
las pruebas.

Etapas de prueba
1. Pruebas de desarrollo: donde el sistema se pone a prueba durante el proceso para descubrir errores (bugs)
y defectos. Intervienen diseadores y programadores del sistema.
2. Prueba de versin: donde un equipo de prueba por separado experimenta una versin completa del
sistema, antes de presentarlo a los usuarios.
3. Pruebas de usuario: donde los usuarios reales o potenciales del sistema prueban el sistema en su propio
entorno.

- 107 -

Pruebas de desarrollo
Las pruebas de desarrollo incluyen todas las actividades de prueba que realiza el equipo que elabora el sistema.

Niveles de prueba

Pruebas de unidad: donde se ponen a prueba unidades de programa, clases de objetos, bloques y paquetes.
Las pruebas de unidad deben enfocarse en comprobar la funcionalidad de objetos y mtodos.
Pruebas de componente (de integracin): se prueban que las unidades trabajan correctamente juntas.
Deben enfocarse en probar interfaces de componentes.
Pruebas de sistema: se prueba el sistema completo.

Pruebas de unidad
Es el nivel de prueba ms bajo y normalmente lo hace el mismo desarrollador. Involucra clases, bloques, paquetes
de servicio.

Prueba de caja negra (de especificacin): verifican el comportamiento de la interfaz de la unidad, o sea lo
que hace la unidad sin importar como lo hace. Adems de verificar si se producen salidas, hay que verificar
si la salida es la correcta.
Prueba de caja blanca (de estructura): se verifica si la estructura interna es la correcta. Todos los caminos
posibles planteados en el cdigo deben ser contemplados y ejecutados. Por lo general esta prueba se realiza
al ltimo.
Prueba basada en estados: prueba la interaccin entre las operaciones de una clase, monitoreando los
cambios que tienen lugar en los atributos de los objetos. Es importante basarse en diagramas de transicin
estados, as, al menos cada estado es visitado por lo menos una vez y cada transicin es atravesada al menos
una vez.

Cuando se pone a prueba las clases de los objetos, hay que disear pruebas para brindar cobertura a todas las
caractersticas del objeto:

Probar todas las operaciones asociadas al objeto.

Establecer y verificar el valor de todos los atributos relacionados con el objeto.
Poner el objeto en todos los estados posibles.

La generalizacin o herencia provoca que sea ms difcil la prueba de las clases de objetos. Por consiguiente, tienen
que poner a prueba la operacin heredada en todos los contextos en que se utilice.
Siempre que sea posible, se deben automatizar las pruebas de unidad (por ejemplo, JUnit).

Pruebas de componentes (de integracin)

Una vez que las unidades han sido certificadas en las pruebas de unidad, estas unidades deberan integrarse en
unidades ms grandes y finalmente al sistema.
El propsito es determinar si las distintas unidades que han sido desarrolladas trabajan apropiadamente juntas.
En general, los componentes de software son componentes compuestos constituidos por varios objetos en
interaccin. El acceso a la funcionalidad de dichos objetos es a travs de la interfaz de componente definida. Por
consiguiente, la prueba de componentes compuestos tiene que enfocarse en mostrar que la interfaz de componente
se comporta segn su especificacin.

Pruebas del sistema

Una vez que se han probado todos los casos de uso por separado se probar el sistema completo.

- 108 -

Las pruebas de sistema durante el desarrollo incluyen la integracin de componentes para crear una versin del
sistema y, luego, poner a prueba el sistema integrado. Las pruebas de sistema demuestran que los componentes son
compatibles, que interactan correctamente y que transfieren los datos correctos en el momento adecuado a travs
de sus interfaces.
Cuando se integran componentes para crear un sistema, se obtiene un comportamiento emergente. Esto significa
que algunos elementos de funcionalidad del sistema slo se hacen evidentes cuando se renen los componentes.
Sin embargo, algunas veces, el comportamiento emergente no est planeado ni se desea. Hay que desarrollar
pruebas que demuestren que el sistema slo hace lo que se supone que debe hacer.
Por lo tanto, las pruebas del sistema deben enfocarse en poner a prueba las interacciones entre los componentes y
los objetos que constituyen el sistema.

Pruebas de versin
Las pruebas de versin son el proceso de poner a prueba una versin particular de un sistema que se pretende usar
fuera del equipo de desarrollo.
Existen dos distinciones importantes entre las pruebas de versin y las pruebas de sistema durante el desarrollo:
1. Un equipo independiente que no intervino en el desarrollo del sistema debe ser el responsable de las
pruebas de versin.
2. Las pruebas del sistema por parte del equipo de desarrollo deben enfocarse en el descubrimiento de bugs
en el sistema.
La principal meta del proceso de pruebas de versin es convencer al proveedor del sistema de que ste es
suficientemente apto para su uso. Por ello, las pruebas de versin deben mostrar que el sistema entrega su
funcionalidad, rendimiento y confiabilidad especificados, y que no falla durante el uso normal.
Las pruebas de versin, por lo regular, son un proceso de prueba de caja negra, donde las pruebas se derivan a partir
de la especificacin del sistema.

Pruebas basadas en requerimientos

Los requerimientos tienen que escribirse de forma que pueda disearse una prueba para dicho requerimiento.
Luego, un examinador comprueba que el requerimiento se cumpla. Las pruebas basadas en requerimientos son un
enfoque sistemtico al diseo de casos de prueba, donde se considera cada requerimiento y se deriva un conjunto
de pruebas para ste.

Pruebas de escenario
Es un enfoque donde se crean escenarios tpicos de uso y se les utiliza en el desarrollo de casos de prueba para el
sistema. Un escenario es una historia que describe una forma en puede usarse el sistema.

Pruebas de rendimiento
Una vez integrado completamente el sistema, es posible probar propiedades emergentes, como el rendimiento y la
confiabilidad. Las pruebas de rendimiento deben disearse para garantizar que el sistema procese su carga
pretendida. Generalmente, esto implica efectuar una serie de pruebas donde se aumenta la carga, hasta que el
rendimiento del sistema se vuelve inaceptable.
La prueba de rendimiento significa estresar el sistema al hacer demandas que estn fuera de los lmites de diseo
del software. Esto se conoce como prueba de esfuerzo. Este tipo de prueba tiene dos funciones:
1. Prueba el comportamiento de falla del sistema.
2. Fuerza al sistema y puede hacer que salgan a luz defectos que no se descubriran normalmente.
- 109 -

Las pruebas de esfuerzo son particularmente relevantes para sistemas distribuidos basados en redes de
procesadores.

Pruebas de usuario
Las pruebas de usuario o del cliente son una etapa en el proceso de pruebas donde los usuarios o clientes
proporcionan entrada y asesora sobre las pruebas del sistema. Las pruebas de usuario son esenciales, aun cuando
se hayan realizado pruebas abarcadoras de sistema y de versin. La razn de esto es que la influencia del entorno
de trabajo del usuario tiene un gran efecto sobre la fiabilidad, el rendimiento, el uso y la robustez de un sistema.
Es casi imposible que un desarrollador de sistema replique el entorno de trabajo del sistema, pues las pruebas en el
entorno del desarrollador son forzosamente artificiales.
Hay tres tipos de pruebas de usuario:

Pruebas alfa: los usuarios del software trabajan con el equipo de diseo para probar el software en el sitio
del desarrollador.
Pruebas beta: una versin del software se pone a disposicin de los usuarios, para permitirles experimentar
y descubrir problemas que encuentran con los desarrolladores del sistema.
Pruebas de aceptacin: donde los clientes prueban un sistema para decidir si est o no listo para ser
aceptado por los desarrolladores del sistema y desplegado en el entorno del cliente.

Tipos de prueba
1. Tests de operacin: el sistema es probado en operacin normal. Mide la confiabilidad del sistema y se
pueden obtener mediciones estadsticas.
2. Tests de escala completa: ejecutamos el sistema al mximo, todos los parmetros se enfocan en valores
mximos, todos los equipos conectados, usados por muchos usuarios ejecutando casos de uso
simultneamente.
3. Tests de performance o capacidad: el objetivo es medir la capacidad de procesamiento del sistema. Los
valores obtenidos son comparados con los requeridos.
4. Tests de sobrecarga (de estrs): determinan cmo se comporta el sistema cuando es sobrecargado. No se
puede esperar que supere esta prueba, pero s que no se venga abajo, que no ocurra una catstrofe. Cuntas
veces se cay el sistema es una medida interesante. Es importante ver como queda el sistema.
5. Tests de requerimientos: estos tests se mapean (rastrean) directamente desde la especificacin de
requerimientos.
6. Tests de documentacin: se prueba la documentacin del sistema.
7. Tests de aceptacin: ejecutado por la organizacin que solicita el sistema. Genera la aceptacin o no del
sistema.
8. Tests de instalacin: se verifica que el sistema pueda ser instalado en la plataforma del cliente y que el
sistema funcionar correctamente cuando sea instalado.
9. Tests de configuracin: verifica que el sistema funciona correctamente en diferentes configuraciones.
10. Tests negativo: el sistema se usa en forma incorrecta intencionalmente para probar casos especiales.
11. Test de procesos de negocio
12. Test de seguridad

Desarrollo dirigido por pruebas (TDD)

El desarrollo dirigido por pruebas (TDD, Test-Driven Development) consiste en desarrollar el cdigo
incrementalmente, junto con una prueba para ese incremento. No se avanza hacia el siguiente incremento sino
hasta que el cdigo diseado para la prueba.

- 110 -

WORKFLOW DE DESPLIEGUE
Propsito
El propsito del despliegue es volcar el producto finalizado a sus usuarios; presentar el software. Incluye los
siguientes tipos de actividades:

Probar el software en el ambiente donde va a operar.

Empaquetar el software.
Distribuir el software.
Instalar el software.
Capacitar a los usuarios finales.
Migrar el software existente o convertir bases de datos.

El centro de atencin del despliegue se centra en la fase de transicin. Durante la fase de transicin, el usuario final
puede probar el sistema para saber cmo trabaja en un ambiente real de trabajo.

Trabajadores del despliegue

1.
2.
3.
4.
5.
6.
7.

Gerente de despliegue.
Gerente de proyecto.
Escritor tcnico.
Desarrollador de cursos.
Artista grfico.
Tester.
Implementador.

Gerente de despliegue
Planifica y organiza el despliegue. Es responsable de la retroalimentacin de las beta test asegurando que el producto
es empaquetado apropiadamente para su envo.

Gerente de proyecto
Es el intermediario con los clientes. Es responsable de aprobar el despliegue segn la retroalimentacin y las
evaluaciones de resultados de las pruebas; y de la aceptacin del cliente sobre el envo del producto.

Escritor tcnico
Planea y produce material de soporte para los usuarios finales.

Desarrollador de cursos
Planea y produce material para capacitacin.

Artista grfico
Es el responsable de todo el material artstico del producto.

Tester
Ejecuta pruebas de aceptacin y es responsable de asegurar que el producto se ha probado adecuadamente.

Implementador
Crea los scripts de instalacin y los artefactos relacionados que ayudaran al usuario final a instalar el producto.

- 111 -

Artefactos del despliegue

El artefacto principal es la release, que consiste en:

El software ejecutable, en todos los casos.

Artefactos de instalacin: scripts, herramientas, archivos, guas, informacin de licencias.
Notas de la release: notas que describen la release para el usuario final.
Material de soporte: manual de usuario, manual de operaciones y mantenimiento.
Materiales de capacitacin

En el caso de productos manufacturados, se necesitan algunos artefactos adicionales, como:

La lista de materiales incluida en el producto.

Release master
Paquete (contenedor del producto) y arte del producto.
Medio de almacenamiento (CD, DVD, etc.)

Otros artefactos usados pero no son necesariamente entregados al cliente son:

Los resultados de las pruebas.

Resultados de retroalimentacin.
Resumen de las pruebas de evaluacin.

Flujo de trabajo (actividades)

1.
2.
3.
4.
5.
6.
7.
8.

Plan de despliegue.
Desarrollar material de soporte.
Probar el producto en el lugar de desarrollo.
Crear la release (producto final).
Beta test de release.
Probar el producto en el lugar de instalacin.
Empaquetar el producto (opc).
Proveer acceso a sitio de descarga (opc.)

Plan de despliegue
Dado que un despliegue exitoso est definido por la voluntad del cliente de usar el nuevo software, el planeamiento
del despliegue no slo debe tener en cuenta cmo y cundo entregar el nuevo software, sino tambin debe
asegurarse que el usuario final tiene toda la informacin necesaria para recibir el nuevo software adecuadamente y
comenzar a usarlo. Para asegurarse de eso, los planes de despliegue incluyen una prueba beta del programa, para ir
asesorando al usuario de forma temprana a travs de las betas que todava estn en construccin. El planeamiento
de despliegue general del sistema requiere un alto grado de colaboracin y preparacin del cliente. Una conclusin
exitosa del proyecto del software puede ser impactada severamente por factores fuera del desarrollo mismo del
software, tales como el edificio donde se instalar el software, la infraestructura de hardware fuera de lugar y
usuarios que no estn lo suficientemente preparados para adaptarse al nuevo software.

Desarrollar material de soporte

El material de soporte cubre toda la informacin que ser requerida por el usuario final para instalar, operar, usar y
mantener el sistema. Tambin incluye material de capacitacin para que todos los usos posibles que se le pueda dar
al sistema sean efectivos.

Probar el producto en el lugar de desarrollo

Probar el producto en el lugar de desarrollo determina si el producto tiene la madurez suficiente para ser entregado
como producto final o como distribucin para betatesters. El testeo de betas se hace para pulir un amplio rango de
- 112 -

detalles, permitiendo al usuario final retroalimentar y mejorar el producto antes de su entrega final y en el caso de
sistemas desarrollados a medida, la prueba beta puede ser una instalacin piloto en el lugar donde se instalar el
sistema.

Crear la release
Hay que asegurarse que el producto est preparado para la entrega al cliente. La release (producto final) consiste
en todo lo que el usuario final necesitar para instalar y ejecutar el software finalmente.

Beta test de release

Esto requiere que el producto sea instalado por el cliente, quien proveer informacin sobre su performance y
usabilidad. En el contexto del desarrollo iterativo, el beta testing es esencial para asegurarse que las expectativas
del cliente fueron satisfechas y la informacin provista por el usuario, se retroalimente a la prxima iteracin del
desarrollo.

Probar el producto en el lugar de instalacin

El producto debe ser instalado y probado por el cliente. Basndonos en las iteraciones y pruebas anteriores, en esta
prueba no deberamos encontrarnos con sorpresas y debera ser solo una formalidad para que el cliente acepte el
sistema.

Empaquetar el producto (opc.)

Estas actividades opcionales describen lo que debe pasar para producir un producto de "software empaquetado".
En este caso, el producto final se guarda como producto maestro para su produccin en masa y luego empaquetado
en cajas con la lista de contenidos para su envo al cliente.

Proveer acceso a sitio de descarga (opc.)

El producto es accesible a travs de internet para su descarga.

- 113 -

EVOLUCIN DEL SOFTWARE

Introduccin
El desarrollo del software no se detiene cuando un sistema se entrega, sino que contina a lo largo de la vida de
ste. Despus de distribuir un sistema, inevitablemente debe modificarse, con la finalidad de mantenerlo til. Tanto
los cambios empresariales como las expectativas del usuario generan nuevos requerimientos para el software
existente.
La evolucin de un sistema rara vez puede considerarse en aislamiento. Los cambios al entorno conducen a cambios
en el sistema que, a la vez, pueden generar ms cambios en el entorno.
La ingeniera de software se debe considerar como un proceso en espirar, con requerimientos, diseo,
implementacin y pruebas continuas, a lo largo de la vida del sistema. Esto comienza por crear la versin 1 del
sistema. Una vez entregada, se proponen cambios y casi de inmediato comienza el desarrollo de la versin 2.
Mantenimiento de software: es el proceso de cambiar el software despus de la entrega. Incluye actividades de
proceso adicionales como la comprensin del programa, adems de las actividades normales del desarrollo del
software.

Procesos de evolucin
Los procesos de evolucin del software varan dependiendo del tipo de software que se mantiene, de los procesos
de desarrollo usados en la organizacin y de las habilidades de las personas que intervienen. En algunas
organizaciones, la evolucin es un proceso informal, donde las solicitudes de cambio provienen de conversaciones
entre los usuarios del sistema y los desarrolladores. En otras compaas, se trata de un proceso formalizado con
documentacin estructurada generada en cada etapa del proceso.
Las propuestas de cambio al sistema son el motor para la evolucin del sistema en todas las organizaciones. Estos
cambios provienen de requerimientos existentes que no se hayan implementado en el sistema liberado, de
peticiones de nuevos requerimientos, de reportes de bugs de los participantes del sistema, y de nuevas ideas para
la mejora del software por parte del equipo de desarrollo del sistema. Los procesos de identificacin de cambios y
evolucin del sistema son cclicos y continan a los largo de la vida de un sistema.

El proceso de evolucin, el cual incluye actividades fundamentales de anlisis de cambio, planeacin de la versin,
implementacin del sistema y su liberacin a los clientes. El costo y el impacto de dichos cambios se valoran para
saber que tanto resultar afectado el sistema por el cambio y cunto costara implementarlo. Si los cambios
propuestos se aceptan, se planea una nueva versin del sistema. Durante la planeacin de la versin se consideran
todos los cambios propuestos (reparacin de fallas, adaptacin y nueva funcionalidad). Entonces se toma una
decisin acerca de cules cambios implementar en la siguiente versin del sistema. Despus de implementarse, se

- 114 -

valida y libera una nueva versin del sistema. Luego, el proceso se repite con un conjunto nuevo de cambios
propuestos para la siguiente liberacin.
La primera etapa de implementacin del cambio puede involucrar la comprensin del programa, sobre todo si los
desarrolladores del sistema original no son los responsables de implementar el cambio.

En carpeta (profe: Judith Meles)

Mantenimiento
El mantenimiento del software es el proceso general de cambiar un sistema despus de que ste se entreg. Los
cambios realizados al software van desde los simples para corregir errores de codificacin, los ms extensos ara
corregir errores de diseo, hasta mejoras significativas para corregir errores de especificacin o incorporar nuevos
requerimientos.

Tipos de mantenimiento de software

Reparaciones de fallas (mantenimiento correctivo): los errores de codificacin por lo general son
relativamente baratos de corregir; los errores de diseo son ms costosos, ya que pueden implicar la
reescritura de muchos componentes. Los errores de requerimientos son los ms costosos de reparar debido
a que podra ser necesario un extenso rediseo del sistema.
Adaptacin ambiental (mantenimiento adaptativo): este tipo de mantenimiento se requiere cuando
algn aspecto del entorno del sistema, como el hardware, la plataforma operativa del sistema u otro
soporte, cambia el software.
Adicin de funcionalidad (mantenimiento perfectivo): este tipo de mantenimiento es necesario cuando
varan los requerimientos del sistema, en respuesta a un cambio organizacional o empresarial.

Prediccin de mantenimiento
Se debe tratar de predecir qu cambios deben proponerse al sistema y qu partes del sistema es probable que sean
las ms difciles de mantener. Tambin hay que tratar de estimar los costos de mantenimiento globales para un
sistema durante cierto lapso de tiempo.
Predecir el nmero de peticiones de cambio para un sistema requiere un entendimiento de la relacin entre el
sistema y su ambiente externo. Para evaluar las relaciones entre un sistema y su ambiente, se debe valorar:
1. El nmero y la complejidad de las interfaces del sistema: cuantas ms interfaces y ms complejas sean, ms
probable ser que se requieran cambios de interfaz conforme se propongan nuevos requerimientos.
- 115 -

2. El nmero de requerimientos de sistema inherentemente inestables: los requerimientos que reflejan

polticas y procedimientos de la organizacin son ms inestables que los requerimientos que se basan en
caractersticas de un dominio estable.
3. Los procesos de negocio donde se usa el sistema: a medida que evolucionan los procesos de negocio,
generan peticiones de cambio del sistema.

Reingeniera de software
Significa volver a hacer ingeniera. Aplicado a sistemas heredados. Se crea un nuevo sistema a partir de uno ya
existente.
Para hacer que los sistemas heredados sean ms sencillos de mantener, se pueden someter a reingeniera para
mejorar su estructura y entendimiento. La reingeniera puede implicar volver a documentar el sistema, refactorizar
su arquitectura, traducir los programas a un lenguaje de programacin moderno, y modificar y actualizar la
estructura y los valores de los datos del sistema. La funcionalidad del software no cambia y, normalmente, conviene
tratar de evitar grandes cambios en la arquitectura del sistema.

Ventajas de la reingeniera frente a la sustitucin

1. Reduccin del riesgo: pueden cometerse errores en la especificacin del sistema o tal vez haya problemas
de desarrollo, las demoras en la introduccin del nuevo software podran significar que la empresa est
perdida y que se incurrir en costos adicionales.
2. Reduccin de costos: el costo de la reingeniera puede ser significativamente menor que el costo de
desarrollar software nuevo.

Actividades de la reingeniera
1. Traduccin del cdigo fuente: el programa se convierte de un lenguaje de programacin antiguo a una
versin ms moderna, o a un lenguaje diferente.
2. Ingeniera inversa: el programa se analiza y se extrae informacin del l. Por lo general es un proceso
automatizado.
3. Mejoramiento de la estructura del programa: la estructura de control del programa se analiza y modifica
para facilitar su lectura y comprensin. Puede ser automatizado con alguna intervencin manual.
4. Modularizacin del programa: las partes relacionadas del programa se agrupan y, donde es adecuado, se
elimina la redundancia. En algunos casos, implica refactorizacin arquitectnica. Es un proceso manual.
5. Reingeniera de datos: los datos procesados por el programa cambian para reflejar cambios al programa.
Significa la redefinicin de los esquemas de bases de datos y convertir las bases de datos existentes a la
nueva estructura.
Cuando se aplica la reingeniera no necesariamente se requiere de todos las actividades.

Desventajas

No es posible convertir un sistema funcional a un sistema orientado a objetos.

Grandes cambios no pueden hacerse de forma automatizada.
Los sistemas con reingeniera probablemente no sern tan mantenibles como los sistemas nuevos
desarrollados con tcnicas modernas.

Refactorizacin
La refactorizacin es el proceso de hacer mejoras a un programa para frenar la degradacin mediante el cambio.
Estos significa modificar un programa para mejorar su estructura, reducir su complejidad o hacerlo ms fcil de
entender.
Mientras se refactorice un programa, no se debe agregar funcionalidad, sino que hay que concentrarse en la mejora
del programa.
- 116 -

Aunque la reingeniera y la refactorizacin tienen la intencin de hacer el software ms fcil de entender y cambiar,
no son lo mismo.

Refactorizacin vs reingeniera
La reingeniera se lleva a cabo despus de haber mantenido un sistema durante cierto tiempo. Se crea un nuevo
sistema a partir de un sistema heredado utilizando herramientas automatizadas.
La refactorizacin es un proceso continuo de mejoramiento debido al proceso de desarrollo y evolucin. Tiene la
intencin de evitar la degradacin de la estructura y el cdigo que aumentan los costos y las dificultades por
mantener un sistema.

Mejoras de la refactorizacin
La refactorizacin mejora:
1. Cdigo duplicado: el mismo cdigo se incluye en diferentes partes del programa. ste se descarta o se
implementa como un solo mtodo.
2. Mtodos largos: si hay mtodos largos, deben redisearse en varios mtodos ms pequeos.
3. Sentencias case (switch): en un lenguaje orientado a objetos se pueden reemplazar mediante polimorfismo.
4. Aglomeracin de datos: las aglomeraciones de datos ocurren cuando el mismo grupo de objetos de datos
vuelven a ocurrir en muchos lugares en un programa. Pueden sustituirse con un objeto que encapsule todos
los datos.
5. Generalidad especulativa: esto ocurre cuando los desarrolladores incluyen generalidad en un programa, en
caso de que se requiera en el futuro. Por lo general, eso simplemente puede eliminarse.

Rediseo arquitectnico
Se realizan cambios en la arquitectura del sistema.

Cmo decidir

Baja calidad y bajo valor de negocio desechar.

Baja calidad y alto valor de negocio Reingeniera.
Alta calidad y bajo valor de negocio Si el cambio es caro, desechar.
Alta calidad y alto valor de negocio Mantenimiento normal.

- 117 -

CONTENIDO
WORKFLOW DE ANLISIS .........................................................................................................................................................1
INTRODUCCIN ................................................................................................................................................................................1
EL ANLISIS ......................................................................................................................................................................................1
EL PAPEL DEL ANLISIS EN EL CICLO DE VIDA DEL SOFTWARE .......................................................................................................................2
ARTEFACTOS DE ANLISIS....................................................................................................................................................................3
TRABAJADORES DEL ANLISIS ...............................................................................................................................................................5
FLUJO DE TRABAJO (ACTIVIDADES) ........................................................................................................................................................6
UML .........................................................................................................................................................................................9
UML ES UN LENGUAJE .......................................................................................................................................................................9
BLOQUES BSICOS DE CONSTRUCCIN .................................................................................................................................................10
REGLAS DE UML ............................................................................................................................................................................12
MECANISMOS COMUNES DE UML .....................................................................................................................................................12
ARQUITECTURA ..............................................................................................................................................................................13
CICLO DE VIDA DEL DESARROLLO DE SOFTWARE .....................................................................................................................................14
DIAGRAMAS...................................................................................................................................................................................15
INTERACCIONES ..............................................................................................................................................................................15
MQUINAS DE ESTADOS ...................................................................................................................................................................17
PATRONES GRASP .................................................................................................................................................................. 19
RESPONSABILIDADES Y MTODOS .......................................................................................................................................................19
PATRONES .....................................................................................................................................................................................19
PATRONES DE ASIGNACIN DE RESPONSABILIDADES (GRASP) .................................................................................................................19
WORKFLOW DE DISEO ......................................................................................................................................................... 24
INTRODUCCIN ..............................................................................................................................................................................24
ANLISIS VS DISEO ........................................................................................................................................................................24
PROPSITOS DEL DISEO ..................................................................................................................................................................25
EL PAPEL DEL DISEO EN EL CICLO DE VIDA DEL SOFTWARE .......................................................................................................................25
ARTEFACTOS DE DISEO ...................................................................................................................................................................25
TRABAJADORES DEL DISEO ..............................................................................................................................................................28
FLUJO DE TRABAJO (ACTIVIDADES) ......................................................................................................................................................29
DISEO .................................................................................................................................................................................. 33
QU SE DISEA? ...........................................................................................................................................................................33
GUA PARA EVALUAR UN BUEN DISEO ................................................................................................................................................34
DIRECTRICES SOBRE CALIDAD DEL DISEO.............................................................................................................................................34
PRINCIPIOS DE DISEO DEL SOFTWARE ................................................................................................................................................35
DISEO ARQUITECTNICO ..................................................................................................................................................... 35
INTRODUCCIN ..............................................................................................................................................................................35
ROL DEL ARQUITECTO ......................................................................................................................................................................35
VENTAJAS DE DISEAR Y DOCUMENTAR LA ARQUITECTURA ......................................................................................................................35
REQUERIMIENTOS NO FUNCIONALES ...................................................................................................................................................36
MODELADO DE LA ARQUITECTURA ......................................................................................................................................................37
PROCESO DE ARQUITECTURA DE SOFTWARE ..........................................................................................................................................39
DOCUMENTAR LA ARQUITECTURA ......................................................................................................................................................40
PATRONES ARQUITECTNICOS .............................................................................................................................................. 40
INTRODUCCIN ..............................................................................................................................................................................40
PATRONES ARQUITECTNICOS VS. ESTILOS ARQUITECTNICOS .................................................................................................................41
PLATNICOS VS. EMBEBIDOS.............................................................................................................................................................41

- 118 -

PATRONES .....................................................................................................................................................................................41
ARQUITECTURA DE SISTEMAS DISTRIBUIDOS ........................................................................................................................ 46
TIPOS DE SISTEMAS..........................................................................................................................................................................46
INTRODUCCIN ..............................................................................................................................................................................46
CARACTERSTICAS DE LOS SISTEMAS DISTRIBUIDOS .................................................................................................................................46
DESVENTAJAS DE LOS SISTEMAS DISTRIBUIDOS ......................................................................................................................................47
ATAQUES DE LOS QUE DEBEN DEFENDERSE LOS SISTEMAS DISTRIBUIDOS .....................................................................................................47
MODELOS DE INTERACCIN EN SISTEMAS DISTRIBUIDOS..........................................................................................................................47
MIDDLEWARE ................................................................................................................................................................................47
PATRONES ARQUITECTNICOS PARA SISTEMAS DISTRIBUIDOS ...................................................................................................................48
ARQUITECTURAS DE LA VISTA DE DISTRIBUCIN .....................................................................................................................................51
ARQUITECTURA ORIENTADA A SERVICIOS ............................................................................................................................. 52
INTRODUCCIN ..............................................................................................................................................................................52
ESTNDARES ..................................................................................................................................................................................52
INGENIERA DE SERVICIO ...................................................................................................................................................................53
SERVICIOS DE SISTEMAS HEREDADOS ...................................................................................................................................................54
VISTAS ARQUITECTNICAS .................................................................................................................................................... 54
TIPOS DE VISTAS .............................................................................................................................................................................55
VISTAS EN EL PROCESO UNIFICADO DE DESARROLLO (PUD) ....................................................................................................................55
REUTILIZACIN DE SOFTWARE ............................................................................................................................................... 56
INTRODUCCIN ..............................................................................................................................................................................56
VENTAJAS DE LA REUTILIZACIN .........................................................................................................................................................57
DESVENTAJAS DE LA REUTILIZACIN ....................................................................................................................................................57
PANORAMA DE LA REUTILIZACIN ......................................................................................................................................................57
FRAMEWORKS DE APLICACIN ...........................................................................................................................................................58
LNEAS DE PRODUCTOS DE SOFTWARE .................................................................................................................................................58
REUTILIZACIN DE PRODUCTOS COTS .................................................................................................................................................59
INGENIERA DE SOFTWARE BASADA EN COMPONENTES (ISBC) ............................................................................................. 60
INTRODUCCIN ..............................................................................................................................................................................60
FUNDAMENTOS DE LA ISBC ..............................................................................................................................................................60
PRINCIPIOS DE DISEO EN LA ISBC .....................................................................................................................................................60
COMPONENTES COMO SERVICIOS .......................................................................................................................................................61
PROBLEMAS DE LA ISBC ...................................................................................................................................................................61
COMPONENTES ..............................................................................................................................................................................61
MODELOS DE COMPONENTES ............................................................................................................................................................62
PROCESOS ISBC .............................................................................................................................................................................63
COMPOSICIN DE COMPONENTES ......................................................................................................................................................64
BENEFICIOS....................................................................................................................................................................................65
VENTAJAS ......................................................................................................................................................................................65
ESTRATEGIAS DE PROTOTIPADO ............................................................................................................................................ 66
CONCEPTOS ...................................................................................................................................................................................66
BENEFICIOS DE LOS PROTOTIPOS ........................................................................................................................................................66
PROCESO DE DESARROLLO DE PROTOTIPOS ...........................................................................................................................................67
CUNDO SON INTERESANTES LOS PROTOTIPOS? ..................................................................................................................................67
CLASIFICACIN DE PROTOTIPOS..........................................................................................................................................................67
DISEO DE INTERFACES DE USUARIO ..................................................................................................................................... 68
INTRODUCCIN ..............................................................................................................................................................................68
FACTORES HUMANOS EN EL DISEO DE GUIS........................................................................................................................................68

- 119 -

PRINCIPIOS DE DISEO DE GUIS .........................................................................................................................................................68

INTERACCIN DE USUARIO ................................................................................................................................................................69
PRESENTACIN DE LA INFORMACIN...................................................................................................................................................70
EL PROCESO DE DISEO DE INTERFACES DE USUARIO...............................................................................................................................71
CONSIDERACIONES ..........................................................................................................................................................................73
LAS OCHO REGLAS DE SHNEIDERMAN ..................................................................................................................................................73
PRODUCTOS DEL DISEO DE INTERFAZ EXTERNA ....................................................................................................................................74
DISEO ORIENTADO A OBJETOS ............................................................................................................................................ 74
CARACTERSTICAS DE UN BUEN DISEO ................................................................................................................................................74
PRINCIPIOS DE DISEO .....................................................................................................................................................................74
CLASES ANIDADAS ...........................................................................................................................................................................75
AGREGACIN .................................................................................................................................................................................75
COMPOSICIN................................................................................................................................................................................76
ENCAPSULAMIENTO.........................................................................................................................................................................76
HERENCIA......................................................................................................................................................................................76
CLASE ABSTRACTA ...........................................................................................................................................................................77
INTERFAZ.......................................................................................................................................................................................77
HERENCIA VS COMPOSICIN ..............................................................................................................................................................77
HERENCIA DE CLASES VS HERENCIA DE INTERFACES .................................................................................................................................78
PROGRAMAR PARA INTERFACES, NO PARA UNA IMPLEMENTACIN ............................................................................................................78
DELEGACIN ..................................................................................................................................................................................79
PATRONES DE DISEO ........................................................................................................................................................... 79
INTRODUCCIN ..............................................................................................................................................................................79
QU ES UN PATRN DE DISEO ..........................................................................................................................................................80
DESCRIPCIN DE LOS PATRONES DE DISEO (PLANTILLA DE DEFINICIN) .....................................................................................................80
A QU AYUDAN LOS PATRONES?.......................................................................................................................................................81
CMO SELECCIONAR UN PATRN DE DISEO? .....................................................................................................................................83
CMO USAR UN PATRN? ..............................................................................................................................................................83
CLASIFICACIN ...............................................................................................................................................................................83
PATRONES DE CREACIN...................................................................................................................................................................83
PATRONES DE ESTRUCTURA ...............................................................................................................................................................84
PATRONES DE COMPORTAMIENTO ......................................................................................................................................................84
DISEO DE PERSISTENCIA (BASES DE DATOS) ........................................................................................................................ 85
INTRODUCCIN ..............................................................................................................................................................................85
DBMS .........................................................................................................................................................................................85
MODELO RELACIONAL Y PROBLEMA DE IMPEDANCIA ..............................................................................................................................86
OBJETOS EN TABLAS ........................................................................................................................................................................87
NORMALIZACIN ............................................................................................................................................................................87
HERENCIA......................................................................................................................................................................................88
MATERIALIZACIN Y DESMATERIALIZACIN ..........................................................................................................................................89
DBMSS ORIENTADOS A OBJETOS ......................................................................................................................................................89
DISEO DE PERSISTENCIA ..................................................................................................................................................................90
FRAMEWORKS DE PERSISTENCIA .........................................................................................................................................................90
SPER OBJETO PERSISTENTE .............................................................................................................................................................90
ESQUEMA DE PERSISTENCIA...............................................................................................................................................................91
WORKFLOW DE IMPLEMENTACIN ....................................................................................................................................... 93
INTRODUCCIN ..............................................................................................................................................................................93
PROPSITOS DE LA IMPLEMENTACIN .................................................................................................................................................94
EL PAPEL DE LA IMPLEMENTACIN EN EL CICLO DE VIDA DEL SOFTWARE ......................................................................................................94
ARTEFACTOS DE LA IMPLEMENTACIN .................................................................................................................................................94
TRABAJADORES DE LA IMPLEMENTACIN .............................................................................................................................................96

- 120 -

FLUJO DE TRABAJO (ACTIVIDADES) ......................................................................................................................................................97

WORKFLOW DE PRUEBA ...................................................................................................................................................... 101
INTRODUCCIN ............................................................................................................................................................................101
PROPSITOS DE LA PRUEBA .............................................................................................................................................................101
EL PAPEL DE LA PRUEBA EN EL CICLO DE VIDA DEL SOFTWARE..................................................................................................................101
ARTEFACTOS DE LA PRUEBA.............................................................................................................................................................101
TRABAJADORES DE LA PRUEBA .........................................................................................................................................................102
FLUJO DE TRABAJO (ACTIVIDADES) ....................................................................................................................................................103
PRUEBA ............................................................................................................................................................................... 106
INTRODUCCIN ............................................................................................................................................................................106
PRUEBA E INSPECCIN ...................................................................................................................................................................107
ETAPAS DE PRUEBA........................................................................................................................................................................107
PRUEBAS DE DESARROLLO ...............................................................................................................................................................108
PRUEBAS DE VERSIN ....................................................................................................................................................................109
PRUEBAS DE USUARIO ....................................................................................................................................................................110
TIPOS DE PRUEBA ..........................................................................................................................................................................110
DESARROLLO DIRIGIDO POR PRUEBAS (TDD) ......................................................................................................................................110
WORKFLOW DE DESPLIEGUE ................................................................................................................................................ 111
PROPSITO ..................................................................................................................................................................................111
TRABAJADORES DEL DESPLIEGUE ......................................................................................................................................................111
ARTEFACTOS DEL DESPLIEGUE ..........................................................................................................................................................112
FLUJO DE TRABAJO (ACTIVIDADES) ....................................................................................................................................................112
EVOLUCIN DEL SOFTWARE ................................................................................................................................................ 114
INTRODUCCIN ............................................................................................................................................................................114
PROCESOS DE EVOLUCIN ...............................................................................................................................................................114
MANTENIMIENTO .........................................................................................................................................................................115
REINGENIERA DE SOFTWARE ...........................................................................................................................................................116
REFACTORIZACIN ........................................................................................................................................................................116
REDISEO ARQUITECTNICO ...........................................................................................................................................................117
CMO DECIDIR .............................................................................................................................................................................117
CONTENIDO ......................................................................................................................................................................... 118

- 121 -