Arquitectura del software.

La arquitectura de software es un conjunto de patrones que proporcionan un

marco de referencia necesario para guiar la construccin de un software,
permitiendo a los programadores, analistas y todo el conjunto de
desarrolladores del software compartir una misma lnea de trabajo y cubrir
todos los objetivos y restricciones de la aplicacin. Es considerada el nivel
ms alto en el diseo de la arquitectura de un sistema puesto que
establecen la estructura, funcionamiento e interaccin entre las partes del
software.
La Arquitectura del Software es el diseo de ms alto nivel de la estructura
de un sistema.
Una Arquitectura de Software, tambin denominada Arquitectura lgica,
consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan un marco definido y claro para interactuar con el cdigo fuente
del software.
Una arquitectura de software se selecciona y disea con base en objetivos
(requerimientos) y restricciones. Los objetivos son aquellos prefijados para
el sistema de informacin, pero no solamente los de tipo funcional, tambin
otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e
interaccin con otros sistemas de informacin. Las restricciones son
aquellas limitaciones derivadas de las tecnologas disponibles para
implementar sistemas de informacin. Unas arquitecturas son ms
recomendables de implementar con ciertas tecnologas mientras que otras
tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no
es viable emplear una arquitectura de software de tres capas para
implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los componentes
que llevan a cabo alguna tarea de computacin, sus interfaces y la
comunicacin entre ellos. Toda arquitectura debe ser implementable en una
arquitectura fsica, que consiste simplemente en determinar qu
computadora tendr asignada cada tarea.
La arquitectura de software, tiene que ver con el diseo y la implementacin
de estructuras de software de alto nivel. Es el resultado de ensamblar un
cierto nmero de elementos arquitectnicos de forma adecuada para
satisfacer la mayor funcionalidad y requerimientos de desempeo de un
sistema, as como requerimientos no funcionales, como la confiabilidad.

Importancia.
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 desempeo, 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.
Los atributos de calidad son parte de los requerimientos (no funcionales) del
sistema y son caractersticas que deben expresarse de forma cuantitativa.
No tiene sentido, por ejemplo, decir que el sistema debe devolver una
peticin de manera rpida, o presentar una pgina ligera, ya que no es
posible evaluar objetivamente si el sistema cubre o no esos requerimientos.
La manera en que se estructura un sistema permitir o impedir que se
satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de
tal manera que una peticin deba transitar por muchos componentes antes
de que se devuelva una respuesta podra tener un desempeo pobre. Por
otro lado, un sistema estructurado de tal manera que los componentes
estn altamente acoplados entre ellos limitar severamente la
modificabilidad. Curiosamente, la estructuracin tiene un impacto mucho
menor respecto a los requerimientos funcionales del sistema. Por ejemplo,
un sistema difcil de modificar puede satisfacer plenamente los
requerimientos funcionales que se le imponen.
Adems de los atributos de calidad, la arquitectura de software juega un
papel fundamental para guiar el desarrollo. Una de las mltiples estructuras
que la componen se enfoca en partir el sistema en componentes que sern
desarrollados por individuos o grupos de individuos. La identificacin de esta
estructura de asignacin de trabajo es esencial para apoyar las tareas de
planeacin del proyecto.
Finalmente, los diseos arquitectnicos que se crean en una organizacin
pueden ser reutilizados para crear sistemas distintos. Esto permite reducir
costos y aumentar la calidad, sobre todo si dichos diseos han resultado
previamente en sistemas exitosos.

Elementos
La arquitectura de software se compone por:

clientes y servidores.
bases de datos.
filtros.
niveles en sistemas jerrquico.

Niveles
Nivel 1

A menudo suele recibir instrucciones detalladas de que debe hacer, puede

escribir parte del cdigo de un software o realizarlo completo.
Un junior es normalmente un desarrollador inicial, alguien que empieza a
dar sus primeros pasos en el ambiente de la creacin de aplicaciones o que
recin sale de la universidad sin experiencia laboral previa. El Junior es
frecuentemente puesto como pasante y por esto sus funciones suelen verse
limitadas.
A menudo un Junior no suele interactuar con los clientes o futuros usuarios
de la aplicacin. Suele dejarse manejar por la presin y por esto no se
delega en el labores de vigilancia de aplicaciones en produccin ni
proyectos con premura o corto deadline.
El periodo en el que se considera Junior puede estar hasta los 2, 3 y 4 aos
(depender en algunos casos de la empresa) de vida laboral en el rea.
Algunas empresas suelen usar como modo de adaptacin y evaluacin,
poner a los desarrolladores Junior a trabajar en pequeas aplicaciones para
medir su desenvolvimiento.

Nivel 2
Normalmente recibe una lista de requerimientos para un proyecto en el cual
puede que trabaje solo o tenga algn (os) Juniors de asistent(s). Se toma la
libertad de adecuar los requerimientos y genera un project plan segmentado
en fases.
El Senior no necesita instrucciones en todos los detalles como los Junior,
suele ingenirsela para investigar detalles puntuales que quizs no fueron
especificados en los requerimientos.
No es necesario tenerle tanta vigilancia en el cumplimiento de sus metas.
En cierta medida la mayor diferencia entre un desarrollador senior y un
junior radica en su autonoma en la ejecucin de sus funciones y pese a su
experiencia laboral el senior suele manejar mejor la presin.
Un senior experimentado suele ser a partir de los 4 aos. Algunas personas
y empresas consideran el espacio entre los 2 y 4 aos de experiencia como
Mid Senior (semi-senior) pues no se considera que sus capacidades sean
completamente ptimas.

Nivel 3
El analista en muchos casos suele ser el puente entre los desarrolladores y
el cliente; en muchos de los casos cumple la funcin de team leader o
project manager.

El analista a menudo tiene una clara idea de que puede o no hacer su

equipo y cuales son sus lmites. Es la persona que se sienta con el cliente,
revisa sus ideas para convertirlas en requerimientos y las lleva a
alternativas viables. Administra recursos y tiempo dentro de su equipo para
cumplir con las fechas acordadas.
Siendo justo y llevando esta descripcin al plano laboral, pudiera decirse
que un analista no necesariamente es un desarrollador pues en algunos
casos es una persona que conoce las funciones de los desarrolladores,
tienes nociones de las herramientas pero no desarrolla.

Nivel 4
Este nivel tiene lo mejor de los dos mundos, pues un Analista Desarrollador
suele ser un Senior con las cualidades y capacidades del analista antes
mencionado.
En este nivel se suele tener una idea ms aterrizada de cada requerimiento
y el plan de accin suele ser ms acabado y preciso en la prctica pues
tambin desarrollar es parte de su da a da.
Un Analista Desarrollador sabe que herramientas son mejores para cada
tarea y por ende sus resultados suelen ser mejores o sus resultados ms
exactos que los de los Analistas.
Existe un segmento Analista Desarrollador Senior que suele diferenciarse
de los anteriores por sus altas capacidades o mejor dominio de la
implementacin de sus aplicaciones.

Nivel 5
Los Arquitectos de Software son quienes determinan las reglas de negocio al
momento de implementar una nueva solucin, no solo se limitan a mirar en
el entorno de desarrollo las herramientas y tecnologas a utilizar sino que
evalan y proponen upgrade a nuevo hardware para los sistemas que van a
crear.
Fuera de lo que puedan pensar los Junior y Senior, para los Arquitectos de
Software la creacin de aplicaciones es un arte.
Cuando un Junior piensa en la palabra Arquitecto imagina un individuo con
grandes maquetas en la cual est impregnada la concepcin de su
infraestructura, esto mismo hacen los Arquitectos de Software aplicado al
desarrollo de soluciones.

El trabajo y responsabilidad de los Arquitectos de Software es ms grande

en cierta medida pues deben hacer las predicciones de cuanto hardware es
necesario para correr la nueva aplicacin que crearn en base a mediciones
de carga o pruebas de stress.
La Arquitectura de Software, tiene que ver con el diseo y la
implementacin de estructuras del software, desempeo del sistema, la
escalabilidad y portabilidad de forma adecuada para satisfacer las
necesidades del negocio.

Nivel 6
Un inventor es un ente completamente independiente de toda tarea
recurrente y cuya misin es crear nuevas implementaciones, API o
innovaciones tecnolgicas no existentes en el mercado.
El inventor debe ser alguien con visin y amplios conocimientos en un
lenguaje o tecnologa y con la capacidad de concebir una idea
completamente original y que pueda revolucionar o brindar una solucin al
mercado de software.
Este nivel no es muy abundante en el mercado comn y suele requerir una
gran cantidad de aos de experiencia obtener este ttulo.

Tipos de arquitecturas
Para utilizar la arquitectura de software se sigue un conjunto de patrones
arquitectnicos, entre los cuales podemos encontrar:

Cliente-Servidor
Blackboard.
Modelo entre capas.
Intrprete.
Orientado a servicios.

Modelos de la arquitectura de software

Modelos estructurales
Son similares a la vista estructural, pero su nfasis primario radica en la
(usualmente una sola) estructura coherente del sistema completo, en vez
de concentrarse en su composicin. Los modelos de framework a menudo
se refieren a dominios o clases de problemas especficos. El trabajo que
ejemplifica esta variante incluye arquitecturas de software especficas de
dominios, como CORBA, o modelos basados en CORBA, o repositorios de
componentes especficos, como PRISM.

Modelos dinmicos
Enfatizan la cualidad conductual de los sistemas ,Dinmico puede referirse
a los cambios en la configuracin del sistema, o a la dinmica involucrada
en el progreso de la computacin, tales como valores cambiantes de datos.

Modelos de proceso
Se concentran en la construccin de la arquitectura, y en los pasos o
procesos involucrados en esa construccin. En esta perspectiva, la
arquitectura es el resultado de seguir un argumento (script) de proceso.
Esta vista se ejemplifica con el actual trabajo sobre programacin de
procesos para derivar arquitecturas.