tipos de arquitectura

TIPOS DE ARQUITECTURA

-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.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

Ventajas

• Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. Esta centralización también facilita la tarea de poner al día datos u otros recursos (mejor que en las redes P2P)..
• Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o servidores).
• Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación.
• Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de empleo.

Desventajas

• La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultaneas al mismo servidor, puede ser que cause muchos problemas para éste (a mayor número de clientes, más problemas para el servidor). Al contrario, en las redes P2P como cada nodo en la red hace también de servidor, cuanto más nodos hay, mejor es el ancho de banda que se tiene.
• El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un servidor está caído, las peticiones de los clientes no pueden ser satisfechas. En la mayor parte de redes P2P, los recursos están generalmente distribuidos en varios nodos de la red. Aunque algunos salgan o abandonen la descarga; otros pueden todavía acabar de descargar consiguiendo datos del resto de los nodos en la red.
• El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el coste.
• El cliente no dispone de los recursos que puedan existir en el servidor. Por ejemplo, si la aplicación es una Web, no podemos escribir en el disco duro del cliente o imprimir directamente sobre las impresoras sin sacar antes la ventana previa de impresión de los navegadores.

-ARQUITECTURA MONOLITICA

Es un modelo en el cual el sistema operativo y todos los servicios fundamentales residen en un monitor monolítico que se accede a través de un mecanismo de llamada al núcleo.

Ventajas

Con un monitor monolítico, los servicios fundamentales que requieran acceso a los recursos del núcleo deben residir en este. De esta forma, la complejidad del núcleo aumenta, aumentando la probabilidad de encontrar errores. Asimismo, el acceso a entrada-salida, al vector de interrupciones y a la memoria física se puede restringir al núcleo por razones de la seguridad, lo que significa que la mayoría de los drivers de dispositivos deben residir en el núcleo.

Cruzar la barrera kernel/aplicación es con frecuencia costoso, así en algunos casos, los drivers que de otro modo se podrían poner en ejecución modo usuario, tal como drivers de gráficos, se incorporan en el núcleo por razones de performance.

Mientras que las aplicaciones no pueden corromper el núcleo, cualesquiera de estos drivers de dispositivos pueden – aumentando la probabilidad de que ocurran errores fatales

Características

•Es un intento de paliar los problemas de la arquitectura plana.
•Su aportación estriba en que los procesos de usuario ejecutan en espacios de direccionamiento diferentes al del sistema operativo.
•Las implementaciones de UNIX han respondido tradicionalmente este diseño.
•Se aislan del sistema de los errores de los procesos de usuario, pero nuevos dispositivos aparecen en el mercado continuamente y es preciso escribir manejadores para soportarlos. De nuevo el sistema crece y la probabilidad del fallo aumenta.
•El programa de usuario lleva a cabo las llamadas al sistema mediante interrupciones software o traps.
•Sólo en modo supervisor se permite al procesador ejecutar instrucciones privilegiadas. Accesos a las posiciones de memoria asignadas a los adaptadores de dispositivo .
•Copia de datos entre espacios de direccionamiento diferentes.

-ARQUITECTURA DE TRES NIVELES

La arquitectura de software incluye los aspectos estáticos y dinámicos más signi­ficativos del software que se desea crear. De acuerdo Robert Pressman, la arquitectura de software no es otra cosa que “…una descripción de los subsistemas y los componentes de un sistema informático y las relaciones entre ellos”. De igual manera, la arquitectura de software de tres niveles, incluye todos estos aspectos, y además, brinda mejores opciones para proyectos informáticos de gran alcance y complejidad.

CAPAS O NIVELES

Capa de presentación

Es la que se encarga de que el sistema interactúe con el usuario y viceversa, muestra el sistema al usuario, le presenta la información y obtiene la información del usuario en un mínimo de proceso. En el mundo de la informática es conocida como interfaz gráfica y debe tener la característica de ser amigable, o sea, entendible y fácil de usar para el usuario. Esta capa se comunica únicamente con la capa intermedia o de negocio.

Capa de negocio

Es donde residen las funciones que se ejecutan, se reciben las peticiones del usuario, se procesa la información y se envían las respuestas tras el proceso. Se denomina capa de negocio o capa de lógica del negocio, porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de acceso a datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él.

Capa de acceso a datos

Esta capa es la encargada de almacenar los datos del sistema y de los usuarios. Su función es almacenar y devolver datos a la capa de negocio, aunque para esto también es necesario en algunos casos, que tengan procedimientos almacenados y funciones dentro de la capa. En una arquitectura de tres capas, esta capa es la única que puede acceder a los mismos. Está formada por uno o variossistemas gestores de bases de datos, localizados en un mismo servidor o en varios.

Estas capas, pueden estar localizadas todas en un mismo ordenador, si el programa o software informático que se desarrolla es de baja complejidad, porque si, por el contrario, fuera de gran complejidad tanto los datos como la lógica de negocio, entonces cada una de las capas pudiera estar situada en diferentes ordenadores, para mejorar la funcionalidad de las mismas, incluso, en productos de gran complejidad, existen varios ordenadores para la capa de acceso a datos, y varios ordenadores para la capa de negocio

Otras arquitecturas  menos conocidas son:

• Máquinas virtuales
• En pipeline.
• En pizarra
• Entre pares.
• Orientada a servicios.
• Dirigida por eventos.

Arquitectura de software

que es :
En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema".





Arquitectura y sus efectos en los Stakeholders

€ La arquitectura afecta a todos losrelacionados con el proyecto, afecta a los clientes, al gerentes, al equipo dedesarrollo, al equipo de pruebas, etc. Cadastakeholder se preocupa por partes especificas del sistema, y esto se ve reflejado en la arquitectura del sistema. La arquitectura provee un lenguaje mediante el cual los stakeholders comprenden el sistema y se comunican para tomar decisiones importantes.

Decisiones tempranas de diseño

€ El diseño de la arquitectura describe la forma en que el sistema está compuesto. Esto hace que se creen

una serie de restricciones a la implementación como la forma de comunicación, y como se van a asignar los recursos.

Estilos arquitectónicos

• Describen una clase de arquitecturas, o piezas significantes de una arquitectura.

• Son muy usados en la práctica. Es un paquete coherente de decisiones de diseño.

• Tienen propiedades identificadas que permiten el re-uso.

El ciclo de vida RUP

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baselin (Línea Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.

[editar]Principales características

• Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
• Pretende implementar las mejores prácticas en Ingeniería de Software
• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

[editar]Fases

• Establece oportunidad y alcance
• Identifica las entidades externas o actores con las que se trata
• Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

'Proceso': Las etapas de esta sección son: (Revise nuevamente la gráfica)

• Modelado de negocio
• Requisitos
• Análisis y Diseño
• Implementación
• Pruebas
• Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

• Gestión del cambio y configuraciones
• Gestión del proyecto
• Entorno

La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

• Inicio (también llamado Incepción o Concepción).
• Elaboración.
• Desarrollo (también llamado Implementación, Construcción).
• Cierre (también llamado Transición).

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

Diagrama de clases

Ejemplo de diagrama de clases de una Universidad.

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema 

mostrando sus clases, 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 manejará en el sistema, y los componentes que se

 encargaran del funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura

 conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de

 software orientados a objetos

REQUISITOS

Modelo requisitos UML

View more PowerPoint from ramirezjaime

CASO DE USO

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores.En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

Requerimientos Funcionales

Son todas aquellas acciones que se van a realizar en el software o como se va a comportar el software.

Requerimientos no Funcionales

Se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.

UML

 diagramas UML.

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje demodelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento

 perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

Actor (UML)

Ilustración de un actor, junto con los demás elementos de un diagrama de casos de uso.

Ejemplo sencillo de diagrama de casos de uso, donde se muestran los actores 

En el Lenguaje Unificado de Modelado (UML), un actor "especifica un rol jugado por un usuario o 

cualquier otro sistema que interactúa con el sujeto."

Un actor modela un tipo de rol jugado por una entidad que interactúa con el sujeto

 (esto es, intercambiando signos y datos), pero que es externo a dicho sujeto.

Los actores pueden representar roles jugados por usuarios humanos, hardware externo,

 u otros sujetos. Un actor no necesariamente representa una entidad física específica, sino

 simplemente una faceta particular (es decir, un "rol") de alguna actividad que es relevante

 a la especificación de sus casos de uso asociados. Así, una única instancia física puede 

jugar el rol de muchos actores diferentes y, asimismo, un actor dado puede ser interpretado

 por múltiples instancias diferentes.

UML  no permite asociaciones entre Actores. A pesar de todo, esta restricción es usualmente 

violada en la práctica, en la medida que la generalización/especialización de relaciones entre

 actores es útil para el modelado de los comportamientos de superposición entre actores.