Herramientas CASE

De acuerdo con Britton (2005), una herramienta CASE (Computer Aided

Software Engineering) se refiere a cualquier pieza de software que ha sido
diseñada para ayudar a la gente a desarrollar sistemas. En teoría, una
herramienta CASE podría ser un simple programa para dibuja, pero
actualmente casi todas las herramientas CASE cubren todo el ciclo de vida de
sistemas y proveen soporte automatizado para todas las actividades de
desarrollo, tanto técnicas como administrativas.
Dada la complejidad del software y del proceso de desarrollo, actualmente, es
difícil aplicar una metodología sin la ayuda de una herramienta CASE. Así, los
beneficios de utilización de un CASE se entremezclan con los beneficios de
aplicar una metodología con éxito. El valor agregado indudable de utilizar un
CASE es el aumento en la productividad en las actividades soportadas por la
herramienta.
Otros de los beneficios de usar una herramienta CASE son:
• Facilita la verificación y mantenimiento de la consistencia de la información
del proyecto.
• Facilita el establecimiento de estándares en los procesos de desarrollo y
documentación.
• Facilita el mantenimiento del sistema y las actualizaciones de su
documentación.
• Facilita la aplicación de las técnicas de una metodología.
• Disponibilidad de funciones automatizadas tales como: obtención de
prototipos, generación de código, generación de pantallas e informes,
generación de diseños físicos de bases de datos, verificadores automáticos de
consistencia.
• Facilita la aplicación de técnicas de reutilización y reingeniería.
• Facilita la planificación y gestión del proyecto informático.
Para sistemas orientados a objetos, herramientas como Rational Rose o
Together, permiten a los desarrolladores producir modelos UML del sistema
que son sintácticamente correctos, consistentes unos con otros y que pueden
refinarse y producir código ejecutable.
Sugerencias para elegir una herramienta CASE (Larman, 2005)

Probar inicialmente una herramienta CASE de UML gratuita. Compre una sólo
cuando haya agotado las opciones de las gratuitas.
Cuando haya elegido una, especialmente cuando sea para una compañía o
cuando implique una gran inversión económica, pruébela en un proyecto real
con tantos desarrolladores como le sea posible, antes de tomar una decisión.
Decida basándose en la opinión de los desarrolladores que la han utilizado por
un largo periodo, no en la opinión de arquitectos u otros que han hecho sólo
una investigación.
Escoja la herramienta UML que incluya las características que usted prefiera
en un ambiente integrado de desarrollo (IDE).
Elija una herramienta que soporte ingeniería en reversa a diagramas de
secuencia de código. O si una herramienta gratis no soporta esto, use la
herramienta gratuita para la mayoría de los desarrolladores y compre sólo
unas pocas copias de la herramienta que si lo hace.
Prefiera una herramienta que imprima los diagramas a plotter en papel grande
de plotter, en font grande, de forma que realmente se puedan visualizar
diagramas extensos.
Una lista de herramientas CASE útil puede encontrarse en:
www.objectsbydesign.com/tools/umltools_byCompany.html

Larman, Craig. 2005. Applying UML and Patterns- an introduction to Object-

Oriented Analysis and Design and Iterative Development. Prentice Hall, 3rd Ed.
Britton, Carol and Doake, Jill. 2005. A Student Guide to Object-Oriented
Development. Elsevier Butterworth-Heinemann Publications. 1st Ed.
Córcoles, José Eduardo y Lozano, María Dolores. Modelado de aplicaciones con
UML, cuaderno de prácticas. Universidad de Castilla-La Mancha.

Mapeo del diseño al código

Para generar el código se tiene como entrada los siguientes artefactos de
UML creados durante el diseño:
-Diagramas de clase del diseño
-Diagramas de interacción.
El proceso unificado nombra a los artefactos generados durante la
implementación como “el modelo de implementación”, entre ellos se
encuentran el código fuente, la definición de la base de datos, las páginas
HTML, etc.
Durante la fase de diseño se seleccionó un lenguaje de programación
orientado a objetos, tal como Java, C#, C++, Smalltalk, etc. O alguno otro
que soporte este paradigma como Visual Basic. En los ejemplos se utilizará
Java.
El código fuente se generará para las clases, definiciones de interfaces y
para los métodos definidos en las operaciones. Algunas herramientas CASE
generan código automáticamente.
Definiciones de clases a partir de los diagramas de clases de diseño

Los diagramas de clases del diseño son el primer punto para generar el
código, ya que ellas indican las clases, superclases, firmas de las
operaciones, atributos de la clase, tipos de acceso a los atributos y
operaciones. Con esto es suficiente para crear una definición básica en un
lenguaje orientado a objetos.
Ya que en muchas metodologías no se incluyen en los diagramas de clases
constructores, destructores, operaciones get y set, deben agregarse al
esqueleto en Java.
En el siguiente ejemplo se puede observar el mapeo de los atributos a
campos de Java y de las operaciones a los métodos en Java.
También se han agregado los sets, gets y constructor(es).
Rectangulo
-ancho: int
-alto: int
+getAncho(): int
+setAncho(value:
int)
+getAlto(): int
+setAlto():int
Class Rectangulo {
private int ancho;
private int alto;
public Rectangulo(ancho int, alto int){…}
public int getAncho()
{
return ancho;
}
public void setAncho(int value)
{
ancho = value;
}
…
}

En el siguiente ejemplo se observa el mapeo a código considerando las

asociaciones entre clases y la multiplicidad.

Cliente

*
Pedido LineaPedido
1 *

El código que se agregaría a la definición de atributos y métodos propios de

cada clase, considerando las asociaciones y multiplicidad sería:
class Pedido {
private Cliente cliente;
private LineaPedido[] lineasPedido;
}
class Cliente {
private Pedido[] pedidos;
}
class LineaPedido {
private Pedido pedido;
}
En el ejemplo anterior no se ha definido navegabilidad entre clases, es por
eso que se asumió un conocimiento mutuo. En caso de definirse la
navegabilidad sólo una de las clases asociadas conocería a la otra. Como en
el siguiente ejemplo.

Cliente

class Cliente {
private Pedido[] 1 losPedidos;
}
class Pedido { *
} Pedido
Para el caso de asociaciones calificadas se tendría:

Pedido LineaPedido
0..1
Producto

class Pedido {
private Dictionary lineItems;
public LineaPedido linea (Producto unProducto);
public void agregaLinea (Numero cantidad, Producto elProducto;
}
Cuando se tiene una clase asociación entre dos clases, lo que ocurrirá en el
código es que se eliminará la asociación entre esas dos clases y quedará una
asociación de cada una de ellas con la clase asociación como se muestra en
el ejemplo.

Empresa * 1..* Persona Empresa Persona

Patrón Empleado
Patrón 1 1 Empleado

Trabajo Trabajo
1..* *

El mapeo a código se haría considerando las asociaciones y multiplicidad del

diagrama convertido, que se observa en el lado derecho. Por lo que quedaría
como sigue.
class Empresa {
private Trabajo[] listaTrabajos;
}
class Persona {
private Trabajo[] listaTrabajos;
}
class Trabajo {
private Empresa empresa;
 private Persona persona;
}
Para la herencia en Java, se utiliza la palabra reservada extends.

DocumentoImpreso

Libro

Folleto
class DocumentoImpreso
{
// lista de propiedades y métodos.
};
// Libro se deriva de DocumentoImpreso.
class Libro extends DocuemntoImpreso
{
// lista de propiedades y métodos.
};
// Folleto se deriva de Libro.
class Folleto extends Libro
{
// lista de propiedades y métodos.
};

Aunque pueden ocurrir distintos tipos de dependencias, en este curso nos

hemos referido principalmente a dos, la que ocurre cuando uno de los
métodos de una clase tiene como parámetro un tipo de la clase de la que se
depende o bien cuando dentro de un método de una clase se crea una
instancia de la clase de la que se depende. La correspondencia en código se
muestra a continuación.

Pedido
Class Pedido {
procesar() void procesar{
Factura = new miFactura();
Factura }
}
class Producto {};
Pedido class Pedido {
public void agrega(Producto producto);
agrega(Producto&)
}

Producto
Métodos a partir de los diagramas de clases

Debe tenerse cuidado en que todos los mensajes en los diagramas de

interacción tengan su correspondiente en métodos. Además, en los
diagramas de interacción se obtiene la secuencia de invocación de métodos
de otras clases. Por ejemplo, en el segmento de diagrama de secuencia
siguiente se obtiene el orden de invocación de métodos y las clases de
quienes tiene que tenerse referencia para llevar a cabo el método
crearRenta.

ControlRenta Renta : Video : Clasificacion

crearRenta(video:Video, cliente:Cliente)
getClasificacion ( )
getCostoRenta ( )

getDiasRenta (argtype)

Dentro del método crearRenta() debe encontrarse, en ese orden, el

siguiente segmento de código.
public boolean crearRenta(video: Video, cliente: Cliente)
{
…
clasificacion = video.getClasificacion();
costo = clasificacion.getCostoRenta();
numDias = clasificacion.getDiasRenta();
…
}
Finalmente, debe decidirse el orden en que deberán ser implementadas y
probadas las clases. Craig Larman (2005) sugiere que se haga de las menos
a las más acopladas. Ya que las últimas son dependientes de las
implementaciones de las primeras. En el siguiente diagrama se ejemplifica el
orden de implementación para un ejemplo de punto de venta.
 Store
7
address : Address
1 2
name : Text
3 ProductDescription
ProductCatalog
addSale(...)
description : Text
... price : Money
1 1..* itemID : ItemID
getProductDesc(...)
...

1
1 Sale
5
6
Register isComplete : Boolean 4
time : DateTime SalesLineItem
...
becomeComplete() quantity : Integer
endSale() 1 1..*
makeLineItem(...)
enterItem(...) getSubtotal()
makePayment(...)
makeNewSale()
getTotal()
makePayment(...)
...
1
* Payment

amount : Money
1
...

Manejo de Errores
De acuerdo con Stumpf (2005) al diseñar e implementar los módulos debe
considerarse que los valores de entrada son válidos. Es decir los módulos
deben confiar en lo que los otros les envían. Ya que de otra manera se
repetiría la validación de valores en cada módulo donde se utilizan, lo que
sería altamente redundante. Aquellos objetos que envían los valores deben
asegurarse que los datos que pasan son válidos.
Las operaciones para manejo de errores deben ubicarse en el primer punto
de la ejecución donde podría detectarse un error.

Larman, Craig. 2005. Applying UML and Patterns: An Introduction to Object

Oriented Analysis and Design and Iterative Development. Pearson
Education. 3rd Edition.

Stumpf, Robert and Teague, Lavette. 2005. Object- Oriented Systems

Analyisis an Design with UML. Pearson Ed.

Desarrollo Orientado a Objetos con UML

2004 Xavier Ferré Grau (Univ. Politécnica de Madrid - España) y María Isabel
Sánchez Segura (Univ. Carlos III de Madrid - España) Permiso para copiar, distribuir
y/o modificar este documento bajo los términos de la Licencia de Documentación
Libre GNU (GNU Free Documentation License), Versión 1.2 o cualquier otra versión
posterior publicada por la Free Software Foundation;

Tomado de:
http://www.clikear.com/manuales/uml/modelofisico.asp
 Modelado Físico De Un Sistema OO

III.2.1 Componentes
Los componentes pertenecen al mundo físico, es decir, representan un bloque
de construcción al modelar aspectos físicos de un sistema.
Una característica básica de un componente es que:
“debe definir una abstracción precisa con una interfaz bien definida, y
permitiendo reemplazar fácilmente los componentes más viejos con otros más
nuevos y compatibles.”
En UML todos los elementos físicos se modelan como componentes. UML
proporciona una representación gráfica para estos como se puede ver en la
Figura 27, en la que XXXX.dll, es el nombre del componente.

Figura 27 Representación de un componente

Cada componente debe tener un nombre que lo distinga de los demás. Al
igual que las clases los componentes pueden enriquecerse con
compartimentos adicionales que muestran sus detalles, como se puede ver en
la Figura 28.

Figura 28 Representación extendida de un componente

Vamos a ver con más detalle cuáles son los parecidos y las diferencias entre
los componentes y las clases.

PARECIDOS
Ambos tienen nombre
Ambos pueden realizar un conjunto de interfaces.
Pueden participar en relaciones de dependencia, generalización y asociación.
Ambos pueden anidarse
Ambos pueden tener instancias
Ambos pueden participar en interacciones

DIFERENCIAS
Las Clases Los Componentes
Representan abstracciones lógicas Representan elementos físicos
Es decir los componentes pueden estar en nodos y las clases no
Pueden tener atributos y operacionesdirectamente accesibles. Sólo tienen
operaciones y estas son alcanzables a través de la interfaz del componente.

III.2.1.1 Interfaces
Tanto los servicios propio de una clase como los de un componente, se
especifican a través de una Interfaz. Por ejemplo, todas las facilidades más
conocidas de los sistemas operativos, basados en componentes (COM+,
CORBA, etc.), utilizan las interfaces como lazo de unión entre unos
componentes y otros. La relación entre un componente y sus interfaces se
puede representar de dos maneras diferentes, de forma icónica como se
indica en la Figura 29, y de forma expandida como se muestra en la Figura
30.

Figura 29 Componentes e interfaces, formato icónico

Figura 30 Componentes e interfaces, formato extendido

III.2.1.2 Tipos de componentes

Existen básicamente tres tipos de componentes:
? Componentes de despliegue: componentes necesarios y suficientes para
formar un sistema ejecutable, como pueden ser las bibliotecas dinámicas
(DLLs) y ejecutables (EXEs).
? Componentes producto del trabajo: estos componentes son básicamente
productos que quedan al final del proceso de desarrollo. Consisten en cosas
como archivos de código fuente y de datos a partir de los cuales se crean los
componentes de despliegue.
? Componentes de ejecución: son componentes que se crean como
consecuencia de un sistema en ejecución. Es el caso de un objeto COM+ que
se instancia a partir de una DLL.

III.2.1.3 Organización de componentes

Los componentes se pueden agrupar en paquetes de la misma forma que se
organizan las clases. Además se pueden especificar entre ellos relaciones de
dependencia, generalización, asociación (incluyendo agregación), y
realización.

III.2.1.4 Estereotipos de componentes

UML define cinco estereotipos estándar que se aplican a los componentes:
executable Componente que se puede ejecutar en un nodo.
library Biblioteca de objetos estática o dinámica.
table Componentes que representa una tabla de una base de datos.
file Componente que representa un documento que contiene código fuente o
datos.
document Componente que representa un documento.
UML no especifica iconos predefinidos para estos estereotipos.

III.2.2 Despliegue

III.2.2.1 Nodos
Al igual que los componentes los nodos pertenecen al mundo material. Vamos
a definir un nodo como un elemento físico, que existe en tiempo de ejecución
y representa un recurso computacional que generalmente tiene alguna
memoria y, a menudo, capacidad de procesamiento. Los nodos sirven para
modelar la topología del hardware sobre el que se ejecuta el sistema. Un nodo
representa normalmente un procesador o un dispositivo sobre el que se
pueden desplegar los componentes. Un nodo debe tener un nombre asignado
que lo distinga del resto de nodos. Además los nodos se representan
gráficamente como se indica en la Figura 31.

Figura 31 Nodos

III.2.2.2 Nodos y componentes

En muchos aspectos los nodos y los componentes tienen características
parecidas. Vamos a ver con más detalle cuales son los parecidos y las
diferencias entre los componentes y los nodos.

PARECIDOS
Ambos tienen nombre
Pueden participar en relaciones de dependencia, generalización y asociación.
Ambos pueden anidarse
Ambos pueden tener instancias
Ambos pueden participar en interacciones

DIFERENCIAS
Los Nodos Los Componentes
Son los elementos donde se ejecutan los componentes. Son los elementos que
participan en la ejecución de un sistema.
Representan el despliegue físico de los componentes. Representan el
empaquetamiento físico de los elementos lógicos.
La relación entre un nodo y los componentes que despliega se pueden
representar mediante una relación de dependencia como se indica en la Figura
32.
Los nodos se pueden agrupar en paquetes igual que los las clases y los
componentes.
Los tipos de relación más común entre nodos es la asociación. Una asociación
entre nodos viene a representar una conexión física entre nodos como se
puede ver en la Figura 33.

Figura 32 Relación entre nodos y componentes

Figura 33 Conexiones entre nodos
Existen dos tipos de diagramas que sirven para modelar los aspectos físicos de
un sistema orientado a objetos:
• Diagramas de Componentes
• Diagramas de Despliegue
Seguidamente veremos para qué sirve cada uno de ellos y cual es su
representación gráfica.

III.2.3 Diagramas de Componentes

Un diagrama de componentes muestra la organización y las dependencias
entre un conjunto de componentes. Para todo sistema OO se han de construir
una serie de diagramas que modelan tanto la parte estática (diagrama de
clases), como dinámica (diagramas de secuencia, colaboración, estados y de
actividades), pero llegado el momento todo esto se debe materializar en un
sistema implementado que utilizará partes ya implementadas de otros
sistemas, todo esto es lo que pretendemos modelar con los diagramas de
componentes.

III.2.3.1 Algunos conceptos

Un diagrama de componentes muestra un conjunto de componentes y sus
relaciones de manera gráfica a través del uso de nodos y arcos entre estos.
Normalmente los diagramas de componentes contienen:
• Componentes
• Interfaces
• Relaciones de dependencia, generalización, asociaciones y realización.
• Paquetes o subsistemas
• Instancias de algunas clases
Visto de otro modo un diagrama de componentes puede ser un tipo especial
de diagrama de clases que se centra en los componentes físicos del sistema.

III.2.3.2 Usos más comunes

a) Modelado de Código Fuente
Los diagramas de componentes se pueden utilizar para modelar la gestión de
la configuración de los archivos de código fuente, tomando como productos de
trabajo precisamente estos ficheros. Esto resulta bastante útil por ejemplo
cuando se han implementado unas partes con Java otras con C, etc. El
resultado de esta implementación pueden ser multitud de ficheros ejecutables
con características particulares, de manera que la mejor forma de controlarlos
es estableciendo gestión de configuración.
Para poder llevar a cabo esta gestión con éxito será necesario definir los
estereotipos de ficheros que se quieren tener bajo control así como las
relaciones entre dichos tipos de ficheros.
Para modelar el código fuente de un sistema:
• Hay que identificar el conjunto de archivos de código fuente de interés y
modelarlos como componentes estereotipados como archivos.
• Si el sistema es muy grande es necesario utilizar los paquetes para agrupar
los archivos de código fuente.
• Es necesario identificar la versión del componente.
b) Modelado de una versión ejecutable y bibliotecas.
La utilización de los componentes para modelar versiones ejecutables se
centra en la definición de todos los elementos que componen lo que se conoce
como versión ejecutable, es decir la documentación, los ficheros que se
entregan etc.
Para modelar una versión ejecutable es preciso:
• Identificar el conjunto de componentes que se pretende modelar.
• Identificar el estereotipo de cada componente del conjunto seleccionado.
• Para cada componente de este conjunto hay que considerar las relaciones
con los vecinos. Esto implica definir las interfaces importadas por ciertos
componentes y las exportadas por otros.
c) Modelado de una base de datos física
Para modelar una base de datos física es necesario:
• Identificar las clases del modelo que representan el esquema lógico de la
base de datos.
• Seleccionar una estrategia para hacer corresponder las clases con tablas. Así
como la distribución física de la/s base/s de datos.
• Para poder visualizar, especificar, construir y documentar dicha
correspondencia es necesario crear un diagrama de componentes que tenga
componentes estereotipados como tablas.
• Donde sea posible es aconsejable utilizar herramientas que ayuden a
transformar diseño lógico en físico.

III.2.4 Diagramas de Despliegue

III.2.4.1 Técnicas más comunes de modelado
a) Modelado de un sistema empotrado
El desarrollo de un sistema empotrado es más que el desarrollo de un sistema
software. Hay que manejar el mundo físico. Los diagramas de despliegue son
útiles para facilitar la comunicación entre los ingenieros de hardware y los de
software.
Para modelar un sistema empotrado es necesario:
• Identificar los dispositivos y nodos propios del sistema.
• Proporcionar señales visuales, sobre todo para los dispositivos poco usuales.
• Modelar las relaciones entre esos procesadores y dispositivos en un
diagrama de despliegue.
• Si es necesario hay que detallar cualquier dispositivo inteligente, modelando
su estructura en un diagrama de despliegue más pormenorizado.
b) Modelado de un sistema cliente servidor
La división entre cliente y servidor en un sistema es complicada ya que implica
tomar algunas decisiones sobre dónde colocar físicamente sus componentes
software, qué cantidad de software debe residir en el cliente, etc.
Para modelar un sistema cliente/servidor hay que hace lo siguiente:
• Identificar los nodos que representan los procesadores cliente y servidor del
sistema.
• Destacar los dispositivos relacionados con el comportamiento del sistema.
• Proporcionar señales visuales para esos procesadores y dispositivos a través
de estereotipos.
• Modelar la tipología de esos nodos mediante un diagrama de despliegue.

III.2.5 Arquitectura del Sistema

III.2.5.1 Arquitectura de tres niveles
La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de
información que además de tener una interfaz de usuario contemplan la
persistencia de los datos.
Una descripción de los tres niveles sería la siguiente:
Nivel 1: Presentación – ventanas, informes, etc.
Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso.
Nivel 3: Almacenamiento – mecanismo de almacenamiento.

III.2.5.2 Arquitectura de tres niveles orientadas a objetos

a) Descomposición del nivel de lógica de la aplicación
En el diseño orientado a objetos, el nivel de lógica de la aplicación se
descompone en sub-niveles que son los siguientes:
Objetos del Dominio: son clases que representan objetos del dominio. Por
ejemplo en un problema de ventas, una “Venta” sería un objeto del dominio.
Servicios: se hace referencia a funciones de interacción con la base de datos,
informes, comunicaciones, seguridad, etc.

III.2.5.3 Arquitectura MULTI-nivel

La arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles si
tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres
niveles se pueden descomponer cada uno de ellos cada vez más.
Por ejemplo el nivel de Servicios, se puede descomponer en servicios de alto y
de bajo nivel, identificando como de alto nivel los servicios de generación de
informes y como de bajo nivel los de manejo de ficheros de entrada y salida.
El motivo que lleva a descomponer la arquitectura del sistema en diferentes
niveles es múltiple:
• Separación de la lógica de la aplicación en componentes separados que sean
más fácilmente reutilizables.
• Distribución de niveles en diferentes nodos físicos de computación.
• Reparto de recursos humanos en diferentes niveles de la arquitectura.

III.2.5.4 Paquetes
La forma que tiene UML de agrupar elementos en subsistemas es a través del
uso de Paquetes, pudiéndose anidar los paquetes formando jerarquías de
paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto
en subsistemas se puede considerar como con un único paquete que lo abarca
todo.
Gráficamente un paquete viene representado como se indica en la Figura 34.

Figura 34 Representación de un paquete en UML

En la Figura 35, vemos cómo se representa la arquitectura del sistema con la
notación de paquetes.
 Figura 35 Arquitectura de un sistema utilizando paquetes

III.2.5.5 Identificación de Paquetes

Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora
de agrupar los diferentes elementos en paquetes.
• Conviene agrupar elementos que proporcionen un mismo servicio.
• Los elementos que se agrupen en un mismo paquete han de presentar un
alto grado de cohesión, es decir deben estar muy relacionados.
• Los elementos que estén en diferentes paquetes deben tener poca relación,
es decir deben colaborar lo menos posible.

Arquitectura software*
En los inicios de la informática, la programación se consideraba un arte, debido a
la dificultad que entrañaba para la mayoría de los mortales, pero con el tiempo se
han ido desarrollando metodologías y fórmulas o trucos para conseguir nuestros
propósitos. Y a todas estas técnicas se les ha dado en llamar Arquitectura Software.

Una Arquitectura Software, también denominada Arquitectura lógica, consiste en un

conjunto de patrones y abstracciones coherentes que proporcionan el marco de
referencia necesario para guiar la construcción del software para un sistema de
información.

La arquitectura software establece los fundamentos para que analistas,

diseñadores, programadores, etc. trabajen en una línea común que permita
alcanzar los objetivos y necesidades del sistema de información.

Una arquitectura software se selecciona y diseña con base en unos objetivos y

restricciones. Los objetivos son aquellos prefijados para el sistema de información,
pero no solamente los de tipo funcional, también otros objetivos como la
mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de
información. Las restricciones son aquellas limitaciones derivadas de las tecnologías
disponibles para implementar sistemas de información. Unas arquitecturas son más
recomendables de implementar con ciertas tecnologías mientras que otras
tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es
viable emplear una arquitectura software de tres capas para implementar sistemas
en tiempo real.

La arquitectura software define, de manera abstracta, los componentes que llevan

a cabo alguna tarea de computación, sus intefaces y la comunicación ente ellos.
Toda arquitectura software debe ser implementable en una arquitectura física, que
consiste simplemente en determinar qué computadora tendrá asignada cada tarea
de computación.

La arquitectura de software, tiene que ver con el diseño y la implementación de

estructuras de software de alto nivel. Es el resultado de ensamblar un cierto
número de elementos arquitectónicos de forma adecuada para satisfacer la mayor
funcionalidad y requerimientos de desempeño de un sistema, así como
requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y
disponibilidad. —Kruchten, Philippe

Tabla de contenidos

• 1 Breve reseña histórica

• 2 Modelos o vistas

• 3 Arquitecturas más comunes

o 3.1 Bibliografía

• 4 Véase también

Breve reseña histórica

En los años 1960 ya se acariciaba el concepto de arquitectura software en los

círculos de investigación (por ejemplo, por Edsger Dijkstra). No obstante, toma
popularidad en los años 1990 tras reconocerse la denominada crisis del
software y como tema de interés de la incipiente disciplina de la ingeniería del
software.

Modelos o vistas

Toda arquitectura software debe describir diversos aspectos del software.

Generalmente, cada uno de estos aspectos se describe de una manera más
comprensible si se utilizan distintos modelos o vistas. Es importante destacar que
cada uno de ellos constituye una descripción parcial de una misma arquitectura y es
deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las
vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos

para describir una arquitectura. No obstante, existen al menos tres vistas
absolutamente fundamentales en cualquier arquitectura:

• La visión estática: describe qué componentes tiene la arquitectura.

• La visión funcional: describe qué hace cada componente.

• La visión dinámica: describe cómo se comportan los componentes a lo largo

del tiempo y como interactúan entre sí.

Las vistas o modelos de una arquitectura pueden expresarse mediante uno o varios
lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes
tales como los diagramas de estado, los diagramas de flujo de datos, etc.
Estos lenguajes son apropiados unicamente para un modelo o vista.
Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling
Language, lenguaje unificado de modelado) como lenguaje único para todos los
modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser
capaz de describir determinadas restricciones de un sistema de información (o
expresarlas de manera incomprensible).

Arquitecturas más comunes

Generalmente, no es necesario inventar una nueva arquitectura software para cada

sistema de información. Lo habitual es adoptar una arquitectura conocida en
función de sus ventajas e inconvenientes para cada caso en concreto. Así, las
arquitecturas más universales són:

• Monolítica. Donde el software se estructura en grupos funcionales muy

acoplados.

• Cliente-servidor. Donde el software reparte su carga de cómputo en dos

partes independientes pero sin reparto claro de funciones.

• Arquitectura de tres niveles. Generalización de la arquitectura cliente-

servidor donde la carga se divide en tres partes con un reparto claro de
funciones: una capa para la presentación, otra para el cálculo y otra para el
almacenamiento. Una capa solamente tiene relación con la siguiente.

Otras arquitecturas menos conocidas son:

• En pipeline.

• Entre pares.

• En pizarra.

• Orientada a servicios.

• Máquinas virtuales

*Tomado de : http://es.wikipedia.org/wiki/Arquitectura_de_software

Bibliografía

• Booch, Grady. Object-Oriented Analysis and Design. Second Edition.

Benjamin/Cummings, Redwood: 1994.

• Jacobson, Ivar, Grady Booch, and James Rumbaugh. El Proceso Unificado de

Desarrollo de Software. México: Addison-Wesley, 1999.

• Kruchten, Philippe. "Architectural Blueprints--The 4+1 View Model of

Software Architecture". IEEE Software, Institute of Electrical and Electronics
Engineers. November 1995, pp. 42-50.

• Larman, Craig. UML y Patrones, Introducción al análisis y diseño orientado a

objetos. México: Prentice Hall, 1999.

• Martin, Robert C. "Design Principles and Design Patterns". Objectmentor

<http://www.objectmentor.com>

• Muller, Pierre-Alain. Modèlisation Object avec UML. Paris: Eyrolles, 1997.

• Wilson, Scott F. Analyzing Requirements and Defining Solution Architectures.

Redmond: Microsoft Press, 1999.

• Fernández Aramayo, David Ricardo. Arquitectura de Software. Universidad

Tecmilenio, ITESM.
Architectural manifesto: Designing
software architectures, Part 5
Introducing the 4+1 view model
(Tomado de http://www-
128.ibm.com/developerworks/wireless/library/wi
-arch11/ el 7 de junio de 2006)

Level: Introductory
Mikko Kontio (mikko.kontio@softera.fi), Production
Manager, Softera
02 Feb 2005
The designing software architectures series continues
with a look at the 4+1 view model. The 4+1 view model
lets you separate a system into four essential views:
logical, process, physical, and development. Then, for
good measure, it gives you one more: a use case view
that describes the functional aspects of the system as a
whole.
This month you're being introduced to the 4+1 view
model, an architect's tool for viewing and documenting
application software. The 4+1 view model was originally
introduced by Philippe Kruchten in 1995 (see Resources).
Kruchten's new approach gave architects a way to
examine different parts of an architecture separately,
thus easing the complexity of the overall viewing.
Each of the five views in the 4+1 view model highlights
some elements of the system, while intentionally
suppressing others. The 4+1 view model is an excellent
way for both architects and other team members to learn
about a system's architecture. Architects use it to
understand and document the many layers of an
application in a systematic, standardized way.
Documents created using the 4+1 view process are
easily used by all members of the development team.
The first four views represent the logical, processing,
physical, and developmental aspects of the architecture.
The fifth view consists of use cases and scenarios that
might further describe or consolidate the other views.
Figure 1 shows the five views of the 4+1 view model.

Figure 1. The 4+1 view model

Note that, like some of the other articles in this series,
this article assumes you are familiar with UML
diagramming.
The logical view
The 4+1's logical view supports behavioral requirements
and shows how the system is decomposed into a set of
abstractions. Classes and objects are the main elements
studied in this view. You can use class diagrams,
collaboration diagrams, and sequence diagrams, among
others, to show the relationship of these elements from a
logical view.
Class diagrams show classes and their attributes,
methods, and associations to other classes in the system.
The class diagram in Figure 2 shows a simple use case of
an ordering system (or part of one). The customer can
have from zero to several orders, and an order can have
from one to several items.

Figure 2. A class diagram of an ordering system

While useful, the class diagram hardly gives you a

complete picture of the system. For one thing, class
diagrams are static, so they tell you nothing about how
the system will react to user input. For another, class
diagrams are often too detailed to offer a useful overview
of the system. You can only learn so much from studying
a class diagram for a system comprised of thousands of
classes.
You can use collaboration diagrams (or communication
diagrams) and sequence diagrams to see how objects in
the system interact. A collaboration diagram is a simple
way to show system objects and the messages and calls
that pass between them. Figure 3 is a simple
collaboration diagram. Note that each message is
assigned a number that indicates its order in the
sequence.

Figure 3. A collaboration diagram of an ordering

system
Collaboration diagrams are very practical for showing a
birds-eye view of collaborating objects in the system. If
you want a more detailed window into the system's logic
you might want to try drawing a sequence diagram.
Sequence diagrams provide more detail than
collaboration diagrams, but still let you study the system
from a distance. Architects and designers often use
sequence diagrams to fine-tune system design. For
example, looking at the sequence diagram in Figure 4
might lead you to change a number of the system's
method calls to reduce their number. Alternately, you
might change the design by creating a vector (or similar
collection) of all the Items. You could then pass the
vector and a Customer id to the Order constructor. (Note
that doing this would change the roles of the Customer
and Order classes completely.)

Figure 4. A sequence diagram of an ordering

system

The development view

The development view is used to describe the modules of
the system. Modules are bigger building blocks than
classes and objects and vary according to the
development environment. Packages, subsystems, and
class libraries are all considered modules. Figure 5 is a
package diagram showing how packages are nested in
the system.

Figure 5. A package diagram shows how packages

are nested in the system

You can also use the development view to study the

placement of actual files in the system and development
environment. Alternately, it is a good way to view the
layers of a system in a layered architecture. A typical
layered architecture might contain a UI layer, a
Presentation layer, an Application Logic layer, a Business
Logic layer, and a Persistence layer.

The process view

The process view lets you describe and study the
system's processes and how they communicate, if they
communicate with each other at all. An overview of the
processes and their communication can help you avert
unintentional errors. This view is helpful when you have
multiple, simultaneous processes or threads in your
software.
For example, Java servlets usually create threads of one
servlet instance to serve requests. Without access to a
process view, a developer might unintentionally store
something in the servlet class's attributes, which could
lead to complex errors if other threads did the same. The
process view could reduce this type of problem by
describing clearly how to communicate.
The process view can be described from several levels of
abstraction, starting from independently executing logical
networks of communicating programs. The process view
takes into account many of the nonfunctional
requirements or quality requirements (which last month's
column talked about) like performance, availability, etc.
Activity diagrams are quite often used to describe this
view.
The physical view
The physical view describes how the application is
installed and how it executes in a network of computers.
This view takes into account nonfunctional requirements
like availability, reliability, performance, and scalability.
Figure 6 is a deployment diagram of the example
ordering system. It has one node for users who run the
Web browser on their own computers. The ordering
system and database are on their own nodes. The nodes
contain one or more components, which can be either
larger entities or smaller actual components.

Figure 6. A deployment diagram of an ordering

system

The 'plus-one' view

The "plus-one" view of the 4+1 view model consists of
use cases and scenarios that further describe or
consolidate the other views. As discussed in previous
columns in this series, use cases represent the functional
side of the system. In the case of the 4+1 model they
are used to explain the functionality and structures
described by the other views. Some of the other views
also utilize use cases, like the sequence diagram shown
in Figure 4. The use case view consists of use case
diagrams and specifications detailing the actions and
conditions inside each use case. See Resources for more
about use cases.

In conclusion
The 4+1 view model is a useful, standardized method for
studying and documenting a software system from an
architectural perspective. In this fifth article in the
"Designing software architectures" series, I've introduced
you to the five views of the 4+1 model. Each view offers
a window into a different layer of the system. Taken
together they ensure that all of the important aspects of
the system are studied and documented.
Let's review the views:
• The logical view describes the (object-
oriented system) system in terms of abstractions,
such as classes and objects. The logical view
typically contains class diagrams, sequence
diagrams, and collaboration diagrams. Other
types of diagrams can be used where applicable.
• The development view describe the
structure of modules, files, and/or packages in the
system. The package diagram can be used to
describe this view.
• The process view describes the processes
of the system and how they communicate with
each other.
• The physical view describes how the
system is installed and how it executes in a
network of computers. Deployment diagrams are
often used to describe this view.
• The use case view describes the
functionality of the system. This view can be
described using case diagrams and use case
specifications.
Resources offers more links where you can learn about
the 4+1 view model, as well as other architectural views.
In next month's Architectural manifesto I will discuss the
evaluation of architecture prototypes.

Resources
• Mikko talked about use case diagramming
in his column on "How to write a requirements
specification" (developerWorks, December 2004).
• You can learn more about the 4+1 view
model by reading Phillipe Krutchen's "The "4+1"
 View Model of Software Architecture" (in PDF
format).
• Phillipe Krutchen's "The Tao of the
Software Architect" is one of the Software
Engineering Institute's published essays on
software architecture.
• "Documenting Software Architectures," a
comprehensive handbook about software
documentation, includes an excellent section on
views.
• Visit the OMG's UML homepage to learn
more about the Unified Modeling Language
• Granville Miller's UML modeling workbook
(developerWorks, May 2001 through June 2002)
is a hands-on introduction to use case
development and the Unified Modeling Language.
• "Documenting software architectures" (The
Rational Edge, January 2004) is one architect's
account of the importance of good documentation
in large-scale development projects -- as well as a
review of a book worth reading.
• See the Architectural Manifesto column
page for a complete listing of Mikko's columns, as
well as all the articles in the Designing software
architectures series

Mikko Kontio works as a Production

Manager for the leading-edge Finnish software company,
Softera. He holds a Masters degree in Computer Science
and is the author and co-author of several books, the
latest being Professional Mobile Java with J2ME,
published by IT Press. Mikko can be reached at
mikko.kontio@softera.fi.

Pruebas
Las pruebas deben llevarse a cabo durante todo el proceso de desarrollo de sistemas.
Varía su clasificación y características dependiendo del momento en que se lleven a
cabo.

Hay pruebas de integración para cada grupo de componentes generado

dentro de una al final de cada iteración. Al final de la iteración se hacen
pruebas de sistema que abarcan al sistema en su totalidad.
Antes de la etapa de transición, las pruebas las lleva a cabo el equipo de
desarrollo. Se sugiere que lo haga una persona distinta a la que generó el
artefacto y de preferencia un equipo. En la etapa de transición las pruebas
de aceptación las llevan a cabo los usuarios para confirmar que sus
requerimientos han sido satisfechos. Las pruebas de aceptación se pueden
generar mientras se hace el diseño y deben comprobar los requerimientos
funcionales (casos de uso) y no funcionales, deben estar terminadas antes
de generar el código.
Pruebas basadas en la no ejecución
Normal antes de llegar a la generación de código, se habrán creado un gran
número de artefactos que requieran revisión. Para garantizar que estén
completos, correctos, cumpliendo con los requerimientos, se utilizarán las
inspecciones, una técnica utilizada para revisar todo tipo de artefactos. Un
equipo de expertos en la terminología revisa cuidadosamente cada artefacto,
por ejemplo un diagrama de secuencia. El objetivo de la inspección será
encontrar fallas importantes pero no corregirlas.
Pruebas basadas en la ejecución

Estas se deben llevar a cabo a partir de que se genera código. Para su

realización se requiere preparar previamente datos de prueba. La correcta
elección de los datos de prueba será la clave del éxito de las mismas.
Hay dos tipos básicos de pruebas las de caja negra y las de caja de vidrio,
antes conocidas como caja blanca.
Las pruebas de caja negra se preparan considerando únicamente las
especificaciones del sistema, es decir, los requerimientos. Sin asomarse al
código.
En las pruebas de caja de vidrio se examina el código a fin de generar datos
de prueba que garanticen se ejecute cada una de las líneas de código para
poder observar su resultado.
Las cualidades que deben verificarse en las pruebas son: utilidad, fiabilidad,
solidez o robustez, desempeño y corrección.
La utilidad verifica a qué grado el sistema satisface las necesidades del
cliente en cuanto a rentabilidad o utilidades.
La fiabilidad que es la medida de la frecuencia de fallas, es decir el tiempo
entre fallas y el tiempo promedio de reparación. Esta medida permitirá
tomar consideraciones de recuperación.
La solidez o robustez implica varios factores como la respuesta a entradas
inválidas.
El desempeño mide qué tanto el sistema cumple con los tiempos de
respuesta o requisitos de espacio establecidos en las especificaciones.
Finalmente, la corrección se refiere a qué tanto cumple con todas las
especificaciones del usuario.
Un ejemplo de un caso de prueba basada en la ejecución es el siguiente
[Larman, 2005]:
1. Crear una Venta – lo que se va a probar.
2. Agregar algunas líneas de artículos con el método
hacerLineaArticulo (este es el método en particular que queremos
probar).
3. Solicitar el total, y verificar que sea el valor establecido,
usando el método verificaTrue. JUnit indicara una falla si el enunciado
verificaTrue no devuelve True.
Valores: artículo guitarra $2000, piano $10000, total de la venta $12000
Es importante notar que en este caso de prueba no se trata de verificar toda
la clase Venta, cuando la clase ha “aprobado” este caso de prueba se pasa a
verificar el siguiente método.

Referencias
 • Larman, Craig. 2005. “Applyling UML and Patterns: an
Introduction to Object Oriented Analysis and Design and Iterative
Development”, Prentice Hall, 3a edición
• Stumpf, Robert, et al. 2005. “Object Oriented Systems
Analysis and Design with UML”, Pearson Education.
• Schach, Stephen, 2005. “Análisis y diseño orientado a objetos
con UML y el Proceso Unificado”. Mc Graw Hill.

Refactorización
Según Martin Fowler refactorización es el método disciplinado, estructurado,
para reescribir o reestructurar código existente sin cambiar su
comportamiento externo, aplicando pequeños pasos o transformaciones sin
re-ejecutar pruebas a cada paso.
Cada refactorización es muy corta, sólo se aplica una transformación
pequeña que mantiene el comportamiento en un momento dado. Después
de la transformación se ejecutan las pruebas unitarias para probar que la
refactorización no causó una falla.
Los objetivos de la refactorización son [Larman, 2005]:
• Eliminar código duplicado
• Mejorar claridad
• Acortar métodos largos
• Corregir clases con mucho código o con muchas variables de
instancia
• Reducir acoplamiento
• Mejorar la cohesión
• En general, mejorar código mal escrito o de baja calidad.
El remedio es utilizar las refactorizaciones, similares a los patrones en
cuanto a que tienen un nombre y un objetivo para mejorar el diseño.
Para revisar el catálogo de refactorizaciones, se sugiere revisar el libro:
“Improving the Desing of Existing Code”, de Martin Fowler o el sitio
http://www.refactorización.com
Otras páginas con información válida sobre refactorizaciones:
www.junit.org
www.testdriven.com
Referencias
• Larman, Craig. 2005. “Applyling UML and Patterns: an
Introduction to Object Oriented Analysis and Design and Iterative
Development”, Prentice Hall, 3a edición
• Fowler, Martin. “Refactorización Home Page”.
http://www.refactorización.com/ consultado el 9 de junio de 2006.

El glosario contiene 8 términos.

 ABCDIPR

A
Descripción de la organización, estructura y motivación de un sistema. Las
Arquitectura:
arquitecturas pueden tener varios niveles.
B
Es la colección de datos requeridos por una organización para manejar las
Base de datos: operaciones de la misma, mantenida y acomodada de tal forma en que es
acezada por diferentes aplicaciones.
C
Especifica la funcionalidad del sistema desde el punto de vista del usuario.
Caso de Uso: Detalla las interacciones entre un actor y el sistema para lograr una meta
específica.
D
Diagrama de
Diagrama de UML utilizado para modelar los detalles de procesos complejos.
actividad:
Diagrama de Diagrama utilizado para describir el comportamiento de instancias de un
Transición de elemento de un modelo tales como un objeto o una interacción, en respuesta
Estados: a eventos del sistema.
I
Implementación: Es la traducción del diseño del sistema a código.
P
Patrón: Solución probada a un problema de diseño común
R
Según Martin Fowler refactorización es el método disciplinado, estructurado,
para reescribir o reestructurar código existente sin cambiar su
Refactorización:
comportamiento externo, aplicando pequeños pasos o transformaciones sin
re-ejecutar pruebas a cada paso.