Arquitectura de Software
-
Upload
pilar-pardo -
Category
Education
-
view
1.396 -
download
0
Transcript of Arquitectura de Software
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