Fundamentos de la arquitectura de software

REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD NACIONAL EXPERIMENTAL
DE LOS LLANOS OCCIDENTALES
“EZEQUIEL ZAMORA” – UNELLEZ
BARINAS EDO BARINAS

Fundamentos de la
Arquitectura de software
Integrantes:
Roger Villegas C.I. 18.839.157
Nathalinis Barrios C.I. 19.517.983

Breve Historia de la Arquitectura del
software
1960 la historia de la arquitectura del software remonta a la época
de los años 60 desde ese entonces se empezó a utilizar el término
cuando Edsger Dijkstra de la Universidad Tecnológica de Eindhoven
en Holanda en 1968 propuso que se establezca una estructura
correcta de los sistemas de software antes de que se inicie la
programación como tal, escribiendo código de cualquier manera.
En 1969 un año después de la sesión en que se fundara la ingeniería
de software, P. I. Sharp formuló que la ingeniería era diferente a la
“arquitectura”.
En 1969 Fred Brooks Jr y Ken Iverson llamaban arquitectura a la
estructura conceptual de un sistema en la perspectiva del
programador

software
En 1972, Parnas publicó un ensayo en el que discutía la forma en
1972
que la modularidad en el diseño de sistemas podía mejorar la
flexibilidad y el control conceptual del sistema, introduciendo el
concepto de Ocultamiento de información, La herencia de este
concepto en la ingeniería y la arquitectura ulterior es inmensa, y se
confunde estrechamente con la idea de abstracción.
En 1975, Brooks, diseñador del sistema operativo OS/360 y Premio
1975
Turing 2000, utilizaba el concepto de arquitectura del sistema para
designar “la especificación completa y detallada de la interfaz de
usuario”.
En la década de 1980, los métodos de desarrollo estructurado
1980
demostraron no escalar suficientemente y fueron dejando el lugar a
un nuevo paradigma, el de la programación orientada a objetos.

software
La década de 1990, fue la década de la “arquitectura de software”,
dando cumplimiento a las profecías de Perry y Wolf, fue sin duda la
década de consolidación y diseminación de la AS en una escala sin
precedentes. Las contribuciones más importantes surgieron en
torno del instituto de ingeniería de la información de la Universidad
Carnegie Mellon (CMU SEI). En la misma década, demasiado
pródiga en acontecimientos, surge también la programación basada
en componentes, que en su momento de mayor impacto impulsó a
algunos arquitectos mayores, como Paul Clements (Clements Enero
de 1996.), a afirmar que la AS promovía un modelo que debía ser
más de integración de componentes pre-programados que de
programación.

software

Conceptos fundamentales
• Estilos
Un estilo, es un concepto descriptivo que define una forma de
articulación u organización arquitectónica. El conjunto de los estilos
cataloga las formas básicas posibles de estructuras de software,
siendo este, un aspecto fundamental de la AS (Wolfy Perry).
•El modelado OO y UML no lo cubren satisfactoriamente.
•Su descripción, se puede formular en lenguaje natural o en
diagramas
•Se recomienda hacerlo en un lenguaje de descripción
arquitectónica (ADLs) o en lenguajes formales de especificación.
Ejemplos: arquitecturas basadas en flujo de datos, las peer-to-peer,
las de invocación implícita, las jerárquicas, las centradas en datos o
las de intérprete- máquina virtual.

Conceptos fundamentales
• Lenguajes de descripción arquitectónica (ADLs)
Los ADLs permiten modelar una arquitectura mucho antes
que se lleve a cabo la programación de las aplicaciones que la
componen, analizar su adecuación, determinar sus puntos
críticos y eventualmente simular su comportamiento.
•Aparecieron a principios de los 90´s
•Lo integran un conjunto de propuestas, ampliamente
conocidas en el ámbito académico
•Se fundamentan en la incapacidad de expresar conectores
en UML
•Alrededor de 20 ADLs han sido reconocidos
•Son poco utilizados en la industria del software
Ejemplos: AADL, Acme, Rapide, LILEANA, etc.

Frameworks y Vistas
• Un framework permite ordenar las diferentes perspectivas de
una arquitectura en términos de vistas. Una vista es un
subconjunto resultante de practicar una selección o
abstracción sobre una realidad, desde un punto de vista
determinado.

Frameworks y Vistas
La IEEE Std 1471-2000 procura establecer una base común para la
descripción de arquitecturas de software, e implementa para ello
tres términos básicos:
•Arquitectura. Es la organización fundamental de un sistema,
encarnada en sus componentes, las relaciones entre ellos y con su
entorno, y los principios que gobiernan su diseño y evolución.
•Vista. Es la representación concreta de un sistema en particular
desde una perspectiva unitaria.
•Punto de vista. Define un patrón o plantilla (template) para
representar un conjunto de incumbencias (concerns) relativas a una
arquitectura. Ejemplos: punto de vista estructural, punto de vista
conductual, punto de vista de interconexión física.
El punto de vista estructural ha sido motivado por el trabajo de los
ADLs

Procesos y metodologías
•Proceso. Hace alusión a los marcos de trabajo las cuales
son representados por vistas. Por ejemplo: las vistas
estáticas se corresponden con las perspectivas particulares
de los diferentes participantes y las vistas dinámicas tienen
que ver con etapas del proceso, el ciclo de vida o
metodología caracterizadas en requerimientos, análisis,
diseño, implementación e integración.
•Metodología. Hace referencia a un framework que es
usado para estructurar, planear y controlar el proceso de
desarrollo en sistemas de información: RUP, RAD, RSD,
ARIS, PERA, CIMOSA, GRAI, GERAM, CMM. En el campo de
a AS la dominante es el Modelo de Madurez de la
Capacidad (CMM).

Métodos Específicos de Procesos de
Ingeniería que Sistematizan el Rol de
la Arquitectura en la Totalidad del
Proceso (Desarrollados en el SEI):
•
•
•
•
•
•
•
•
•
•
•
•

Architecture Based Design (ABD),
Software Architecture Analysis Method (SAAM)
Quality Attribute Workshops (QAW)
Quality Attribute-Oriented Software Architecture Design Method (QASAR)
Attribute-Driven Design (ADD)
Architecture Tradeoff Analysis Method (ATAM)
Active Review for Intermediate Design (ARID)
Cost-Benefits Analysis Method (CBAM)
Family-Architecture Analysis Method (FAAM)
Architecture Level Modifiability Analysis (ALMA)
Software Architecture Comparison Analysis Method (SACAM)
Aplicabilidad e impacto de los métodos en el proceso de desarrollo de software

Métodos Específicos de Procesos de
Ingeniería que Sistematizan el Rol de
la Arquitectura en la Totalidad del
Proceso (Desarrollados en el SEI):

Abstracción
Una abstracción denota las características esenciales de un objeto
que lo distingue de otras clases de objeto y provee de este modo
delimitaciones conceptuales bien definidas, relativas a la perspectiva
del observador.
Grady Booch, 1991
La abstracción consiste en extraer las propiedades esenciales, o
identificar los aspectos importantes, o examinar selectivamente
ciertos aspectos de un problema, posponiendo o ignorando los
detalles menos sustanciales, distractivos o irrelevantes.
IEEE, Rumbaugh, Shaw, et.
En un estilo, “menos es más”: Si una decisión se pospone hasta el
momento de tratar las cosas a bajo nivel, entonces, ésta no es una
decisión arquitectónica
Bass, Clemennts, Kazman, 1998

Escenarios
Son técnicas que se implementan en la elicitación de los
requerimientos, particularmente en relación a los operadores
de sistemas. Los escenarios, también son utilizados como
métodos para comparar alternativas de diseño ya que
permiten realizar una descripción anticipada del sistema y
típicamente se expresan en una frase.
Kazban, Abow, Bass y Clements, 1996
Métodos de diseño y desarrollo basados en arquitectura por
escenarios: ALMA, SAAM y ATAM

Escenario de autenticación
basada en notificaciones

Campos de la arquitectura de
software
La AS es un conjunto inmenso y heterogéneo de áreas de
investigación teórica y de formulación práctica. Garlan y
Perry (IEEE Transactions on Software Engineering, 1995)
delinean las áreas de investigación más promisoras de la AS:
•Lenguajes de descripción de arquitecturas
•Fundamentos formales de la AS (bases matemáticas,
caracterizaciones formales de propiedades extra-funcionales
tales como mantenibilidad, teorías de la interconexión,
etcétera).
•Técnicas de análisis arquitectónicas
•Métodos de desarrollo basados en arquitectura
•Recuperación y reutilización de arquitectura
•Codificación y guía arquitectónica
•Herramientas y ambientes de diseño arquitectónico

Campos de la arquitectura de
software

Necesidades actuales:
•Modelos precisos que razonen sobre las propiedades
actuales de una arquitectura verificando su consistencia y
completitud.
•Automatización de los procesos de análisis, diseño y
síntesis.

Arquitecturas mas comunes
•Monolítica. Donde el software se estructura en grupos
funcionales muy acoplados.
•Cliente-servidor. Donde el software reparte su carga de
cómputo en dos partes independientes pero sin reparto claro
de funciones.
•Arquitectura de tres niveles. Especialización de la
arquitectura cliente- servidor donde la carga se divide en tres
partes (o capas) con un reparto claro de funciones:
–una capa para la presentación (interfaz de usuario),
–otra para el cálculo (donde se encuentra modelado el
negocio) y
–otra para el almacenamiento (persistencia).

Arquitecturas mas comunes
desde otra perspectiva:
•Descomposición Modular
•Arquitecturas de Dominio Específico
•Diseño Software Arquitectura Multiprocesador
•Diseño Software Arquitectura Cliente Servidor
•Diseño Software Distribuido
•Diseño Software Tiempo Real

Modalidades y tendencias
•Corrientes de la AS propuestas por Carlos Billy Reynoso
(2004):
1.Arquitectura como etapa de ingeniería y diseño orientada a
objetos. Esta perspectiva concierne a decisiones sobre
organización, selección de elementos estructurales,
comportamiento, composición y estilo arquitectónicos
susceptibles de ser descritas a través de las cinco vistas
clásicas del modelo 4+1 de Kruchten (UML y Rational).
Rumbaugh, Jacobson, Book, Larman, Kruchten, entre otros..

2.Arquitectura estructural. Basada en un modelo estático de
estilos, ADLs y vistas. La representan los académicos de la
Universidad Carnegie Mellon de Pittsbugh: Shaw, Clements,
Garlan, Allen, Abowd, Ockerbloom. En ella se reconocen tres
modalidades en cuanto a formalización:
–Descripción verbales o diagramas de caja (los más
informales)
–Los que se sirven de ADLs (intermedios), y
–Los que utilizan lenguajes formales de especificación como
CHAM y Z (los más exigentes)

4.Arquitectura basada en patrones. No está rígidamente
vinculada con el modelado UML, ni a las metodologías de
CMM. El diseño consiste en identificar y articular patrones
preexistentes, que se definen en forma parecida a los estilos
de arquitectura.
5.Arquitectura procesual. Intenta establecer modelos de ciclo
de vida y técnicas de elicitación de requerimientos,
brainstorming, diseño, análisis, selección de alternativas,
validación, comparación, estimación de calidad y justificación
económica específicas para la arquitectura de software. La
documentación se encuentra en SEI, pero no se mezcla con
CMM.

6.Arquitectura basada en escenarios. Es la corriente más
nueva. Se trata de un movimiento predominantemente
europeo, con centro en Holanda. Recupera el nexo de la AS
con los requerimientos y la funcionalidad del sistema, el cual
es, ocasionalmente borroso en la arquitectura estructural
clásica. En esta corriente suele utilizarse diagramas de casos
de uso UML como herramienta informal u ocasional, dado
que los casos de uso son uno de los escenarios posibles.
Los casos de uso no están orientados a objeto.

Otras menos populares son:
Genética), Arquitectura centrada en la acción (inteligencia
artificial heideggeriana), Arquitectura epistemológicamente
reflexiva, etc.
Y del lado opuesto: la anti-arquitectura

Diferencias entre arquitectura y
diseño
La arquitectura es el primer paso en la producción de un diseño de
software (Shaw y Garlan,1996), en donde los pasos que la distinguen
son:
1.Arquitectura. Asocia los requerimientos con los componentes del
sistema que habrán de implementarla. Estilos complejos a partir de
estilos simples, es decir, sistemas a partir de subsistemas.
2.Diseño de código. Comprende algoritmos y estructuras de datos; los
componentes son primitivas de los lenguajes de programación (números,
caracteres, punteros, etc.).
3.Diseño ejecutable. Remite el diseño a un nivel de detalle más bajo
(asignación de memoria, formato de datos, etc.).
La arquitectura concierne a un nivel de abstracción mas elevado; se
ocupa de componentes y no de procedimientos; de las interacciones de
esos componentes y no de las interfaces; de las restricciones a ejercer
sobre los componentes y de las interacciones y no de los algoritmos, los
procedimientos y los tipos. (Dewayne Perry, 1997)

diseño
Taylor Medvidovic (2000). Señala que la literatura mantiene un estado
ambiguo al existir diferentes interpretaciones.
1)Arquitectura y diseño son lo mismo
2)La AS se encuentra en un nivel de abstracción por encima del diseño
3)La AS es otro paso en el proceso de software
4)La AS es algo nuevo y en alguna medida diferente al diseño

diseño
Estephen Albin (2003). La arquitectura es una metáfora de diseño de
software la cual abarca las metodologías de diseño, así como
metodologías de análisis.
“El arquitecto contemporáneo ejecuta una combinación de roles
(analistas, diseñadores e ingenieros de software), pero ahora caen en
una orquestación del Shief Architect”
•La arquitectura integra las actividades de análisis y diseño en un
framework de diseño más amplio y coherente.
•La integración de las metodologías y modelos es lo que distingue a la
AS de la simple yuxtaposición de técnicas de análisis y diseño

Fundamentos de la arquitectura
del software
La Arquitectura de Software es la organización fundamental de un
sistema
encarnada en sus componentes, las relaciones entre ellos y el ambiente
y los
principios que orientan su diseño y evolución
Repositorios de la Arquitectura de Software
Existen unos cuantos repositorios de información arquitectónica, cuyas
direcciones son más o menos permanentes. El más importante hoy en
día parece ser el del Software Engineering Institute en la Universidad
Carnegie Mellon de Pittsburgh, Pennsylvania
(http://www.sei.cmu.edu/ata/ata_init.html)
El sitio del SEI incluye abundante literatura académica y todas las
especificaciones o recomendaciones metodológicas.

Fundamentos de la arquitectura
del software
Entre los organismos que definen estándares, son esenciales los
servicios de información de RM-ODP en
http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html, TOGAF
en
http://www.software.org/pub/architecture/togaf.asp DoDAF (hogar del
C4ISR) en http://www.software.org/pub/architecture/dodaf.asp El
estándar IEEE 1471-2000 se puede encontrar en
http://www.techstreet.com/cgibin/detail?product_id=879737 El marco de
referencia empresarial de Zachman se puede acceder desde
http://www.software.org/pub/architecture/zachman.asp
.
Las páginas de cabecera de la estrategia de arquitectura de Microsoft se
hal
lan en http://msdn.microsoft.com/architecture/ Las páginas de Patterns &
Practices están en
http://www.microsoft.com/resources/practices/completelist.asp La
estrategia

Relevancia de la Arquitectura de
Software
Aunque todavía no se ha constituido un repositorio uniformizado de
estudios de casos en base al cual se pueda extraer una conclusión
responsable, la AS ha resultado instrumental en un número respetable de
escenarios reduciendo costos, evitando errores, encontrando fallas,
implementando sistemas de misión crítica. Cada uno de los documentos
que describen lenguajes de descripción arquitectónica, por ejemplo,
subraya su utilización exitosa en proyectos de gran envergadura
requeridos por organizaciones de gobierno o
por grandes empresas.

Software
Aún cuando aquí y allá se señalen dificultades ocasionales, nadie duda
de la necesidad de una visión arquitectónica. Escribe Barry Boehm,
especialista máximo en gestión de riesgo y bien conocido creador del
COCOMO y del método de desarrollo en espiral:
Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su
justificación, el proyecto no debe empezar el desarrollo en gran escala. Si
se
especifica la arquitectura como un elemento a entregar, se la puede usar
a lo largo de los procesos de desarrollo y mantenimiento [Boe95].

Software
Antes que transcribir listas de ideas que a veces coinciden y otras
señalan características heterogéneas, sintetizaremos las virtudes de la
AS articulando las opiniones convergentes de los expertos [CN96]
[Gar00]:
1. Comunicación mutua. La AS representa un alto nivel de abstracción
común que la mayoría de los participantes, si no todos, pueden usar
como base para crear entendimiento mutuo, formar consenso y
comunicarse entre sí. En sus mejores expresiones, la descripción
arquitectónica expone las restricciones de alto nivel sobre el diseño del
sistema, así como la justificación de decisiones arquitectónicas
fundamentales.

Software

2. Decisiones tempranas de diseño. La AS representa la encarnación de
las decisiones de diseño más tempranas sobre un sistema, y esos
vínculos tempranos tienen un peso fuera de toda proporción en su
gravedad individual con respecto al desarrollo restante del sistema, su
servicio en el despliegue y su vida de mantenimiento. La arquitectura
representa lo que el método SAAM una puerta de peaje: el desarrollo no
puede proseguir hasta que los participantes involucrados aprueben su
diseño.

Software
3. Restricciones constructivas. Una descripción arquitectónica
proporciona
blueprintsparciales para el desarrollo, indicando los componentes y las
dependencias entre ellos. Por ejemplo, una vista en capas de un
arquitectura documenta típicamente los límites de abstracción entre las
partes, identificando las principales interfaces y estableciendo las formas
en que unas partes pueden interactuar con otras.
4. Reutilización, o abstracción transferible de un sistema. La AS encarna
un modelo relativamente pequeño, intelectualmente tratable, de la forma
en que un sistema se estructura y sus componentes se entienden entre
sí; este modelo es transferible através de sistemas; en particular, se
puede aplicar a otros sistemas que exhiben requerimientos parecidos y
puede promover reutilización en gran escala. El diseño arquitectónico
soporta reutilización de grandes componentes o incluso de frameworks
en el que se pueden integrar componentes.

Software
5. Evolución. La AS puede exponer las dimensiones a lo largo de las
cuales puede esperarse que evolucione un sistema. Haciendo explícitas
estas “paredes” perdurables, quienes mantienen un sistema pueden
comprender mejor las ramificaciones de los cambios y estimar con mayor
precisión los costos de las modificaciones. Esas delimitaciones ayudan
también a establecer mecanismos de conexión que permiten manejar
requerimientos cambiantes de interoperabilidad, prototipado y
reutilización.
6. Análisis. Las descripciones arquitectónicas aportan nuevas
oportunidades para el análisis, incluyendo verificaciones de consistencia
del sistema, conformidad con las restricciones impuestas por un estilo,
conformidad con atributos de calidad, análisis de dependencias y análisis
específicos de dominio y negocios.

Software
7. Administración. La experiencia demuestra que los proyectos exitosos
consideran una arquitectura viable como un logro clave del proceso de
desarrollo industrial. La evaluación crítica de una arquitectura conduce
típicamente a una comprensión más clara de los requerimientos, las
estrategias de implementación y los riegos potenciales

Definiciones de estilos
Estilo también se utiliza en la informática: las hojas de estilo en
cascada (Cascading Style Sheets, CSS según sus siglas en inglés)
componen un lenguaje que se emplea para estipular cómo se presentará
un documento que ha sido desarrollado en XML, HTML o XHTML.
Es la forma en que el autor plasma lo que escribe usando rasgos propios
y particulares.
El estilo es la expresión de la personalidad del autor. Es el rostro del
alma. Es el hombre. Es su Vida.
Cada autor es un estilo nuevo. Exactamente inimitable., ineditable,
absoluto diríase.
Dos autores pueden parecerse al escribir pero jamás sus estilos serán
copia exacta uno de otro. Ni que traten sobre el mismo tema. Ni que usen
palabras iguales. Ni que pongan en sus obras el mismo fervor.
Dos elementos fundamentales lo integran, el espíritu y la técnica literaria.
Predominando el espíritu, que es como decir, el dolor, la alegría, la
angustia, la esperanza, el odio, el amor, el cinismo, la fraternal
sinceridad.

Los estilos arquitectónicos:
Es la clasificación arquitectónica en los términos de forma,
técnicas,materiales, período, región, etc.Surgen del estudio de la
evolución y la historia de la arquitectura.El estilo arquitectónico es una
manera de clasificar la arquitectura que da énfasis a las
característicasdel diseño, dando lugar a una terminología
Es un estilo bastante sencillo. No lleva molduras ( detalles en relieve ) ni
detalles recargados, es de líneasrectas y simples.La decoración
transmite una sensación de informalidad y juventud. Es simple y
funcional, se caracterizapor crear espacios amplios y luminosos. Se
puede optar por colores claros en paredes y muebles. Es unestilo muy
práctico, los muebles son de líneas puras y detalles discretos.Un
mobiliario apropiado sería:Sillas. De madera laqueada, sola o con base
de acero. Podríamos usar, asimismo, sillas en plástico decolores, con
tapicería también colorida y diseños modernos.Mesas. Las mesas
pueden ser de plástico, enchape melamínico o madera de acabado
laqueado;preferentemente redondas, pues son menos rígidas.Mobiliario
de apoyo. Como en los estilos anteriores, sólo para colocar vajilla y
mantelería. Pueden sersencillas, en madera o enchape melamínico, con
puertas y divisiones para guardar utensilios.

Clasificaciones
Estilos de flujo de datos
Tubería-filtros
Tubería-filtros uniforme
Estilos de replicación
Repositorio replicado
Cache
Estilos jerárquicos
Cliente-servidor
Sistemas en capas y Cliente-servidor en
capas
Cliente-Servidor sin estado
Cliente-servidor con
cache
en cliente
Cliente-servidor con
cache
en cliente y servidor sin estado
Sesión remota
Acceso a datos remoto

Estilos de código móvil
Máquina virtual
Evaluación remota
Código a demanda
Código a demanda en capas
Agente móvil
Estilos peer-to-peer
Integración basada en eventos

Descripción
Los estilos sólo se manifiestan en arquitectura teórica descript
iva de alto nivel de abstracción; los patrones, por todas partes.
Los partidarios de los estilos se definen desde el inicio como
arquitectos; los que se agrupan en torno de los patrones se
confunden a veces con ingenieros y diseñadores, cuando no
con programadores con conciencia sistemática o lo que alguna
vez se llamó analistas de software
El primer grupo ha abundado en taxonomías internas de los
estilos y en reflexión teórica;el segundo se ha mantenido, en
general, refractario al impulso taxonómico, llevado por una
actitud resueltamente empírica. Ambos, con mayor o menor
plenitud y autoconciencia, participan del campo abarcativo de la
arquitectura de software.

Los patrones arquitectónicos
Por su parte, se han materializado con referencia a
lenguajes y paradigmas también específicos de desarrollo,
mientras que ningún estilo presupone o establece
preceptivas al respecto. Si hay algún código en las
inmediaciones de un estilo, será código del lenguaje de
descripción arquitectónica o del lenguaje de modelado; de
ninguna manera será código de lenguaje de programación
Los patrones de arquitectura están claramente dentro de
la disciplina arquitectónica, solapándose con los estilos

Patrones Arquitectónico
Según Buschmann los patrones de arquitectura se pueden
ver como la descripción de un problema en particular y
recurrente de diseño, que aparece en contextos de diseño
arquitectónicos específicos, y representa un esquema
genérico demostrado con éxito para su solución. El
esquema de solución se especifica mediante la
descripción de los componentes que la constituyen, sus
responsabilidades y desarrollos, así como también la
forma en que estos colaboran entre sí. (Buschmann, et al.,
1996).
Los patrones arquitectónicos se definen sobre aspectos
fundamentales de la estructura del sistema software,
donde se especifican un conjunto de subsistemas con sus
responsabilidades y una serie de recomendaciones para
organizar los distintos componentes.

Patrón de Diseño
Un patrón de diseño provee un esquema para refinar los
subsistemas o componentes de un sistema de software, o
las relaciones entre ellos. Describe la estructura
comúnmente recurrente de los componentes en
comunicación, que resuelve un problema general de
diseño en un contexto particular (Buschmann, et al.,
1996).
Son menores en la escala de abstracción que los patrones
arquitectónicos, además tienden a ser independientes de
los lenguajes y paradigmas de programación. Su
aplicación tiene efectos sobre subsistemas, debido a que
especifica a un mayor nivel de detalle, sin llegar a la
implementación, el comportamiento de los componentes
del subsistema.

Fundamentos de la arquitectura de software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Fundamentos de la arquitectura de software

Similar a Fundamentos de la arquitectura de software (20)

Fundamentos de la arquitectura de software