Arquitectura cliente - servidor 

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes.

Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

Arquitectura de software

El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo.

Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.

La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema.

Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estatura de un sistema mostrando sus clases y atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejara que el sistema, y los elementos se encargaran del funcionamiento y la relación entre uno y otro.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clases: atributos, métodos, visibilidad.

Relaciones: herencia, composición, agregación, asociación  y uso

Atributos:

Los atributos y características  de una clase pueden ser de tres tipos,  los que definen el grado de comunicación y visibilidad de ellos con el entorno, estas son:

Public: indica que el atributo será visible tanto dentro  como fuera de la clase, es decir, que es accesible desde todos lados.

Private: indica que el atributo solo será accesible desde dentro de la clase  (solo sus métodos pueden accesar).

Protected: indica que el atributo no será accesible desde  fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven(herencia).

Relaciones entre las clases:

Bueno ya definido el concepto de clase,  es necesario explicar  como se pueden interrelacionar dos o mas clases (cada uno con características y objetivos diferentes).

Antes es necesario el concepto de cardinalidad de las relaciones: En UML la cardinalidad de las relaciones indica el grado y el nivel  de dependencia se anotan en cada extremo de la relación y  estas pueden ser: 

Uno a muchos: 1..*(n..1).

 0 o muchos:0..(0..n).

Numero fijo: m (m denota el numero). 

Agregación: Para modelar objetos completos, no bastan los tipos de datos básicos que proveen de lenguajes: enteros, reales y secuencia de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación tenemos do posibilidade.

Por valor: es un tipo de relación estática, en donde el tiempo  de vida del objeto esta condicionado por  el  tiempo de vida del que lo incluye. este tipo de relación es comúnmente  llamada  composición  (el objeto base se construye a partir de objeto incluido, es decir, “parte/todo”).

 Por referencia: es un tipo de relación dinámica, en donde el tiempo de vida del objeto es independiente del que lo incluye.

Agregación: (el objeto base  utiliza al incluido por funcionamiento).