La relación entre la arquitectura de software y el

diseño basado en componentes de software

Germán Ernesto Ochoa-Manríquez
gochoa@uabcs.mx – DASC
Universidad Autónoma de BCS
La Paz, BCS, México

Abstract— This document tries to relate the software arquitectura omite específicamente cierta información sobre
architecture and the component-based design through the analysis elementos que no es útil para razonar sobre el sistema en
of the architecture as an abstraction, as well as the design patterns particular, omite información que no tiene ramificaciones fuera
for decision-making. (Abstract) de un solo elemento. Por tanto, una arquitectura es ante todo una
abstracción de un sistema que selecciona ciertos detalles y
I. INTRODUCCIÓN suprime otros. En todos los sistemas modernos, los elementos
interactúan entre sí mediante interfaces que dividen los detalles
La arquitectura de software es importante para el desarrollo
de un elemento en partes públicas y privadas. La arquitectura se
exitoso de un sistema de software, poderlo plasmar a través de
preocupa por el lado público de esta división; Los detalles
un libro o documento, pues lo hace relevante para el que lo
privados de los elementos Los detalles que tienen que ver
consume, ya que le da la posibilidad de que se puede aplicar de
únicamente con la implementación interna no son
manera hágalo usted mismo. Los sistemas de software se
arquitectónicos. Sin embargo, más allá de las interfaces, la
construyen para satisfacer los objetivos comerciales de las
abstracción arquitectónica nos permite ver el sistema en
organizaciones. La arquitectura es un puente entre esos (a
términos de sus elementos, cómo están organizados, cómo
menudo abstractos) objetivos comerciales y el sistema final
interactúan, cómo están compuestos, cuáles son sus propiedades
(concreto) resultante. Si bien el camino desde los objetivos
que apoyan el razonamiento de nuestro sistema, etc. Esta
abstractos hasta los sistemas concretos puede ser complejo, la
abstracción es esencial para domar la complejidad de un sistema
buena noticia es que las arquitecturas de software se pueden
que simplemente no podemos, y no queremos, lidiar con toda la
diseñar, analizar, documentar e implementar utilizando técnicas
complejidad todo el tiempo.
conocidas que respaldarán el logro de estos objetivos
comerciales y de misión. La complejidad puede ser III. LA ARQUITECTURA INCLUYE EL COMPORTAMIENTO
domesticada, manejable. La arquitectura de software de un
El comportamiento de cada elemento es parte de la
sistema es el conjunto de estructuras necesarias para razonar
arquitectura en la medida en que ese comportamiento se puede
sobre el sistema, que comprende elementos de software,
utilizar para razonar sobre el sistema. Este comportamiento
relaciones entre ellos y propiedades de ambos. Esta definición
encarna cómo los elementos interactúan entre sí, lo cual es
contrasta con otras definiciones que hablan de las decisiones de
claramente parte de nuestra definición de arquitectura. Esto nos
diseño "tempranas" o "principales" del sistema. Si bien es cierto
dice que los dibujos de caja y línea que se hacen pasar por
que muchas decisiones arquitectónicas se toman temprano, no
arquitecturas, de hecho, no son arquitecturas en absoluto. Al
todas lo son: especialmente en proyectos ágiles o de desarrollo
mirar los nombres de las cajas (base de datos, interfaz gráfica de
en espiral. También es cierto que se toman muchas decisiones
usuario, ejecutivo, etc.), un lector puede imaginarse la
anticipadas que no son arquitectónicas. Además, es difícil
funcionalidad y el comportamiento de los elementos
analizar una decisión y saber si es "importante" o no. A veces,
correspondientes. Esta imagen mental se acerca a una
solo el tiempo lo dirá. Y dado que escribir una arquitectura es
arquitectura, pero surge de la imaginación de la mente del
una de las obligaciones más importantes del arquitecto,
observador y se basa en información que no está presente. Esto
necesitamos saber ahora qué decisiones comprende una
no significa que el comportamiento y el rendimiento exactos de
arquitectura. Las estructuras, por otro lado, son bastante fáciles
cada elemento deban documentarse en todas las circunstancias,
de identificar en el software y forman una herramienta poderosa
algunos aspectos del comportamiento son detallados y están por
para el diseño de sistemas.
debajo del nivel de preocupación del arquitecto. Pero en la
II. LA ARQUITECTURA ES UNA ABSTRACCIÓN medida en que el comportamiento de un elemento influya en otro
elemento o influya en la aceptabilidad del sistema en su
conjunto, este comportamiento debe considerarse y
Debido a que la arquitectura consta de estructuras y las
documentarse como parte de la arquitectura del software.
estructuras constan de elementos y relaciones, se deduce que una
arquitectura comprende elementos de software y cómo los
elementos se relacionan entre sí. Esto significa que la
 IV. ARQUITECTURAS DE SISTEMAS Y EMPRESAS
Dos disciplinas relacionadas con la arquitectura de software
son la arquitectura de sistemas y la arquitectura empresarial.
Ambas disciplinas tienen preocupaciones más amplias que el
software y afectan la arquitectura del software mediante el
establecimiento de restricciones dentro de las cuales debe vivir
un sistema de software. En ambos casos, el arquitecto de
software de un sistema debe estar en el equipo que proporciona
información sobre las decisiones que se toman sobre el sistema
o la empresa.
IV.1. ARQUITECTURA DEL SISTEMA
La arquitectura de un sistema es una representación de un
sistema en el que hay un mapeo de funcionalidad en
componentes de hardware y software, un mapeo de la
arquitectura de software en la arquitectura de hardware y una
preocupación por la interacción humana con estos componentes.
Es decir, la arquitectura del sistema se ocupa de un sistema total,
incluidos el hardware, el software y los seres humanos. Una
arquitectura de sistema determinará, por ejemplo, la
funcionalidad que se asigna a los diferentes procesadores y el
tipo de red que conecta esos procesadores. La arquitectura de
software de cada uno de esos procesadores determinará cómo se
implementa esta funcionalidad y cómo interactúan los distintos
procesadores a través del intercambio de mensajes en la red. Una
descripción de la arquitectura del software, ya que se asigna a
los componentes de hardware y de red, permite razonar sobre
cualidades como el rendimiento y la confiabilidad. Una
descripción de la arquitectura del sistema permitirá razonar
sobre cualidades adicionales como el consumo de energía, el
peso y el espacio físico. Cuando se diseña un sistema en
particular, con frecuencia existe una negociación entre el
arquitecto del sistema y el arquitecto del software en cuanto a la
distribución de la funcionalidad y, en consecuencia, las
restricciones impuestas a la arquitectura del software.
IV.2 ARQUITECTURA EMPRESARIAL
La arquitectura empresarial es una descripción de la
estructura y el comportamiento de los procesos, el flujo de
información, el personal y las subunidades organizativas de una
organización, alineados con los objetivos centrales y la dirección
estratégica de la organización. Una arquitectura empresarial no
necesita incluir sistemas de información claramente, las
organizaciones tenían arquitecturas que se ajustaban a la
definición anterior antes de la llegada de las computadoras, pero
en estos días, las arquitecturas empresariales para todas las
empresas, excepto las más pequeñas, son impensables sin el
soporte del sistema de información. Por lo tanto, una
arquitectura empresarial moderna se ocupa de cómo los sistemas
de software de una empresa respaldan los procesos y objetivos
comerciales de la empresa. Por lo general, en este conjunto de
preocupaciones se incluye un proceso para decidir qué sistemas
con qué funcionalidad debe respaldar una empresa. Una
arquitectura empresarial especificará el modelo de datos que
utilizan varios sistemas para interactuar, por ejemplo.
Especificará reglas sobre cómo los sistemas de la empresa
interactúan con los sistemas externos. El software es solo una
preocupación de la arquitectura empresarial. Otras dos
preocupaciones comunes abordadas por la arquitectura
empresarial son cómo los humanos utilizan el software para
realizar procesos comerciales y los estándares que determinan el
entorno computacional.
A veces, la infraestructura de software que soporta la
comunicación entre sistemas y con el mundo externo se
considera una parte de la arquitectura empresarial; otras veces,
esta infraestructura se considera uno de los sistemas dentro de
una empresa. (¡En cualquier caso, la arquitectura de esa
infraestructura es una arquitectura de software!) Estas dos
visiones resultarán en diferentes estructuras de gestión y esferas
de influencia para las personas interesadas en la infraestructura.
El sistema y la empresa proporcionan entornos y
limitaciones para la arquitectura del software. La arquitectura
del software debe vivir dentro del sistema y la empresa, y cada
vez más es el foco para lograr los objetivos comerciales de la
organización. Pero las tres formas de arquitectura comparten
importantes puntos en común: se preocupan por los elementos
principales tomados como abstracciones, las relaciones entre los
elementos y cómo los elementos juntos cumplen con los
objetivos de comportamiento y calidad de la cosa que se está
construyendo.
V. ¿QUÉ ES UN PATRÓN DE DISEÑO?
Un patrón de diseño es una mejor práctica documentada o el
núcleo de una solución que se ha aplicado con éxito en múltiples
entornos para resolver un problema que se repite en un conjunto
específico de situaciones. El arquitecto Christopher Alexander
describe un patrón como "una solución recurrente a un problema
común en un contexto y sistema de fuerzas determinados". En
su definición, el término contexto se refiere al conjunto de
condiciones / situaciones en las que un patrón dado es aplicable
y el término sistema de fuerzas se refiere al conjunto de
restricciones que ocurren en el contexto específico.
Un patrón de diseño es un medio eficaz para transmitir /
comunicar lo que se ha aprendido sobre diseños de alta calidad.
El resultado es: - Un lenguaje compartido para comunicar la
experiencia adquirida en el tratamiento de estos problemas
recurrentes y sus soluciones. - Un vocabulario común de
elementos de diseño de sistemas para discusiones de resolución
de problemas. Un medio de reutilizar y construir sobre la
información adquirida que resulta en una mejora en la calidad
del software en términos de su capacidad de mantenimiento y
reutilización. Un patrón de diseño no es una invención. Un
patrón de diseño es más bien una expresión documentada de la
mejor manera de resolver un problema que se observa o
descubre durante el estudio o la construcción de numerosos
sistemas de software. Uno de los conceptos erróneos más
comunes sobre los patrones de diseño es que se aplican solo en
un entorno orientado a objetos. Aunque las discusiones sobre
patrones de diseño normalmente se refieren al desarrollo
orientado a objetos, también son aplicables en otras áreas. Con
solo cambios menores, la descripción de un patrón de diseño se
puede ajustar para hacer referencia a los patrones de diseño de
software en general. En la sección anterior, Origen e historia, se o de los detalles de
puede ver que los patrones han existido desde los primeros días implementación.
de la arquitectura, mucho antes de la era de la programación y el Los patrones son de Los marcos proporcionan
diseño orientado a objetos. naturaleza más genérica y funcionalidad específica de
Los patrones de diseño no son construcciones teóricas. Un se pueden utilizar en casi dominio.
patrón de diseño puede verse como una encapsulación de una cualquier tipo de
solución reutilizable que se ha aplicado con éxito para resolver aplicación.
un problema de diseño común. Un patrón de diseño no Los marcos no son
Aunque los patrones de diseño se refieren a las formas más existe en forma de aplicaciones completas por sí
conocidas de resolver problemas, no todas las mejores prácticas componente de software solas. Se pueden construir
en la resolución de problemas se consideran patrones. Una mejor por sí solo. Debe aplicaciones completas
práctica debe cumplir la Regla de tres para ser tratada como un implementarse heredando los componentes
patrón de diseño. La Regla de Tres establece que se debe explícitamente cada vez const directamente.
verificar que una solución dada es un fenómeno recurrente, que se utiliza.
preferiblemente en al menos tres sistemas existentes. De lo Los patrones proporcionan Los patrones de diseño
contrario, la solución no se considera un patrón. El objetivo es una forma de hacer un pueden usarse en el diseño e
asegurar que alguna comunidad de profesionales de software diseño "bueno" y se implementación de un
aplique la solución descrita por el patrón para resolver utilizan para ayudar a marco. En otras palabras, los
problemas de diseño de software. Satisfacer la regla de tres diseñar marcos. marcos suelen incorporar
indica que un patrón de diseño proporciona una solución varios patrones de diseño.
práctica para hacer frente a un problema del mundo real.
Los patrones de diseño no brindan soluciones a todos los
problemas que se encuentran en el diseño y desarrollo de VI. ARQUITECTURA EN EL CONTEXTO DEL CICLO DE VIDA DE
software del mundo real. Los patrones de diseño tratan de UN PROYECTO
proporcionar soluciones elegantes y reutilizables a problemas de Los procesos de desarrollo de software son enfoques
desarrollo de software que se encuentran comúnmente en un estándar para desarrollar sistemas de software. Imponen una
contexto particular. Esto significa que un patrón destinado a disciplina a los ingenieros de software y, lo que es más
proporcionar la mejor solución a un problema en un contexto importante, a los equipos de ingenieros de software. Les dicen a
particular puede no producir una solución eficaz al mismo los miembros del equipo qué hacer a continuación. Hay cuatro
problema en un contexto diferente. A veces, la solución procesos de desarrollo de software dominantes, que describimos
propuesta por el patrón de diseño puede que ni siquiera sea aproximadamente en el orden en que llegaron a la prominencia:
aplicable en un contexto diferente. Los marcos de software se 1. Cascada. Durante muchos años, el modelo Waterfall
pueden confundir con patrones de diseño. Están estrechamente dominó el campo del desarrollo de software.
relacionados. La tabla 1.1 enumera las similitudes y diferencias El modelo Waterfall organizó el ciclo de vida en una serie de
entre los dos. actividades secuenciales conectadas, cada una con condiciones
Patrones de Diseño Marcos de trabajo de entrada y salida y una relación formalizada con sus vecinos
Los patrones de diseño son Un marco es un grupo de aguas arriba y aguas abajo. El proceso comenzó con la
soluciones recurrentes a componentes que cooperan especificación de requisitos, seguido del diseño, luego la
problemas que surgen entre sí para proporcionar implementación, luego la integración, luego las pruebas, luego
durante la vida de una una arquitectura reutilizable la instalación, todo seguido por el mantenimiento. Las rutas de
aplicación de software en para aplicaciones con un retroalimentación de los pasos posteriores a los anteriores
un contexto particular. dominio determinado. permitieron la revisión de los artefactos (documentos de
El objetivo principal es: El objetivo principal es: requisitos, documentos de diseño, etc.) según fuera necesario, en
• Ayudar a mejorar la • Ayudar a mejorar la calidad función del conocimiento adquirido en la etapa posterior. Por
calidad del software en del software en términos del ejemplo, los diseñadores podrían rechazar requisitos demasiado
términos de que el software software. ser reutilizable, estrictos, que luego se volverían a trabajar y fluirían hacia abajo.
sea reutilizable, mantenible, extensible, etc. Probar que los defectos descubiertos desencadenarían la
mantenible, extensible, etc. Reducir el tiempo de reimplementación (y tal vez incluso el rediseño). Y luego el
Reducir el tiempo de desarrollo ciclo continuó.
desarrollo 2. Iterativo. Con el tiempo, las rutas de retroalimentación del
Los patrones son de Los marcos son de naturaleza modelo Waterfall se volvieron tan pronunciadas que quedó claro
naturaleza lógica. más física, ya que existen en que era mejor pensar en el desarrollo de software como una serie
forma de software. de ciclos cortos a través de los pasos que algunos requisitos
Las descripciones de Debido a que los marcos conducen a algún diseño, que se puede implementar y probar
patrones suelen ser existen en forma de software, mientras el siguiente Se están capturando y diseñando el valor
independientes del son específico de la de los requisitos del ciclo. Estos ciclos se denominan iteraciones,
lenguaje de programación implementación. en el sentido de iterar hacia la solución de software definitiva
para el problema dado. Cada iteración debería ofrecer algo que
funcione y sea útil. El truco aquí es descubrir temprano aquellos
requisitos que tienen el efecto de mayor alcance en el diseño; el
peligro correspondiente es pasar por alto requisitos que, cuando
se descubran más tarde, harán que las decisiones de diseño
tomadas hasta ahora vuelquen. Un proceso iterativo
especialmente conocido se llama Proceso Unificado
(originalmente llamado Proceso Unificado Rational, en honor a
Rational Software, que lo originó). Define cuatro fases de cada
iteración: inicio, elaboración, construcción y transición. Un
conjunto de casos de uso elegidos define los objetivos de cada
iteración, y las iteraciones se ordenan para abordar primero los
mayores riesgos.
3. Ágil. El término "desarrollo ágil de software" se refiere a
un grupo de metodologías de desarrollo de software, las más
conocidas de las cuales incluyen Scrmn, Extreme Programming
y Crystal Clear. Todas estas metodologías son incrementales e
iterativas. Como tal, se pueden considerar algunas metodologías
iterativas como Agile. Lo que distingue a las prácticas ágiles es
la entrega temprana y frecuente de software en funcionamiento,
una estrecha colaboración entre desarrolladores y clientes,
organizar equipos y centrarse en la adaptación a las
circunstancias cambiantes (como los requisitos de llegada
tardía). Todas las metodologías ágiles se centran en el trabajo en
equipo, la adaptabilidad y la colaboración estrecha (tanto dentro
del equipo como entre los miembros del equipo y los clientes /
usuarios finales). Por lo general, estas metodologías evitan un
trabajo inicial sustancial, en el supuesto de que los requisitos
siempre cambian y continúan cambiando a lo largo del ciclo de
vida del proyecto.
Como tal, podría parecer que las metodologías ágiles y la
arquitectura no pueden coexistir felizmente.
4. Desarrollo impulsado por modelos. El desarrollo
impulsado por modelos se basa en la idea de que los humanos
no deberían escribir código en lenguajes de programación, sino
que deberían crear modelos del dominio, a partir del cual el
código se genera automáticamente. Los humanos crean una
plataforma
modelo independiente (PIM), que se combina con un modelo
de definición de plataforma (PDM) para generar código en
ejecución. De esta manera, el PIM es una mera realización de
los requisitos funcionales, mientras que el PDM aborda las
características específicas de la plataforma y los atributos de
calidad.
Todos estos procesos incluyen el diseño entre sus
obligaciones, y debido a que la arquitectura es un tipo especial
de diseño, la arquitectura encuentra un hogar en cada uno. El
cambio de un proceso de desarrollo a otro en medio de un
proyecto requiere que el arquitecto guarde información útil del
proceso anterior y determine cómo integrarlo en el nuevo
proceso.
No importa qué proceso de desarrollo de software o modelo
de ciclo de vida esté utilizando, hay una gran cantidad de
actividades que están involucradas en la creación de una
arquitectura de software, el uso de esa arquitectura para realizar
un diseño completo y luego implementar o gestionar la
evolución de un objetivo. sistema o aplicación.
El proceso que utilice determinará la frecuencia y el
momento en que revisará y desarrollará cada una de estas
actividades. Estas actividades incluyen:
1. Hacer un caso de negocio para el sistema
2. Comprensión de los requisitos de importancia
arquitectónica
3. Crear o seleccionar la arquitectura
4. Documentar y comunicar la arquitectura
5. Analizar o evaluar la arquitectura
6. Implementación y prueba del sistema basado en la
arquitectura.
7. Asegurarse de que la implementación se ajuste a la
arquitectura.
Arquitectura en un contexto empresarial
Las arquitecturas y los sistemas no se construyen de forma
frívola. Sirven para algunos fines comerciales, aunque, como se
mencionó anteriormente, estos fines pueden cambiar con el
tiempo.
Arquitecturas y objetivos comerciales
Los sistemas se crean para satisfacer los objetivos
comerciales de una o más organizaciones. Las organizaciones de
desarrollo quieren obtener ganancias, capturar mercado,
permanecer en el negocio o ayudar a sus clientes a hacer mejor
su trabajo, o mantener a su personal con un empleo remunerado,
o hacer felices a sus accionistas, o un poco de cada uno. Los
clientes tienen sus propios objetivos para adquirir un sistema,
que generalmente implican algún aspecto para hacer sus vidas
más fáciles o más productivas. Otras organizaciones
involucradas en el ciclo de vida de un proyecto, como
subcontratistas o agencias reguladoras gubernamentales, tienen
sus propios objetivos relacionados con el sistema. Los
arquitectos deben comprender quiénes son las organizaciones
con derechos adquiridos y cuáles son sus objetivos. Muchos de
estos objetivos tendrán una profunda influencia en la
arquitectura. Muchos objetivos comerciales se manifestarán
como requisitos de atributos de calidad. De hecho, cada atributo
de calidad, como el tiempo de respuesta visible para el usuario
o la flexibilidad de la plataforma o la seguridad férrea, o
cualquiera de una docena de otras necesidades, debe tener su
origen en algún propósito superior que pueda describirse en
términos de valor agregado. Si preguntamos, por ejemplo, "¿Por
qué quiere que este sistema tenga un tiempo de respuesta
realmente rápido?" es posible que escuchemos que esto
diferenciará el producto de su competencia y permitirá que la
organización en desarrollo capture la participación de mercado.
Sin embargo, algunos objetivos comerciales no se mostrarán en
forma de requisitos. Sabemos de un arquitecto de software a
quien su gerente le informó que la arquitectura debería incluir
una base de datos. El arquitecto estaba perplejo, porque los
requisitos del sistema realmente no garantizaban una base de
datos y el diseño del arquitecto había evitado muy bien poner
una, simplificando así el diseño y reduciendo el costo del
producto. El arquitecto estaba perplejo, es decir, hasta que el
gerente le recordó al arquitecto que el departamento de bases de
datos de la empresa estaba sobrecargado de personal y con poco
trabajo. ¡Necesitaban algo que hacer! El arquitecto introdujo la
base de datos y todo salió bien. No es probable que ese tipo de
personal de mantenimiento de objetivos comerciales con empleo
remunerado aparezca en ningún documento de requisitos, pero
si el arquitecto no lo hubiera cumplido, el gerente habría
considerado la arquitectura como inaceptable, tal como lo habría
hecho el cliente si fallara para proporcionar una pieza clave de
funcionalidad.
Aún otros objetivos comerciales no tienen ningún efecto
sobre la arquitectura. Un objetivo comercial para reducir los
costos se puede lograr pidiendo a los empleados que trabajen
desde casa, que bajen los termostatos de la oficina en invierno o
que usen menos papel en las impresoras.
Arquitectura en un contexto profesional
¿Qué hacen los arquitectos? ¿Cómo te conviertes en
arquitecto? En esta sección hablamos de las múltiples facetas de
ser arquitecto que van más allá de lo aprendido en un curso de
programación o ingeniería de software. Probablemente ya sepa
que los arquitectos necesitan algo más que habilidades técnicas.
Los arquitectos deben explicar a una parte interesada u otra las
prioridades elegidas de las diferentes propiedades y por qué las
partes interesadas en particular no están cumpliendo todas sus
expectativas. Entonces, para ser un arquitecto eficaz, necesitará
habilidades diplomáticas, de negociación y comunicación.
Realizarás muchas actividades más allá de producir
directamente una arquitectura. Estas actividades, que llamamos
deberes, forman la columna vertebral de la competencia
arquitectónica individual. Examinamos el amplio conjunto de
información dirigida a los arquitectos (como sitios web, cursos,
libros y descripciones de puestos para arquitectos), así como a
los arquitectos en ejercicio, y las funciones son solo un aspecto.
Los escritores sobre arquitectos también hablan de habilidades
y conocimientos. Por ejemplo, los arquitectos necesitan la
capacidad de comunicar ideas con claridad y necesitan tener
conocimientos actualizados sobre (por ejemplo) patrones,
plataformas de bases de datos o estándares de servicios web.
Los deberes, las habilidades y el conocimiento forman una
tríada sobre la que se basa la competencia en arquitectura.
Deberá participar en el apoyo a la gestión y en el trato con los
clientes. Deberá administrar una carga de trabajo diversa y poder
cambiar de contexto con frecuencia. Necesitará conocer las
consideraciones comerciales.
VII. CONCLUCIONES
La reutilización de software ofrece una solución para
eliminar el trabajo repetido y mejorar la eficiencia y la calidad
en el desarrollo de software. En los últimos diez años, la
tecnología orientada a objetos ha aparecido y se ha convertido
en una tecnología convencional, proporcionando así un soporte
tecnológico fundamental para la reutilización de software. en
investigación de ingeniería de software y se considera un
enfoque práctico y factible para resolver la crisis del software.
La reutilización de software generalmente se clasifica en dos
catálogos: reutilización de productos y reutilización de procesos.
de investigación de reutilización de software. Al mismo tiempo,
la tecnología de componentes de software juega un papel
importante en la investigación de objetos distribuidos. Por lo
tanto, la tecnología de componentes de software se considera un
factor clave para la reutilización de software exitosa. El
desarrollo y la aplicación de la tecnología de reutilización de
software facilitarán la revolución. de desarrollo de software y
reorganizar software como resultado, el desarrollo de
componentes de software se convertirá en una industria
independiente e inseparable. Las decisiones de diseño
arquitectónico son los elementos que conforman la arquitectura
de un Sistema. Dichas decisiones son tomadas por los
arquitectos de TI basados en su conocimiento y experiencia, que
en muchos casos es poca cuando se trata de tecnologías
emergentes como microservicios. En cualquier proyecto de
software que vaya más allá de una prueba de concepto o
demostración, necesitaremos una organización racional del
trabajo. Tendremos que esforzarnos en buscar patrones
repetibles para agilizar futuros procesos y debemos armarnos
con criterios duraderos para tomar decisiones coherentes a lo
largo del ciclo de vida del proyecto. Esto es, lo que en el mundo
de la arquitectura del software, llamamos una metodología.
Pero, ¿cómo optar por una u otra? ¿Cómo decidir si adherirnos
o no a un determinado estándar? ¿Cómo determinar el nivel
adecuado para formalizar más o menos el andamiaje de la
solución? ¿Está la metodología contraviniendo la agilidad en el
desarrollo? En definitiva, ¿qué criterios seguir para tomar
decisiones?.
Las respuestas a estas preguntas estarán condicionadas por
las prioridades que otorguemos a los objetivos que nos
marquemos al definir nuestra arquitectura del software. En mi
credo aparecen objetivos que a todos os resultarán familiares y
difícilmente podemos prescindir de alguno de ellos. Pero la
cuestión es que, ante una situación de escasez de recursos para
hacer frente a todos ellos como se merecen, ¿cuál es la
prioridad? ¿se pueden ordenar estos sagrados objetivos?. Para el
caso de pequeñas consultoras, o startups creando su primer
producto propongo esta lista ordenada
Agilidad en el desarrollo, para fomentar la productividad
y aceptar cambios en la funcionalidad sin traumas.
Funcionalidad Básica, para poder ser evaluada cuanto
antes, y que además sirva de revulsivo o pequeño quick-win.
Fiabilidad en la ejecución. Es mejor que haga poco, pero
bien, pues la desconfianza una vez instaurada es muy difícil de
erradicar.
Mantenimiento operativo y correctivo: programar con el
usuario, pero también con el operador y futuros programadores
en mente.
Extensibilidad de la funcionalidad, ya que la hemos
reducido inicialmente debemos ser muy precavidos para dejar
puntos de extensibilidad suficientes.
Adaptabilidad sin compilación. Ficheros de
configuración, parametrizaciones, técnicas de inyección de
código, cualquier posibilidad de mejora… sin recompilar y
redistribuir el proyecto principal.
Funcionalidad completa. La competencia y las demandas
de los clientes no tienen límite, debemos completar la aplicación
agregando módulos a buen ritmo.
 Seguridad de la información. Según el sector de destino,
este puede ser un punto crucial que avance posiciones.
Velocidad en la ejecución. Optimizar los tiempos totales
y sobre todo los percibidos por el usuario.
Coste total. Resumen y colofón de todo lo anterior.
¿Cuánto me cuesta producir el programa de esta forma? ¿Me
saldría más barata otra tecnología?
A lo largo de mi experiencia profesional me he encontrado
con proyectos de mayor o menor calado, pero todos se han visto
afectados por los anteriores factores. Esta suerte de
mandamientos en mi experiencia constituye la clave del éxito de
los desarrollos de multitud de proyectos.
Creo que cualquier metodología ante todo debe ser ágil para
no entorpecer la productividad de la empresa, y permitirle
alcanzar una funcionalidad básica que pueda ser apreciada y
validada por el destinatario del software, el cliente. Si esto no se
produce, el proyecto en sí puede desaparecer. Un equipo de
desarrollo lento o una metodología engorrosa son un factor
decisivo hacia el fracaso.
Para continuar debemos pensar en corregir, completar y
adaptar el software hasta satisfacer las necesidades del usuario.
Si los primeros objetivos se han cumplido deberíamos suplir las
carencias del piloto con facilidad, y haciendo entregas continuas
ganarnos la confianza del usuario que verá como día a día
evoluciona el producto. La seguridad debe implantarse de forma
gradual y supeditada a los criterios principales de agilidad y
mantenimiento. Esto lo digo ahora que ningún administrador de
sistemas nos oye…
No priorizo la velocidad, pues no soy amigo de
optimizaciones tempranas que puedan retrasar el nacimiento del
proyecto. Prefiero métricas reales y atacar los cuellos de botella
que se detecten con el uso, favoreciendo siempre la sensación de
velocidad del usuario.
Por último, el coste del proyecto, entendido este como la
suma de los factores productivos clásicos (maquinaria y mano
de obra), el mantenimiento futuro, y la imagen final (plataforma
de despliegue…). Realmente la consideración del coste está
implícita en cada decisión tomada, si no eres tú el que te juegas
tu dinero, alguien habrá que lo haga, y te recordará vía
presupuesto cuál es tu cajón de arena para jugar.
Como reflexión diré que cualquier metodología debe ser
tomada como una guía y no como una ley estricta, máxime
cuando todos los objetivos reseñados son vitales. Estar abiertos
a cambios, ser permeables al conocimiento y abusar del sentido
común, os permitirá ordenar vuestros objetivos en cada
proyecto, y con ello tomar decisiones adecuada y
coherentemente.
VIII. REFERENCIAS
[1] I. Sommerville, Ingeniería del software, USA: Pearson
Educación, 2005, pp. 389-390.
[2] C. J. Date, Introducción a los sistemas de bases de datos,
México: Pearson Educación de México, 2001, pp. 27-
28.
[3] C. M. Ricardo, Bases de datos, México: McGraw-Hill
Interamericana, 2004.
[4] M. V. Nevado Cabello, Introducción a las bases de datos
relacionales, España: Visión Libros, 2010.
[5] A. La Fuente, «El blog de Aukera,» Aukera mastering
data, [En línea]. Available: https://aukera.es/blog/bases-
de-datos-relacionales-vs-no-relacionales/. [Último
acceso: 24 Diciembre 20020].
[6] P. J. Sadalage y M. Fowler, NoSQL Distilled. A Brief
Guide to the Emerging World of Polyglot Persistence,
USA: Addison-Wesley, 2013.
[7] J. E. Córcoles Tendero, Acceso a Datos (GRADO
Superior), España: RA-MA, 2013.
[8] M. Cíceri, Introducción a Laravel: Aplicaciones
robustas y a gran escala, Chile: Creative Andina Corp,
2019.
[9] G. Méndez González, Aprende a Desarrollar con Spring
Framework: 2ª Edición, España: IT Campus Academy,
2016.
[10] S. Ladd, D. Davison, S. Devijer y C. Yates, Expert
Spring MVC and Web Flow, USA: Apress, 2006.
[11] L. Cosmina, R. Harrop, C. Schaefer y C. Ho, Pro Spring
5An In-Depth Guide to the Spring Framework and Its
Tools, USA: Apress, 2017.
[12] P. Kuchana, Software Architecture Design Patterns in
Java, USA: CRC Press, 2004.
[13] D. Alur, J. Crupi y D. Malks, Core J2EE Patterns Best
practices and design strategies, USA: Prentice Hall PTR,
2003.
[14] L. Bass, P. Clements y R. Kazman, Software
architecture in practice, 2013: Pearson Education,, USA.