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;

ClienteCliente

PedidoPedido

1

*

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.

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.

ClienteCliente

PedidoPedido

1

*

LineaPedidoLineaPedido

*1

class Cliente {

private Pedido[] losPedidos;

}

class Pedido {

}

Para el caso de asociaciones calificadas se tendría:

PedidoPedido LineaPedidoLineaPedido0..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 Persona

Trabajo

Patrón Empleado

* 1..* Empresa Persona

Trabajo

Patrón Empleado1 1

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.

procesar()

Pedido

procesar()

Pedido

FacturaFactura

agrega(Producto&)

Pedido

agrega(Producto&)

Pedido

ProductoProducto

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.

Class Pedido {

void procesar{

Factura = new miFactura();

}

}

class Producto {};

class Pedido {

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

Renta : Video : ClasificacionControlRenta

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.

SalesLineItem

quantity : Integer

getSubtotal()

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID : ItemID

...

Store

address : Addressname : Text

addSale(...)

Payment

amount : Money

...

1..*

1..*

Register

...

endSale()enterItem(...)makeNewSale()makePayment(...)

Sale

isComplete : Booleantime : DateTime

becomeComplete()makeLineItem(...)makePayment(...)getTotal()...

1

1

1

1

1

1

* 1

23

4

56

7

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 nombreAmbos pueden realizar un conjunto de interfaces.Pueden participar en relaciones de dependencia, generalización y asociación.Ambos pueden anidarseAmbos pueden tener instanciasAmbos pueden participar en interacciones

DIFERENCIASLas Clases Los ComponentesRepresentan abstracciones lógicas Representan elementos físicos Es decir los componentes pueden estar en nodos y las clases noPueden 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.

PARECIDOSAmbos tienen nombrePueden participar en relaciones de dependencia, generalización y asociación.Ambos pueden anidarseAmbos pueden tener instanciasAmbos pueden participar en interacciones

DIFERENCIAS Los Nodos Los ComponentesSon 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 DespliegueSeguidamente 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ísicaPara 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 empotradoEl 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 servidorLa 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ónEn 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

o3.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 5Introducing 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.

 A B C D I P R

A

Arquitectura:Descripción de la organización, estructura y motivación de un sistema. Las arquitecturas pueden tener varios niveles.

B

Base de datos:Es la colección de datos requeridos por una organización para manejar las operaciones de la misma, mantenida y acomodada de tal forma en que es acezada por diferentes aplicaciones.

C

Caso de Uso:Especifica la funcionalidad del sistema desde el punto de vista del usuario. Detalla las interacciones entre un actor y el sistema para lograr una meta específica.

D

Diagrama de actividad:

Diagrama de UML utilizado para modelar los detalles de procesos complejos.

Diagrama de Transición de Estados:

Diagrama utilizado para describir el comportamiento de instancias de un elemento de un modelo tales como un objeto o una interacción, en respuesta 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

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.