Arquitecto debe tomar en cuenta RN escalable, seguro y extensible =JEE

El papel de un arquitecto

El objetivo del arquitecto es la de reorganizar el entorno para dar forma

visualizar la
comportamiento de un sistema. Crean el modelo para el sistema, y definen
la forma en que los elementos del sistema trabajan juntos. Arquitectos distinguen
entre los requisitos funcionales y no funcionales del sistema, y que son responsables
para la integracin de los requisitos no funcionales en el sistema.
El arte o la prctica de estructuras de diseo y construccin y, especialmente,
los habitables

Tipos arquitectura
El arquitecto recoge informacin sobre el problema y disea una solucin que satisface la
funcional y no funcional requisitos del cliente y es lo suficientemente flexible como para
evolucionar cuando los requisitos cambiar.
La arquitectura del sistema se puede formular en un estilo descriptiva o prescriptiva.
descriptivo
estilo define una codificacin especial de elementos de diseo y los acuerdos formales.
El estilo descriptivo se utiliza durante las discusiones entre el cliente y el arquitecto.
Estilo prescriptivo limita los elementos de diseo y sus arreglos formales
Arquitectura de referencia corresponde a "la arquitectura como un estilo o mtodo." Se
refiere a un principio de diseo coherente utilizado en un dominio especfico=base=JEE.
La arquitectura deber indicar y justificar claramente cmo y en qu etapa de la
proceso de desarrollo, las restricciones externas y las decisiones de diseo de ingeniera
son introducido
Arquitectura de referencia flexible = PLANTILLA, terminologa unificada
Diseo y Principios de Arquitectura
La arquitectura es la estructura general de un sistema, y puede contener subsistemas que
interfaz con otros subsistemas. Arquitectura considera la escalabilidad, seguridad y
portabilidad del sistema. La aplicacin normalmente sigue la arquitectura. en
el nivel de arquitectura, todos los detalles de implementacin estn ocultos

la arquitectura del sistema es una descripcin abstracta de un sistema especfico.

indicando el funciones de los componentes del sistema, sus interacciones, y las
restricciones a la ayuda (re) desarrollar el sistema
La arquitectura de software es la estructura de alto nivel de un sistema de software.

DISEO VS ARQUITECTURA
La diferencia clave entre la arquitectura y el diseo de trminos est en el nivel de
detalles. Arquitectura funciona a un alto nivel de abstraccin con menos detalles. Diseo
opera a un bajo nivel de abstraccin, , los diseadores intervenir y proporcionan detalles
internos de cada componente
Los pasos tpicos en el desarrollo de software incluyen anlisis de necesidades o el
enunciado del problema, el anlisis orientado a objetos y anlisis arquitectnico, diseo
orientado a objetos y el diseo arquitectnico, y en ltima instancia, la creacin de
objetos.
El trmino abstraccin implica el uso de un smbolo para algo que se usa repetidamente
en un diseo; es un componente que esconde detalles y es una representacin clara.
utilizamos abstracciones cada da cuando hablamos de modelos informticos que utilizan
cajas con lneas conectndolos para representar los componentes que estamos tratando
de pegar juntos.
rea de la superficie Superficie es un trmino usado para describir la forma en que los
componentes interactan con uno al otro de una manera definida
lmites Los lmites son las reas en las que dos componentes interactan.

Fragilidad
La fragilidad es el grado en el que pequeos cambios tendrn un impacto en grandes porciones del
sistema.
Software tiende a ser difcil de manejar por muchas razones, pero la razn principal es la
fragilidad.
Software rompe antes de que se dobla; que exige la perfeccin en un universo que prefiere
las estadsticas. Esto a su vez conduce a la "herencia lock-in" y otras perversiones. la distancia
entre los equipos ideales arquitectos imaginan y los sistemas informticos del mundo real
sabemos y trabajar es lamentable y debe en gran parte a la fragilidad.
Capacidades, friccin, y Capas
Las capacidades son las cualidades funcionales del sistema, observable incluyendo escalabilidad,
manejabilidad, el rendimiento, la disponibilidad, la fiabilidad y la seguridad, que se definen

en trminos de contexto. Capacidades se discuten ms adelante en el captulo, en la seccin

"Las capacidades de una arquitectura".
La friccin se refiere a la cantidad de interaccin que ocurre entre dos componentes. friccin
se mide en trminos de cmo un cambio en un componente afecta a ambos componentes.
Capas es una jerarqua de separacin.
Principios de Arquitectura
Para los arquitectos de sistemas, todas las tcnicas de descomposicin (rotura de un objeto
grande en
partes ms pequeas de componentes) sistemas de software abordan dos preocupaciones
principales:
n mayora de los sistemas son demasiado complejos para comprender en su totalidad.
n Las diferentes audiencias requieren diferentes perspectivas de un sistema.
Los siguientes prrafos describen las tcnicas para descomponer una arquitectura
utilizando conceptos conocidos como capas y niveles.
Capas
Las capas de la arquitectura son los sistemas en s mismos, y que hacen lo que hacen todos los
sistemas:

niveles
En un entorno de varios niveles, el cliente implementa la lgica de presentacin (delgada
cliente). La lgica de negocio se implementa en un servidor de aplicaciones (s), y los datos
reside en un servidor (s) base de datos. As, las tres capas componentes siguientes definen
una arquitectura de varios niveles: Un componente front-end, que es responsable de
proporcionar porttil , la lgica de presentacin, tal como un servidor web ,Un componente de
back-end, que proporciona acceso a los servicios dedicados, tales como un servidor de base de
datos

Calidad del Sistema Definicin

Disponibilidad El grado en que un sistema es accesible. El plazo de 24 7 describe
total disponibilidad. Este aspecto de un sistema es a menudo junto con
rendimiento.
Fiabilidad La capacidad de garantizar la integridad y consistencia de una aplicacin
y de sus transacciones.
Manejabilidad La capacidad de administrar y de esta manera gestionar los recursos del sistema
para garantizar la disponibilidad y el rendimiento de un sistema con respecto
a las otras capacidades.
Flexibilidad La capacidad para hacer frente a la configuracin arquitectnica y hardware
cambios sin una gran cantidad de impacto en el sistema subyacente.
Rendimiento La capacidad para llevar a cabo funciones en un plazo de tiempo que se rene
objetivos especficos.
Capacidad La capacidad de un sistema para ejecutar varias tareas por unidad de tiempo.
Escalabilidad La capacidad para soportar la disponibilidad y el rendimiento requerido como
aumenta la carga transaccional.

Extensibilidad La capacidad de extender la funcionalidad.

Validez La capacidad de predecir y confirmar los resultados sobre la base de una entrada
especificada
o un gesto de usuario.
Reutilizacin La capacidad de utilizar un componente en ms de un contexto sin
el cambio de sus componentes internos.
Seguridad La capacidad de asegurar que la informacin no se accede y modificado
a no ser hecho de acuerdo con la poltica de la empresa.

AUTO TEST
Las siguientes preguntas le ayudarn a medir su comprensin del material presentado en este
captulo. Lea todas las opciones con cuidado porque puede haber ms de una respuesta correcta.
elegir
todas las respuestas correctas para cada pregunta.
Reconocer el efecto en cada una de las siguientes caractersticas de dos niveles,
De tres niveles y multi-tier Architectures: Escalabilidad mantenibilidad, fiabilidad,
Disponibilidad, extensibilidad, rendimiento, manejabilidad y seguridad.
1. Cul de los siguientes es cierto acerca de los requisitos de un sistema bancario?
A. La necesidad de seguridad es un ejemplo clsico de un requisito de nivel de servicio funcional, y
una regla de cuenta de cheques es un ejemplo de un requisito no funcional.
B. Seguridad y de la cuenta de cheques obligatoria tanto ilustran el nivel de servicio funcional
requisitos.
C. Ni la seguridad ni la cuenta de cheques obligatoria es un ejemplo de cualquier tipo de
requisito, hablando tericamente.
D. La seguridad es un requisito no funcional arquitectnico y la verificacin obligatoria
representa un requisito de diseo funcional.
E. Ambos son ejemplos de casos de uso del negocio.
2. Cul de los siguientes son los requisitos no funcionales?
A. La escalabilidad, disponibilidad, extensibilidad, manejabilidad y seguridad
B. Rendimiento, confiabilidad, elaboracin, de transicin, la documentacin, y la seguridad
C. Especificacin, elaboracin, construccin, transicin, casos de uso, y la seguridad
D. rendimiento, disponibilidad, escalabilidad y seguridad
E. La fiabilidad, disponibilidad, escalabilidad, capacidad de administracin y seguridad
3. Cul de los siguientes es el elemento ms importante que debe ser considerado en el diseo
de

una aplicacin?
A. Escalabilidad
B. Mantenibilidad
C. Confiabilidad
D. Reunin de las necesidades del cliente
E. Rendimiento
F. Asegurar la aplicacin se produce a tiempo y dentro del presupuesto
Dada una arquitectura descrita en trminos de diseo de red, una lista de beneficios
y Debilidades potenciales asociados a ella
4. Su han sido contactados por una empresa para ayudarles a mejorar el rendimiento de su
aplicacin de e-commerce. Usted ha sugerido que el hardware en el que la aplicacin es
Actualmente desplegados (dos servidores web y un servidor de base de datos) pueden migrar a
tres servidores web, un
servidor de aplicaciones y un servidor de base de datos (todo en mquinas diferentes). Les aseguro
que todo
las reescrituras de software necesarios valdr la pena en el largo plazo. Cules son las
caractersticas de
su arquitectura sugerida?
Clientes A. Grasa
B. clientes Thin
C. Buena separacin de la lgica de negocio
D. buena escalabilidad
E. La mala separacin de la lgica de negocio
F. La mala escalabilidad
G. No hay diferencia en la separacin de la lgica de negocio
RESPUESTAS DE LA PRUEBA DE AUTO
Reconocer el efecto en cada una de las siguientes caractersticas de dos niveles,

De tres niveles y multi-tier Architectures: Escalabilidad mantenibilidad, fiabilidad,

Disponibilidad, extensibilidad, rendimiento, manejabilidad y seguridad.
1. 3 D es correcta. Ofertas exitosas de arquitectura de software con abordar la no funcional
los requisitos de nivel de servicio de un sistema. El proceso de diseo se lleva todo negocio
funcional
requisitos en cuenta. La seguridad se considera un requisito no funcional y especfico
reglas de negocio, tales como el descrito para la cuenta de cheques, se consideran funcional
requisitos. La opcin D es la nica opcin que describe con precisin este.
A, B, C, y E no son ciertas. La opcin A es incorrecta porque la funcional y
requisitos no funcionales se conmutan. La opcin B es incorrecta porque slo uno de ellos
es un requisito funcional. La opcin C es incorrecta porque, como se acaba de describir, uno de
ellos es
un requisito funcional y el otro, un requisito no funcional. Finalmente, Seleccin E es
porque el anlisis de negocios incorrecta puede comenzar con los casos de uso.
2. 3 D es correcta. Los requisitos de nivel de servicio no funcionales son discutidos rendimiento
(I: El sistema debe responder dentro de los 5 segundos); disponibilidad (II: El sistema tiene que
tener
un tiempo de actividad del 99,9 por ciento); escalabilidad (III se aadirn 200.000 suscriptores
adicionales); y
de seguridad (IV: HTTPS se va a utilizar). Por lo tanto, la eleccin D es correcta.
A, B, C, y E son incorrectos. No hay ninguna mencin de extensibilidad (capacidad de agregar
fcilmente o
ampliar la funcionalidad) y capacidad de gestin (capacidad de monitorear la salud del sistema).
Por lo tanto,
opcin A es incorrecta. Especificacin, elaboracin, construccin, transicin, documentacin,
y casos de uso no son requisitos no funcionales de nivel de servicio. Por lo tanto, las opciones B y C
son
incorrecta. Mientras que la escalabilidad y la fiabilidad pueden estar relacionados (El sistema
realizar como fiable

cuando ms usuarios operan en l?), no hay ninguna mencin de fiabilidad en la pregunta. Por lo
tanto,
opcin E es incorrecta.
3. 3 D es correcta. La consideracin ms importante en el diseo de una aplicacin es que
satisface las necesidades del cliente.
A, B, C, E, y F son incorrectos. Asegurar la aplicacin se produce a tiempo y dentro
presupuesto es algo que se debe hacer, pero no es la preocupacin nmero uno. la aplicacin
no tiene que ser la mejor solucin posible bajo las circunstancias. Mientras se encuentra con el
las necesidades del cliente, se considera adecuada. Todas las dems consideraciones son
secundarias a
satisfaccin de las necesidades del cliente.
y Debilidades potenciales asociados a ella
4. 3 B, C, y D son correctas. El sistema que usted ha sugerido que migran a una de tres niveles
sistema. Las caractersticas de un sistema de tres niveles son los clientes ligeros, una buena
separacin de los negocios
la lgica y la buena escalabilidad. Esto es debido al hecho de que cada nivel es independiente de la
otra
(por ejemplo, sera posible cambiar el almacn de datos sin afectar a la lgica de negocio).
A, E, F y G son incorrectos. La opcin A es incorrecta; el sistema propuesto tiene clientes
ligeros,
la lgica de negocio que reside en el servidor de aplicaciones, en el nivel medio. Debido a que hay
una buena
separacin de la lgica de negocio, las opciones E y G son incorrectos. Opcin F es incorrecto, ya
que el threetier
naturaleza del sistema hace que sea muy escalable.

n arquitectura definida
n trminos arquitectnicos
n Arquitectura frente diseo
n Fundamentos de la arquitectura
n Capacidades de una arquitectura
objetivos n Diseo de la arquitectura
n Arquitectura niveles y capas
n Beneficios y debilidades de la arquitectura
n Protocolos: HTTP, HTTPS, IIOP