1. Arquitectura de Software
28
-
Upload
ramiro-de-la-cruz-monge -
Category
Documents
-
view
237 -
download
0
description
habla de como esta formado un software y sus características rincipales
Transcript of 1. Arquitectura de Software
Introducción a la arquitectura de los sistemas de información.
Definiendo un objeto de negocio.
Desarrollo basado en componentes.
Agenda
Introducción a la
arquitectura de los
sistemas de información
¿Por qué hablar de arquitectura?
En la medida que el tamaño de los sistemas crecen, los algoritmos y las estructuras de datos dejan de convertirse en el mayor problema.
El nuevo reto es diseñar y especificar la estructura global del sistema.
Introducción
Arquitectura se refiere a una representación abstracta de los módulos / componentes de un sistema y su entorno.
Idealmente, la arquitectura no incluye detalles de implementación.
Definiciones
Rol del Arquitecto.El arquitecto obtiene información sobre el problema y diseña una solución que satisfaga los requisitos funcionales y los no funcionales, manteniendo flexibilidad cuando los requisitos cambien.
Se apoya en patrones, modelos y frameworks.
Participa activamente en todas las fases del desarrollo.
Establece lineamientos generales que deben ser tomados en cuenta en el desarrollo de nuevos proyectos.
Definiciones
Atributos de calidad de la arquitectura
Arquitectura
Rendimiento
Escalabilidad
Mantenibilid
ad
Reusabilidad
Compatibilida
dDisponibilida
d
Portabilidad
Oportunidad
Seguridad
Flexibilidad
Definiciones
La arquitectura reúne las principales características el software y del sistema en relación con el software, se plasma aspectos como:
El ¿Qué? (requisitos funcionales) y el ¿Cómo? (requisitos no funcionales).
Estilos arquitectónicos en los que será implementado el Software: objetos, capas, repositorios, etc.
Patrones que serán usados (DAO, MVC, etc).
Distribución física.
….
¿Qué es una arquitectura y qué
aporta a un sistema?
Co
nta
inin
g a
nd
Co
nn
ecti
ng
Lo
gic
Defi
nin
g
Lo
gic
Logic to LogicLogic to Web
Browser
Accessin
g
Data
Data
Access
Web
Services
Binary
Communication
Distributed
Transactions, etc.
Queued
Messaging
Usin
g
Lo
gic
Web Browser Standalone Client
Objects
Remote Logic
Plataforma actual de las aplicaciones
Origen de DatosServicios
Capa de Datos
Capa de Presentación
Capa de Negocio
Procesos
de Negocio
Componentes
de Negocio
Entidades
de Negocio
Ciclo de Vida del software
Ad
min
istr
ació
n O
pe
rativa
Co
mu
nic
acio
ne
s
Agentes Servicios
Agentes Servicios
Interfaces Servicios
Agentes Servicios
Interfaces Servicios
Seguridad
Usuarios
Aplicaciones por capas
Caso práctico: Definiendo unaarquitectura
Definiendo un Objeto de
Negocio
Entidades: persistencia de
objetos de negocio
Las entidades de negocio exponen:Descriptores de acceso a propiedades.
Descriptores de acceso a colecciones para subcolecciones de datos relacionados
public class Usuario{
private int idUsuarioField;
public int IdUsuario()
{
get{
return idUsuarioField;
}
set{
idUsuarioField = value;
}
}
}
Entidades de Negocio
Entre la comunicación de componentes dentro de un modelo distribuido, se debe seleccionar uno de los siguientes mecanismos:
Serialización XML
Serialización Binaria
Cada mecanismo está asociado al ámbito de comunicación entre los componentes, servicios y/o sistemas.
Transferencia de objetos de
negocio
Tranferencia de Objetos de Negocioentre aplicaciones
Desarrollo basado en
componentes
El desarrollo basado en componentes, se basa en los siguiente principios:
Una mejor granularidad de los componentes de la aplicación.
Mejora el mantenimiento a nivel de cada capa de la aplicación.
Permite diversas formas de implementación por el lado del cliente.
Permite una mayor integración entre sistemas, de forma transparente al usuario final.
Generalidades
El acoplamiento, se basa en trabajar bajo una fuerte dependencia entre las implementaciones de los componentes de un sistema, haciendo compleja su mantenibilidad.
El desacoplamiento, permite construir componentes del sistema de forma independiente, estableciendo contratos (interfaces) para la comunicación entre éstas. (base para SOA)
Acoplamiento / Desacoplamiento
Es la parte mas importante de la aplicacion por la funcionalidad que brinda.
Se basa en la implementación de los siguientes elementos:
Interfaces de Servicio
Procesos de Negocio (Flujos)
Componentes de Negocio
Entidades Empresariales
Diseño de componentes de
negocio
Involucra la construcción de operaciones de flujo de negocio asociado a acciones puntuales, de un flujo simple y bajo la administración una o varias transacciones.
Por lo general una lógica de negocio se implementa bajo la concepción de un caso de uso, al igual que los procesos de negocio.
Lógica de Negocio
Involucra acciones de integración y conjunto de pasos, asociados a un flujo de negocio.
Se recomienda el uso de Workflows para:
Administrar un proceso que conlleve varios pasos y transacciones de ejecución larga.
Exponer una interfaz que implemente un proceso empresarial que habilite la aplicación para establecer
una conversación o un contrato con otros servicios.
Procesos de Negocio
Gestionar la comunicación con el cliente o servicio externo.
Gestionar las transacciones.
Gestionar el flujo lógico de los datos, reflejando un caso de uso.
Integrar la comunicación entre los diversos orígenes de datos.
Controlar la participación de otros sistemas dentro del flujo lógico.
Responsabilidad de la capa de
Negocio
Capa de Datos
Capa de Negocios
Capa de Presentación
Distribución de
Responsabilidades
Manejar el Almacenamiento de los Datos a Utilizar.
Partes de esta Capa:Componentes lógicos de acceso a datos
Agentes de Servicios
Capa de Datos
La parte mas importante de la aplicacion por la funcionalidad que brinda.
Partes de esta Capa:Interfaces de Servicio
Flujos de Trabajo
Componentes Empresariales
Entidades Empresariales
Capa de Lógica de Negocios
Componentes necesarios para habilitar la interactuación del usuario con la aplicación
Partes de esta Capa:Componentes de interfaz de usuario
Componentes de proceso de usuario
Capa de Presentación
Implementando un modelobasado en componente
