Arquitectura de Software

Definición de Arquitectura de SW

La arquitectura se refiere a la forma en la que es diseñada

tanto física como lógicamente un Software.

Programar sin una arquitectura en mente es como explorar

una gruta sólo con una linterna:

No sabes dónde estás, dónde has estado, ni hacia dónde vas.

- Danny Thorpe-

Objetivo de la Arquitectura de SW

Ser la base de un Sistema de Software.

Debe ser ser construida pensando en satisfacer las necesidades actuales, como en proporcionar al software las

capacidades necesarias para permitir su

mantenimiento y evolución de acuerdo a las necesidades del negocio y las solicitudes de los

usuarios y clientes.

Rol del Arquitecto de SW

Es el encargado de establecer a que nivel, con que

estrategia, y que herramientas son necesarias para

realizar una implementación que satisfaga los requisitos

funcionales y no funcionales de los sistemas.

Arquitectura de SW

• Arquitectura: desarrolla un plan general del sistema, asegurando que las necesidades de los usuarios sean atendidas.

• Ingeniería: proyecta la estructura física interna, dando forma a los objetivos definidos por la arquitectura; considerando la eficiencia y la eficacia del proyecto.

• Construcción: elabora la estructura, con el uso de herramientas y datos.

• Ofrece una estructura para pensar, proyectar, elaborar y

desarrollar aplicaciones que se integren y funcionen bien.

• Arquitectura Cliente/Servidor en dos capas: • Front/end

• Back/end

Arquitectura de SW

Modelo de Arquitectura de 2 Capas

Cliente/Servidor

• Front/end

– Es la parte de la aplicación que interactúa con el usuario.

– Basados en una interfaz gráfica con el usuario (GUI). El

Cliente corre la aplicación que ofrece la interfaz con el

usuario.

• Back/end

– Es la parte no-interactiva de la aplicación. La mayor parte

reside en las Bases de Datos (relacionales o no).

Modelo de Arquitectura

Cliente/Servidor

• Aplicaciones Simples: no requieren una gran Base de Datos

compartida, pueden ser elaboradas solamente en el Cliente.

• Aplicaciones Complejas: exigen dos capas, una para la aplicación del

usuario (Cliente) y otra para la base de datos (Servidor).

Eventualmente, el Cliente y el Servidor podrán estar en el mismo

equipamiento.

Modelo de 3 Capas

Es el sucesor de la arquitectura de dos capas, ésta

implementa una ó N capas adicionales las cuales se encargan

de encapsular las reglas del negocio asociadas con el sistema

y las separa de la presentación y del código de la D.B.

Los servicios se forman de componentes

El modelo de 3 capas está destinado a ayudarnos a construir

componentes físicos a partir de los niveles lógicos.

Así que podemos empezar tomando decisiones sobre qué

parte lógica de la aplicación vamos a encapsular en cada

uno de nuestros componentes de igual modo que

encapsulamos los componentes en varios niveles.

Un nivel está conformado por varios componentes, por

tanto puede suplir varios servicios.

Los componentes del nivel de usuario, proporcionan la interfaz

visual que los clientes utilizarán para ver la información y los

datos.

En este nivel, los componentes son responsables de solicitar y

recibir servicios de otros componentes del mismo nivel o del

nivel de servicios de negocio.

Es muy importante destacar que, a pesar de que las funciones

del negocio residen en otro nivel, para el usuario es

transparente la forma de operar.

Nivel Usuario

Como los servicios de usuario no pueden contactar

directamente con el nivel de servicios de datos, es

responsabilidad de los servicios de negocio hacer de puente

entre estos. Los objetos de negocio proporcionan servicios que

completan las tareas de negocio tales como verificar los datos

enviados por el cliente. Antes de llevar a cabo una transacción

en la D.B.

Los componentes de los servicios de negocio también nos

sirven para evitar que el usuario tenga acceso directo a la

base de datos, lo cual proporciona mayor seguridad en la

integridad de ésta.

Nivel de Negocios

El nivel de datos se encarga de las típicas tareas que realizamos con

los datos: Inserción, modificación, consulta y borrado.

La clave del nivel de datos es que los papeles de negocio no son

implementados aquí.

Aunque un componente de servicio de datos es responsable de la

gestión de las peticiones realizadas por un objeto de negocio.

Nivel de Datos

Un nivel de servicios de datos apropiadamente

implementado, debería permitir cambiar su localización sin

afectar a los servicios proporcionados por los componentes

de negocio.

Nivel de Datos

La arquitectura de un sitio Web tiene tres componentes principales:

un servidor Web, una conexión de red, y uno o más clientes (browsers).

El servidor Web distribuye páginas de información formateada a los

clientes que las solicitan. Los requerimientos son hechos a través de

una conexión de red, y para ello se usa el protocolo HTTP.

Arquitectura Web

Arquitectura básica de una aplicación/sitio Web

La información mostrada en las páginas está típicamente almacenada

en archivos. Sin embargo, muchas veces esta información está almace-

nada en una base de datos, y las páginas son creadas dinámicamente.

Los sitios Web que usan este esquema, son llamados sitios dinámicos.

Arquitectura Web

Las páginas Web son el componente principal de una aplicación o sitio Web. Los

browsers piden páginas (almacenadas o creadas dinámicamente) con información a

los servidores Web.

En algunos ambientes de desarrollo de aplicaciones Web, las páginas contienen

código HTML y scripts dinámicos, que son ejecutados por el servidor antes de

entregar la página.

Una vez que se entrega una página, la conexión entre el browser y el servidor Web se

rompe (a diferencia de otros esquemas tipo cliente/servidor). Es decir que la lógica

del negocio en el servidor solamente se activa por la ejecución de los scripts de las

páginas solicitadas por el browser (en el servidor, no en el cliente).

Páginas Web

Cuando el browser ejecuta un script en el cliente, éste no tiene

acceso directo a los recursos del servidor.

Hay otros componentes que no son scripts, como los applets o

los componentes ActiveX. Los scripts del cliente son por lo general

código JavaScript o VBSscript, mezclados con código HTML.

Script en el Cliente

Formularios

La forma más común de capturar la información dada por el usuario, es a

través de formularios. Un formulario (form) es una colección de campos de

entrada: textbox, text area, checkbox, radio button group, button y selection

list.

Cuando un formulario es llenado, se envía al servidor usando una operación

submit solicitada por el usuario típicamente al hacer click en un botón.

Arquitectura Web

Servidor Web

En muchas aplicaciones Web hay una capa intermedia, compuesta por un

conjunto de componentes, que se ejecutan no necesariamente en el servidor

Web, sino en otros servidores de aplicaciones. Esta capa encapsula la lógica

del negocio, y al ser componentes compilados puede contener objetos, con

sus métodos y atributos (llamados business objects).

Arquitectura Web

Los diagramas a través de los cuales se representa el

diseño y distribución del software, pueden mostrar

diferentes vistas de un mismo sistema y de las condiciones

que existen en el entorno donde se depliega.

El modelo 4 + 1 vistas, es una propuesta que establece las diferentes perspectivas a través de las cuales

se puede representar el diseño y arquitectura de un sistema de software

Fuente: Sorey García

Fuente: Sorey García

Framework para Descripción de Arquitectura, basado en vistas lógicas y físicas UML y una

vista funcional de casos de uso.

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-user

Functionality

Programmers

Software management

Performance

Scalability

Throughput

System integrators

System topology

Delivery, installation

communication

System engineering

Analysts/Designers

Structure

Esta propuesta presenta su propio esquema de modelado, pero como bien sabemos, la notación

más reconocida para el modelamiento de sistemas de software es el UML

UML es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y

documentar artefactos de un sistema de software, y se usa para entender, diseñar, configurar,

mantener y controlar la información sobre los sistemas a construir