martes, 9 de octubre de 2012

DIAGRAMA DE COMPONENTES


Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.
En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

DIAGRAMA DE DESPLIEGUE


Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.
En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.
La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

ESTILO ARQUITECTONICO

Es la clasificación arquitectónica en los términos de forma, técnicas, materiales, período, región, etc. Surgen del estudio de la evolución y la historia de la arquitectura. En la historia arquitectónica, por ejemplo, el estudio de la arquitectura gótica, se incluyen todos los aspectos del contexto cultural en que entró el diseño y la construcción de estas estructuras. El estilo arquitectónico es una manera de clasificar la arquitectura que da énfasis a las características del diseño, dando lugar a una terminología como el “estilo gótico”.

Base de datos relacional


Fue propuesto en 1970 por Codd, este es un modelo
simple potente y formal para representar la realidad, también ofrece una base firme
para enfocar y analizar formalmente muchos problemas relacionados con la gestión
de  bases  de  datos,  como  el  diseño,  la  redundancia,  la  distribución  etc.  El
formalismo  y  una  base  matemática,  son  las  piedras  angulares  del  modelo
relacional , el elemento básico del modelo es la relación y un esquema de bases de
datos relacional es una colección de definiciones de relaciones. En este modelo, el
lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia
de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja
de que es más fácil de entender y de utilizar para un usuario esporádico de la base
de  datos.  La  información  puede  ser  recuperada  o  almacenada  mediante
"consultas"  que  ofrecen  una  amplia  flexibilidad  y  poder  para  administrar  la
información.

Bases de datos transaccionales


Son bases de datos cuyo único fin es el envió y
recepción de datos a grandes velocidades, estas bases son muy poco comunes y
están dirigidas por lo general al entorno de análisis de calidad, datos de produccióne industrial, es importante entender que su fin único es recolectar y recuperar los
datos a la mayor velocidad posible, por lo tanto la redundancia y duplicación de
información no es un problema como con las demás bases de datos, por lo general
para poderlas aprovechar al máximo permiten algún tipo de conectividad a bases
de datos relacionales.

MODELO-VISTA-CONTROLADOR


El objetivo de este tipo de modelos es de intentar repetirse lo menos posible y de tenerlo todo organizado o sea hacer una distinción entre la lógica de toda la aplicación y presentación.

Los Fundamentos básicos del MVC son los siguientes:
  • Modelo: Esta sirve como representación específica de toda la información con la cual el sistema va a trabajar. La lógica de datos nos puede llegar a asegurar la integridad de ellos y nos permitirá derivar nuevos datos. ¿Como lo hace?  Pues , no permitiendonos comprar un número de unidades negativas, y también calculando si hoy puede ser el cumpleaños del usuario/a o también los totales, impuestos o importes en un sistema de venta.
  • Vista: Presenta el modelo con el que va a interactuar el usuario, más conocida como interfaz.
  • Controlador: El controlador responde más bien a eventos, normalmente son acciones que el usuario invoca, implica cambios en el modelo y también en la vista (interfaz).
Es un modelo de distribución de software donde el software y los datos que maneja se alojan en servidores de la compañía de tecnologías de información y comunicación (TIC) y se accede con un navegador web o un cliente ligero especializado, a través de Internet  La empresa TIC provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. Regularmente el software puede ser consultado en cualquier computador, esté presente en la empresa o no. Se deduce que la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software están hospedados en la compañía de TIC.

ASP


La tecnología ASP está estrechamente relacionada con el modelo tecnológico y de negocio de su fabricante. Intenta ser solución para un modelo de programación rápida ya que "programar en ASP es como programar en Visual Basic y C#", por supuesto con muchas limitaciones y algunas ventajas específicas en entornos web.
Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados como algunos controles ActiveX así como componentes del lado del servidor, tales como CDONTS, por ejemplo, que permite la interacción de los scripts con el servidor SMTP que integra IIS.

Se facilita la programación de sitios web mediante varios objetos integrados, como por ejemplo un objeto de sesión basada en cookies, que mantiene las variables mientras se pasa de página a página.
Está limitada (la tecnología ASP) a funcionar solo en Microsoft Windows, pues requiere el servidor IIS; aunque en las versiones "9x" de Microsoft Windows era posible instalarMicrosoft Personal Web Server (PWS) y de esa manera usar asp. También puede instalarse software de terceros como por ejemplo Baby Web Server.
Por lo que su uso es cuestionado por la mayoría de los programadores web, quienes prefieren otros lenguajes de programación del lado del servidor como por ejemplo PHP, Perl,Java etc.

Cliente liviano o cliente ligero


Un cliente liviano o cliente ligero (thin client o slim client en inglés) es una computadora cliente o un software de cliente en una arquitectura de red cliente-servidor que depende primariamente del servidor central para las tareas de procesamiento, y principalmente se enfoca en transportar la entrada y la salida entre el usuario y el servidor remoto. En contraste, un cliente pesado realiza tanto procesamiento como sea posible y trasmite solamente los datos para las comunicaciones y el almacenamiento al servidor.
Muchos dispositivos de cliente liviano ejecutaban solamente navegadores web o programas de escritorio remoto, lo que significaba que todo el procesamiento significativo ocurría en el servidor. Sin embargo, dispositivos recientes vendidos como clientes livianos pueden correr sistemas operativos completos tales como GNU/Linux Debian, calificándolos comonodos sin disco o clientes híbridos. Algunos clientes livianos también son llamados "terminales de acceso".

Por consecuencia, el término "cliente liviano", en términos de hardware, ha venido abarcar cualquier dispositivo comercializado o usado como un cliente liviano en la definición original, incluso si sus capacidades reales son mucho mayores. El término también es a veces usado en un sentido incluso más amplio que incluye nodos sin disco.

CLIENTE PESADO


El término "cliente pesado", a diferencia de un cliente liviano, se utiliza para una aplicación gráfica de cliente que se ejecuta en el sistema operativo del usuario. Un cliente pesado suele tener una mayor capacidad de procesamiento y es posible que tenga una interfaz gráfica sofisticada. Sin embargo, esto conlleva un desarrollo adicional y suele ser una mezcla de la lógica de presentación (interfaz gráfica) con la lógica de la aplicación (potencia de procesamiento).
Este tipo de aplicación suele instalarse en el sistema operativo del usuario y se debe instalar una nueva versión cuando se realiza una actualización. Para solucionar esto, los programadores de aplicaciones pesadas, por lo general, incorporan una funcionalidad que se ejecuta al iniciar la aplicación y verifica un servidor remoto para saber si está disponible alguna versión más nueva. De ser así, le indica al usuario que descargue e instale la actualización. 

Arquitectura orientada a servicios de cliente SOA




SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lógica de negocio de sus sistemas separados.
Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo.
La necesidad de tal marco se deriva de la evolución del software de negocio. En los comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades específicas: contabilidad, compras, nómina de sueldos, transporte. Cada aplicación fue desarrollada sin consideración de otros sistemas en la empresa y como comunicarse con ellos. Porque las aplicaciones eran auto suficientes, la información común a toda la empresa (como por ejemplo: la dirección del cliente) y funciones específicas de negocios (como por ejemplo: buscar un nombre) aparecían en todas partes y requerían un código complejo para, todos o muchos de los sistemas independientes.