ENSAYO ARQUITECTURA DE SOFTWARE

Prez Tun Octavio Uriel, Lara Dzul Geidy Abigahil

Instituto Tecnolgico Superior Progreso
Progreso, Mxico
Octavio_pereztun@hotmail.com
GALD204@hotmail.com

Introduccin
El objetivo del presente ensayo es presentar la arquitectura
del software, como otros del hardware de proyecto tecnolgico.
El contenido consiste en la definicin de Arquitectura, las
consideraciones de lo mismo un, objetivos del sistema,
presentacin de los componentes de software, utilidad y futuras
actividades relacionadas con el desarrollo del software y las
etapas del proyecto.

1. Historia y Antecedentes
EDSGER DIJKSTRA, 1968 DE LA UNIVERSIDAD TECNOLGICA DE
EINDHOVEN EN HOLANDA Y PREMIO TURING 1972, PROPUSO QUE
SE ESTABLEZCA UNA ESTRUCTURACIN CORRECTA DE LOS SISTEMAS
DE SOFTWARE ANTES DE LANZARSE A PROGRAMAR, ESCRIBIENDO
CDIGO DE CUALQUIER MANERA [DIJ68A]. DIJKSTRA, QUIEN
SOSTENA QUE LAS CIENCIAS DE LA COMPUTACIN ERAN UNA RAMA
APLICADA DE LAS MATEMTICAS Y SUGERA SEGUIR PASOS
FORMALES PARA DESCOMPONER PROBLEMAS MAYORES, FUE UNO
DE LOS INTRODUCTORES DE LA NOCIN DE SISTEMAS OPERATIVOS
ORGANIZADOS EN CAPAS QUE SE COMUNICAN SLO CON LAS CAPAS
ADYACENTES Y QUE SE SUPERPONEN COMO CAPAS DE CEBOLLA.
INVENT O AYUD A PRECISAR ADEMS DOCENAS DE CONCEPTOS:
EL ALGORITMO DEL CAMINO MS CORTO, LOS STACKS, LOS
VECTORES, LOS SEMFOROS, LOS ABRAZOS
MORTALES. DE SUS ENSAYOS ARRANCA LA TRADICIN DE HACER
REFERENCIA A NIVELES DE ABSTRACCIN QUE HA SIDO TAN
COMN EN LA ARQUITECTURA SUBSIGUIENTE.

En la conferencia de la NATO de 1969, un ao despus de la

sesin en que se fundara la ingeniera de software, P. I. Sharp
formul estas sorprendentes apreciaciones comentando las
ideas de Dijkstra: Pienso que tenemos algo, aparte de la
ingeniera de software: algo de lo que hemos hablado muy poco
pero que deberamos poner sobre el tapete y concentrar la
atencin en ello. Es la cuestin de la arquitectura de software.
La arquitectura es diferente de la ingeniera. Como ejemplo de
lo que quiero decir, echemos una mirada a OS/360. Partes de
OS/360 estn extremadamente bien codificadas. Partes de OS,
si vamos al detalle, han utilizado tcnicas que hemos acordado
constituyen buena prctica de programacin.
La razn de que OS sea un amontonamiento amorfo de
programas es que no tuvo arquitecto. Su diseo fue delegado a
series de grupos de ingenieros, cada uno de los cuales invent
su propia arquitectura. Y cuando esos pedazos se clavaron
todos juntos no produjeron una tersa y bella pieza de software.
En 1971, C. R. Spooner titul uno de sus ensayos Una
arquitectura de software para los 70s [Spo71], sin que la

mayor parte de la historiografa de la AS registrara ese

antecedente. En 1975, Brooks, diseador del sistema operativo
OS/360 y Premio Turing 2000, utilizaba el concepto de
arquitectura del sistema para designar la especificacin
completa y detallada de la interfaz de usuario y consideraba
que el arquitecto es un agente del usuario, igual que lo es quien
disea su casa [Bro75], empleando una nomenclatura que ya
nadie aplica de ese modo.
En el mismo texto, identificaba y razonaba sobre las
estructuras de alto nivel y reconoca la importancia de las
decisiones tomadas a ese nivel de diseo. Tambin distingua
entre arquitectura e implementacin; mientras aquella deca
qu hacer, la implementacin se ocupa de cmo.
En 1972, Parnas public un ensayo en el que discuta la
forma en que la modularidad en el diseo de sistemas poda
mejorar la flexibilidad y el control conceptual del sistema,
acortando los tiempos de desarrollo [Par72]. Introdujo
entonces el concepto de ocultamiento de informacin
(information hiding), uno de los principios de diseo
fundamentales en diseo de software an en la actualidad. La
herencia de este concepto en la ingeniera y la arquitectura
ulterior es inmensa, y se confunde estrechamente con la idea de
abstraccin.
En la segunda de las descomposiciones que propone Parnas
comienza a utilizarse el ocultamiento de informacin como
criterio. Los mdulos ya no se corresponden con las etapas de
procesamiento? Cada mdulo en la segunda descomposicin se
caracteriza por su conocimiento de una decisin de diseo
oculta para todos los otros mdulos. Su interfaz o definicin se
escoge para que revele tan poco como sea posible sobre su
forma interna de trabajo.
Dewayne Perry, Alexander Wolf 1992 Foundations for the
study
of
software
architecture
La dcada de 1990, creemos, ser la dcada de la
arquitectura de software. Usamos el trmino arquitectura en
contraste con diseo, para evocar nociones de codificacin,
de abstraccin, de estndares, de entrenamiento formal (de los
arquitectos de software) y de estilo. Es tiempo de reexaminar el papel de la arquitectura de software en el contexto
ms amplio del proceso de software y de su administracin, as
como sealar las nuevas tcnicas que han sido adoptadas.

Presentacin
El contenido de la misma consiste de la definicin de
Arquitectura, consideraciones de la misma, objetivos del
sistema, presentacin de los componentes de software, utilidad
y futuras actividades relacionadas con el desarrollo de
software y las etapas del proyecto.

Disponibilidad: referente a la medida del tiempo en que

Que es una Arquitectura de Software
Considerando definiciones de distintos autores y especialistas
en el tema (Mary Shaw David Garlan Bass Clement
Kazman), se ha adoptado la siguiente, la cual define al sistema
de software en trminos de Componentes computacionales y las
interacciones entre los mismos.
El desarrollo de una arquitectura de software corresponde a
las etapas iniciales de una metodologa de desarrollo de
sistemas.

Implicaciones
El enfoque que brinda esta metodologa de desarrollo est
centrado en las funcionalidades que darn soporte a los
requerimientos de sistemas. Brinda una visin de cmo el
sistema funcionar en tiempo de ejecucin, la colaboracin
entre los distintos componentes, los flujos de informacin que
se llevarn a cabo con el objetivo de cumplir tareas especficas.
Facilita la definicin de un lenguaje comn entre los
participantes del proyecto, es una metodologa de
comunicacin para describir el sistema, sus caractersticas,
facilitando la interpretacin de los conceptos especficos.
Es fundamental dedicar el tiempo suficiente, en esta etapa, para
la toma de decisiones y definiciones que sern cruciales para
el alcanzar la misin del sistema.

Requerimientos de Calidad
Es muy importante, plantear las cualidades que el sistema
deber cumplir una vez desarrollado, las mismas deben ser
analizadas, definidas y consideradas desde el inicio del
desarrollo. Las que se han detectado como fundamentales para
la arquitectura del proyecto son las siguientes:

Performance: en esta etapa una decisin fundamental es

la divisin de las funcionalidades del sistema y su forma de
comunicacin. Se plantearn componentes con roles bien
definidos los cules interactuarn con otros para alcanzar un
objetivo en comn. En futuras etapas se tendrn en cuenta
medida de tiempos de respuestas deseados, flexibilidad del
software y el hardware para alcanzar los niveles de
performance deseados.

Modificabilidad:

se refiere al desarrollo de software

flexible para adecuarse a cambios para extender, cambiar o
eliminar funcionalidades del sistema, sin necesidad de volver a
escribir los programas y provocando la menor alteracin al
sistema en su totalidad.

el sistema estar operativos y ejecutndose correctamente. Es

muy importante identificar componentes crticos, los cules
necesitaran redundancia, monitoreo de fallas,

capacidades de recuperacin.
Integrabilidad:

como se ver ms adelante, la

caracterstica del sistema a desarrollar es que deber integrar
sistemas que trabajan de manera independiente, por lo tanto
deber considerarse, inter fases y modos de comunicacin que
permitan la colaboracin en conjunto

Componentes de Software
El lenguaje clsico de presentacin de una arquitectura es a
travs de diagramas, con diferentes simbologas que
representan componentes de software.
Los principales componentes del sistema son:

Sistema de Informacin Geogrfica

Modelos de Simulacin de crecimiento vegetal
Sistema de Publicacin
Base de datos geogrfica

Cada uno tiene una funcionalidad muy bien definida, son

sistemas autnomos pero el desafo es integrarlos en una nica
aplicacin. Al ser sistemas autnomos la interaccin y el flujo
de informacin no es directa, se deben desarrollar inter fases
para posibilitar el intercambio de informacin.
A continuacin se mostrar cmo cada uno de estos
componentes en forma ms detallada, conformando
subsistemas y cmo es la comunicacin entre estos.

Componentes del Software- tipos de

informacin
El componente principal de la arquitectura es la base de datos
geogrfica, la cual manejara dos grandes tipos de informacin:

1.Informacin Meteorolgica y Agronmica

2.Cartografa de Base
El primer grupo tiene la responsabilidad de manejar series
histricas de 20 aos de temperatura (Max, min), radiacin
solar, precipitaciones, direccin y velocidad del viento, entre
otros. Est informacin se encuentra disponible a partir de
distintas fuentes, formatos y medios. Por lo tanto es necesario
desarrollar estndares de almacenamiento, como as tambin
procesos automticos que se encarguen del control y
conversin de los mismos para su posterior almacenamiento en
la base de datos geogrfica. Cmo as tambin interfaces que
permitan la carga de los mismos para los datos que se
encuentren en medios analgicos.

El segundo grupo corresponde a toda la informacin grfica

que conformar la cartografa de base, la que manejar el
sistema de informacin geogrfica. En este grupo estar
formado por todos los trabajos de teledeteccin que se
realizarn en el proyecto, capas grficas que han sido cedidas
y digitalizacin de cartas topogrfica. De la misma manera, se
necesitan procesos de control estandarizacin y un sistema de
procesamiento de imgenes que soporte las actividades de
Teledeteccin y los resultados que se generen sern
almacenados en la base de datos geogrfica.

Modelos de Simulacin de crecimiento

vegetal
Este componente abre el sistema a la comunidad, la estructura
responde a un sistema de publicacin, al cual se podr acceder
a travs de Internet, por medio de un navegador. En el mismo
se pondr a disposicin la informacin de tipo ambiental que
se genere en el centro, estadsticas, avances del proyecto,
metodologas, etc. Con el objetivo de ayudar a adoptar
polticas ambientales que fomenten el desarrollo sustentable.

Utilidad
Este enfoque metodolgico es muy til ya que permite enfocar
el desarrollo del software sobre las funcionalidades bsicas y
la cooperacin a partir de componentes. A partir de estos se
deber ir especificando detalles hasta llegar a la
implementacin fsica de los mismos. Brinda una divisin bien
clara entre los que son aplicaciones y los datos.
La divisin de funcionalidades facilita la modificabilidad y
extensin del sistema. Se enfatizan los atributos de calidad
desde la etapa inicial de desarrollo, que no todas las
metodologa los consideran.

negocio y por otro lado una actualizacin tecnolgica

para gran parte de sus aplicativos.

Necesidad
El cliente necesita implementar una estrategia de TI
que facilite y agilice la implementacin de nuevos
procesos de negocio, modificaciones a los actuales,
interaccin con sistemas legaca e integracin con
sistemas de otras compaas del grupo asegurador
(Seguros Generali) desarrollados en una plataforma
diferente (Microsoft).

Solucin
Para dar respuesta a este importante desafo se
propuso basar la estrategia de desarrollo en una
arquitectura orientada a servicios (SOA).
La arquitectura orientada a servicios es tanto un
marco de trabajo para el desarrollo de software como
un marco de trabajo de implantacin.
Ha sido clave para el xito de este proyecto, la
orientacin del proyecto hacia una arquitectura de
servicios desde sus inicios, en trminos de
planificacin y diseo para garantizar la consistencia
del trabajo a realizar a lo largo de todo el proyecto.
Los beneficios obtenidos bajo esta arquitectura son:
o

Proyecto SOA

o
o

Cliente
La Caja de Ahorro y Seguro SA, compaa lder en la
comercializacin de seguros de la Repblica Argentina,
abarcando los seguros del segmento Vida, Laboral, Generales
y Automotor.

Objetivo
El objetivo general de este proyecto fue proponer al
cliente una solucin arquitectnica para dar un
sustento consistente a las necesidades de su negocio,
que presentaban por un lado, un problema de agilidad
y adaptabilidad a las cambiantes necesidades del

Mejora en los tiempos de realizacin de

cambios en procesos.
Facilidad para evolucionar a modelos de
negocios basados en tercerizacin.
Facilidad para abordar modelos de negocios
basados en colaboracin con otros entes
(socios, proveedores).
Poder para reemplazar elementos de la capa
aplicativa SOA sin disrupcin en el proceso
de negocio.

SOA proporciona una metodologa y un marco de

trabajo para documentar las capacidades de negocio
y puede dar soporte a las actividades de integracin y
consolidacin.
En un ambiente SOA, los nodos de la red hacen
disponibles sus recursos a otros participantes en la
red como servicios independientes a los que tienen
acceso de un modo estandarizado.

Modalidad de Servicio

La modalidad de servicio que se aplic en este

proyecto fue Clula de Trabajo, conformando un
equipo de trabajo multidisciplinario de nueve
recursos.

pasando por los Casos de Uso de

Especificacin, los Componentes hasta las
piezas de software que lo implementan.
Bugzilla: utilizamos esta herramienta de uso
libre en lo referente a tracking de defectos.

La duracin del contrato es de dos aos.

Tecnologa

Octavio Perez Tun

Geidy Lara Dzu

Para

el proyecto se utilizaron las siguientes

tecnologas:
o
o
o
o
o
o
o
o

Java J2EE
Struts
Webwork
Ibatis
Websphere
Tomcat
Apache
Oracle

Recursos HumanosWinCVS: la utilizamos

en lo relativo al rea de proceso mencionada, lo que
nos permite realizar de manera consistente y segura
toda la administracin de los componentes de un
El proyecto fue llevado adelante por un equipo
interdisciplinario integrado por profesionales que
cubran los siguientes roles
o
o
o
o
o
o
o
o

Gerente de Proyecto
Analistas Funcionales
Arquitectos
Analistas Tcnicos
Programadores
Analista Funcional Tester
Testeadores
Especialista SCM

REFERENCIAS
[1] L. Bass, P. Clements, and R. Kazman, Chapter 1
The architecture Business Cycle Software
Architecture in Practice, Second Edition, pp3.
Addison-Wesley.
[2] P. Abrahamsson, M. A. Babar, and P. Kruchten,
Agility and architecture: Can they coexist?, IEEE
Software, vol. 27, pp. 1622, 2010.
[3] J. Canos, P. Letelier, and C. Penad es,
Metodolog as Agiles en el desarrollo de
software, 2003. Universidad Politecnica de
Valencia.
[4] K. Schwaber, Agile Project Management With
Scrum. Redmond, WA, USA: Microsoft Press, 2004.
[5] K. Beck, Extreme Programming Explained:
Embrace Change. Addison-Wesley Professional, first
ed., 1999.
[6] A. Cockburn, Agile software development. Boston,
MA, USA: Addison-Wesley Longman Publishing Co.,
Inc., 2002.

Recursos Tcnicos

[7]http://carlosreynoso.com.ar/archivos/arquitectura
/Arquitectura-software.pdf

Los recursos tcnicos utilizados en el proyecto fueron

los siguientes:

[8]http://arquitsoft.blogspot.mx/

Microsoft Project Server: De vital

importancia para poder realizar un
seguimiento de manera real y poder prevenir
desvos en forma temprana.
Enterprise Architect: Utilizamos una
reconocida herramienta de mercado como
Enterprise Architect la cual nos permite
administrar la totalidad del ciclo de
desarrollo de un proyecto permitindonos
realizar una trazabilidad de manera
completa desde los Casos de Uso de
Requerimientos,

[9]www.academica.mx/sites/default/files/adjuntos/53
512/Ensayo.docx
[10]http://www.huenei.com/es/clientes/casos-deexito/proyecto-soa/