1) El documento presenta información sobre la arquitectura de software, incluyendo su historia, definición de conceptos clave como estilos y lenguajes de descripción, y campos y tendencias en arquitectura de software. 2) Se proporcionan detalles sobre tres bachilleres de la Universidad Nacional Experimental de los Llanos Occidentales Ezequiel Zamora, incluyendo sus números de cédula. 3) El documento fue creado en enero de 2014 por la universidad mencionada para fomentar conocimientos sobre arqu

1. Universidad Nacional Experimental
De los Llanos Occidentales Ezequiel Zamora
UNELLEZ- Barinas
Arquitectura del
software
Bachilleres:
21.168.736 Caro José
19.193.035 Díaz Nohely
23.028.057 Díaz Bárbara
Ing. Informática
Barinas, Enero 2014

2. Introducción
Al principio del tiempo la programación e informática eran consideradas un arte y se
desarrollaban como tal con algo de dificultad, debido a ello se fueron creando formas y
quías generales con base a la cuales se pudieran resolver los problemas. Tal invención se
denominó Arquitectura del Software debido a la semejanza de los planos de un edifico o
construcción, ya que indican la estructura, funcionamiento e interacciones entre las partes
del software.
Dicho informe tiene como objeto fomentar conocimientos relacionado a la arquitectura del
Software, su historia, inicio y fundamentos, además de los procesos campos y
metodologías. Cabe destacar que nace como una respuesta a la necesidad de contar con los
conocimientos determinados para analizar y resolver problemas. Esta recopilación de
información es procedente de diversas fuentes o lecturas lo que ayudaran a la mejor
comprensión de dicha unidad.

3. Breve historia de la arquitectura de software: Sus inicios y fundamentos
Aunque el término arquitectura de software, tal y como lo concebimos ahora,
aparece en 1992 con el trabajo de Perry y Wolf, sus antecedentes se remontan al menos
hasta finales de la década de los sesenta. En 1968, Dijkstra habla de una estructuración
correcta de los sistemas de software, aunque no la llama arquitectura como tal.
Posteriormente, en 1969, P. I. Sharp, comentando las ideas de Dijkstra, ya usa el término
arquitectura de software al mencionar que quizá luego se hable de “la escuela de
arquitectura de software de Dijkstra”, y al mismo tiempo lamentar que la industria de ese
tiempo preste muy poca atención a ésta.
Durante la década de los setentas el concepto de arquitectura deambuló por el aire
sin una semántica clara y carente de una expresión pragmática. En esta misma década, el
diseño estructurado dio pie a la independencia entre el diseño y la implementación. Los
trabajos de Parnas sobre técnicas de modularización en decisiones de diseño y familias de
programas, fueron, sin duda, aportaciones esenciales y permanentes.
Rompiendo esquemas y acaparando la atención en la década de los ochentas,
aparece el paradigma de la orientación a objetos. En esta década aparecen dos trabajos
importantes de Mary Shaw, que retoman las abstracciones de alto nivel: “Técnicas de
abstracción en lenguajes modernos de programación” y “Los sistemas de gran escala
requieren de abstracciones de alto nivel”.
Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de
manera más clara la idea de que las aplicaciones tienen una morfología, una estructura. El
trabajo de Perry y Wolf de 1992 es el punto de partida para lo que hoy conocemos como
arquitectura de software. Por un lado, son los primeros que proponen un modelo para la
arquitectura de software; este modelo contempla a la arquitectura formada por tres
componentes: elementos, forma y razón. Los elementos pueden ser de procesamiento, datos
o conexión; la forma se define de acuerdo a las propiedades, y a las relaciones entre los

4. elementos; la razón se contempla en términos de restricciones del sistema, que se derivan
de los requerimientos del sistema.
Perry y Wolf profetizaron que: “la década de los noventas, creemos, será la década
de la arquitectura de software”, lo cual se convirtió en realidad. A lo largo de esa década,
salieron a la luz varios trabajos con propuestas relevantes, entre ellas, la programación
basada en componentes, el surgimiento de los patrones y estilos, el modelo de 4+1 visto, y
lenguajes de descripción de arquitecturas (ADL) entre otras.
En la segunda mitad de los noventa aparecen los primeros libros de texto dedicados
a la arquitectura de software. El año 2000 cierra esta década con dos trabajos clave: el
modelo REST propuesto en la tesis de Roy Fielding que pone la atención en Internet y los
modelos orientados a servicios; y el trabajo de la IEEE, que genera una versión definitiva
de la recomendación IEEE std 1471-2000.
También en este año se abren nuevas perspectivas para la arquitectura de software,
aparecen las estrategias orientadas a líneas de productos y se procura insertar la arquitectura
de software dentro del ciclo de vida, obligando a redefinir las metodologías referentes a él
en términos de arquitectura.
Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en
arquitectura, métodos de análisis y diseño de arquitecturas (dentro del ciclo de vida),
análisis de arquitecturas de software basados en escenarios, modelos de evaluación de
arquitecturas de software y modelos orientados por la arquitectura entre algunos otros
tópicos.
Definición de los 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

5. de estructuras de software, mientras que las formas complejas se articulan mediante
composición de los estilos fundamentales.
Sucintamente descriptos, los estilos conjugan elementos (o “componentes”, como se
los llama aquí), conectores, configuraciones y restricciones. Al estipular los conectores
como elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se sitúa
en un orden de discurso y de método que el modelado orientado a objetos en general y
UML en particular no cubren satisfactoriamente. La descripción de un estilo se puede
formular en lenguaje natural o en diagramas, pero lo mejor es hacerlo en un lenguaje de
descripción arquitectónica o en lenguajes formales de especificación.
A diferencia de los patrones de diseños, que son centenares, los estilos se ordenan
en seis o siete clases fundamentales y unos veinte ejemplares, como máximo. Es digno de
señalarse el empeño por subsumir todas las formas existentes de aplicaciones en unconjunto
de dimensiones tan modestas. Las arquitecturas complejas o compuestasresultan del
agregado o la composición de estilos más básicos. Algunos estilos típicos sonlas
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.
Lenguajes de descripción de arquitecturas:Los lenguajes de descripción de
arquitecturas, o ADLs, ocupan una parte importante del trabajo arquitectónico desde la
fundación de la disciplina. Se trata de un conjunto de propuestas de variado nivel de
rigurosidad, casi todas ellas de extracción académica, que fueron surgiendo desde
comienzos de la década de 1990 hasta la actualidad, más o menos en contemporaneidad con
el proyecto de unificación de los lenguajes de modelado bajo la forma de UML. Los ADL
difiere sustancialmente de UML, que al menos en su versión 1.x se estima inadecuado en su
capacidad para expresar conectores en particular y en su modelo semántico en general para
las clases de descripción y análisis que se requieren. Los ADLs permiten modelar una
arquitectura mucho antes que se lleve a cabo la programación de las aplicaciones que la

6. componen, analizar su adecuación, determinar sus puntos críticos y eventualmente simular
su comportamiento.
Los ADL son bien conocidos en los estudios universitarios de AS, pero muy
pocosarquitectos de industria parecen conocerlos y son menos aún quienes los utilizan
comoinstrumento en el diseño arquitectónico de sus proyectos. Hay unos veinte ADL
deprimera magnitud y tal vez unos cuarenta o cincuenta propuestos en ponencias que nohan
resistido el paso del tiempo o que no han encontrado su camino en el mercado. Sehan
analizado esos lenguajes descriptivos en un documento aparte, en el cual se invitaasimismo
a su discusión.
Frameworks y Vistas: LosFrameworksson una estructura conceptual y tecnológica de
soporte definido, normalmente con artefactos o módulos de software concretos, que puede
servir de base para la organización y desarrollo de software. Típicamente, puede incluir
soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para
así ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las
entidades del dominio, y provee una estructura y una especial metodología de trabajo, la
cual extiende o utiliza las aplicaciones del dominio.
Las vistas, Al final, a este miembro de la familia le corresponde dibujar, o expresar la
última forma de los datos: la interfaz gráfica que interactúa con el usuario final del
programa (GUI). Después de todo, a este miembro le toca evidenciar la información
obtenida hasta hacerla llegar al controlador. Solo (e inicialmente), nos espera demostrar la
información.
Procesos y metodología:
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

7. ciclo de vida o metodología caracterizadas en requerimientos, análisis, diseño,
implementación e integración.
Metodología: Hace referencia a un frameworkque 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).
Abstracción: La idea de abstracción forma parte de lo que acaso sea la pieza conceptual
más importante de la AS, el concepto de estilo; un estilo se identifica a grandes rasgos o,
como se dice habitualmente, en un estilo “menos es más”. La misma idea prevalece en
todos los conceptos y procedimientos que se consideran arquitectónicos. Para
LenBass,PaulClements y Rick Kazman [BCK98], si una decisión debe posponerse hasta el
momento de tratar las cosas a un bajo nivel, no se trata de una decisión de arquitectura.
Clements y Northrop [CN96] sostienen que el trabajo de Garlan y Shaw sobre los
estilos arquitectónicos nos enseña que aunque los programas pueden combinarse de
maneras prácticamente infinitas, hay mucho que ganar si nos restringimos a un conjunto
relativamente pequeño de elecciones cuando se trata de cooperación e interacción. Las
ventajas incluyen mejor reutilización, mejores análisis, menor tiempo se selección y mayor
interoperabilidad. “Menos es más” figura, de hecho, en el título y en los contenidos de
numerosos papers de la profesión [MB02] [CN96]. Conceptos como el de estilo, o marcos
como MSF, revelan su naturaleza arquitectónica en su abstracción y en su generalidad.
Escenarios:Esta es una noción arquitectónica importante y se encuentra en la base de
muchos de los métodos de diseño y desarrollo basados en arquitectura, como ALMA,
SAAM y ATAM.Hay que ser precavidos y advertir desde el comienzo que lo que
habitualmente se traduce como “escenario” no es estrictamente lo que en lengua castellana
se designa como tal; la traducción correcta debería ser más bien “guión” o “libreto”. La
traducción literal del término no hace más que aportar confusión. Desde Kruchten en

8. adelante, se reconoce que los escenarios se dividen en dos categorías: casos de uso
(secuencias de responsabilidades) y casos de cambio (modificaciones propuestas al
sistema). Los escenarios han sido básicamente técnicas que se implementan en la
elicitación de los requerimientos, particularmente en relación a los operadores de sistemas.
Típicamente, la técnica comienza instrumentando sesiones de brainstorming. También se
han utilizado escenarios como método para comparar alternativas de diseño. Los escenarios
describen una utilización anticipada o deseada del sistema, y típicamente se expresan en
una frase; Kazman, Abowd, Bass y Clements proponen también llamarlos viñetas
Campos de la arquitectura del software:
La AS es hoy en día un conjunto inmenso y heterogéneo de áreas de investigación
teórica y de formulación práctica, por lo que conviene aunque más no sea enumerar algunos
de sus campos y sus focos. Una semblanza semejante (de la que aquí se proporciona sólo
un rudimento) dudosamente debería ser estática. La AS comenzó siendo una abstracción
descriptiva puntual que en los primeros años no investigó de manera sistemática ni las
relaciones que la vinculaban con los requerimientos previos, ni los pasos metodológicos a
dar luego para comenzar a componer el diseño. Pero esa sincronicidad estructuralista no
pudo sostenerse. Por el contrario, daría la impresión que, a medida que pasa el tiempo,
laAS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la
ingeniería de software, sólo que a un mayor nivel de abstracción y agregando una nueva
dimensión reflexiva en lo que concierne a la fundamentación formal del proceso.
Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en torno
de las áreas que componen el territorio. David Garlan y Dewayne Perry, en su introducción
al volumen de abril de 1995 de IEEE Transactionson Software Engineering dedicado a
laAS, en el cual se delinean las áreas de investigación más promisorias, enumeran las
siguientes:

9. 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
 Estudios de casos
Modalidades y tendencias en la arquitectura de software:
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.
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 verbal o diagramas de caja (los más informales).

10.  Los que se sirven de ADLs (intermedios).
 Los que utilizan lenguajes formales de especificación como CHAM y Z (los más
exigentes).
Estructuralismo arquitectónico radical: Formada por un grupo europeo con una
actitud confrontativa con UML. Tiene al menos dos tendencias: Una excluye el modelado
OO para AS y otra integra metamodelos y estereotipos correctivos de UML.
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.
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.
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.
Diferencias entre arquitectura y diseño
Literalmente se dice que es lo mismo, pero yendo más profundo el diseño es una
parte de la arquitectura, por eso se dice que ambas tienen el mismo propósito, la
arquitectura de software en la estructura del sistema y en las interconexiones se diferencia

11. del diseño, en otras palabras el diseño son todos los componentes en detalle, mientras que
la arquitectura muestra como estos componentes se interconectan entre si formando su
estructura.
La arquitectura se encarga de: Selección de tecnologías Requerimientos no
funcionales Manejo de riesgos, etc. y el Diseño se encarga de: Los requerimientos
funcionales Diseño detallado de componentes, etc.
Repositorios y relevancia de la arquitectura del software
Un repositorio, depósito o archivo es un sitio centralizado donde se almacena y
mantiene información digital, habitualmente bases de datos o archivos informáticos.
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
EngineeringInstituten
la
Universidad
Carnegie
Mellon
de
Pittsburgh,
Pennsylvanhttp://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.
Las páginas de cabecera de la estrategia de arquitectura de Microsoft se hallan en
http://msdn.microsoft.com/architecture/.
Las
páginas
de
Patterns&Practices
enhttp://www.microsoft.com/resources/practices/completelist.asp.
La
están
estrategia
arquitectónica misma se encuentra delineada en un documento de Michael Platt en
http://msdn.microsoft.com/architecture/overview/default.aspx?pull=/library/enus/dnea/html
/eaarchover.asp.
Numerosas editoriales, universidades, consorcios y centros de investigación
incluyenvínculos ligados a la AS. Muy seguramente los lectores podrán suministrar otros
sitios dereferencia importantes.

12. Las relevancia: 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. Aun cuando aquí y allá se señalen dificultades
ocasionales, nadie duda de la necesidad de una visión arquitectónica.
Las virtudes de la arquitectura del software son:
 Comunicación mutua
 Decisiones tempranas
 Restricciones constructivas
 Reutilización, o abstracción transferible de un sistema
 Evolución
 Análisis
 Administración
Definiciones de estilo
Los estilos sólo se manifiestan en arquitectura teórica descriptiva 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

13. la arquitectura de software. Los estilos se encuentran en el centro de la arquitectura y
constituyen buena parte de su sustancia. Los patrones de arquitectura están claramente
dentro de la disciplina arquitectónica, solapándose con los estilos, mientras que los patrones
de diseño se encuentran más bien en la periferia, si esque no decididamente afuera.
Según esa definición, estilos y arquitectura nacen en el mismo momento. Con una
sola excepción (documentada en el párrafo siguiente) no he podido encontrar referencias a
la palabra estilos anteriores a 1992. Todavía en julio de ese año Robert Allen y David
Garlan [AG92] de la Universidad de Carnegie Mellon se refieren a “paradigmas de
arquitectura” y “estructuras de sistemas”, mencionando entre ellos lo que luego sería el
familiar estilo tubería-filtros, los modelos de pizarra y los de flujo de datos. Con nombres
idénticos, esos paradigmas pasarían a llamarse estilos un mes más tarde en todos los textos
de la misma escuela primero y en toda la arquitectura de software después.
Inventario y descripción de los estilos arquitectónicos
Los estilos que habrán de describirse a continuación no aspiran a ser todos los que
se han propuesto, sino apenas los más representativos y vigentes. De más está decir que,
como se ha visto, la agrupación de estilos y sub-estilos es susceptible de realizarse de
múltiples formas, conforme a los criterios que se apliquen en la constitución de los
ejemplares. No se ha de rendir cuentas aquí por la congruencia de la clasificación (nadie ha
hecho lo propio con las suyas), porque cada vez que se la ha revisado en modo outline, se
cedió a la tentación de cambiar su estructura, la cual seguirá sufriendo metamorfosis
después de despachado el artículo. Se podrá apreciar que, en consonancia con los usos de la
especialidad, la caracterización de los estilos no constituye un reflejo pormenorizado de los
detalles de sus estructuras, sino una visión deliberadamente sucinta y genérica que destaca
sus valores esenciales y sus rasgos distintivos. Entre acumular pormenores que podrían
recabarse en otras fuentes y mantener el caudal descriptivo de cada estilo en una magnitud
que facilite su comparación rápida con los demás se ha escogido, Saussureanamente, lo
segundo.

14. En cuanto a las formas de representación esquemática, se ha optado por reproducir
el estilo gráfico característico de la literatura principal del género, el cual es
deliberadamente informal y minimalista, en lugar de aplicar una notación formal o más
elaborada. La notación se establecerá entonces en términos de lo que Shaw y Clements
llaman “boxology” [SC96]. Huelga decir que la descripción de los estilos puede hacerse
también en términos de lenguajes descriptivos de arquitectura (ADLs) y las respectivas
notaciones de las herramientas que se asocian con ellos, según puede verse en un estudio
separado [Rey04b]. Resta anticipar que algunas especies de software conspicuas en la
práctica no aparecen en los catálogos usuales de estilo. La ausencia más notoria concierne a
los sistemas de workflow, que seguramente heredan el prejuicio ancestral de los ingenieros
y arquitectos más refinados en contra de los diagramas de flujo y las abstracciones
procesuales. Fred Brooks, por ejemplo, considera el diagrama de flujo como una
abstracción muy pobre de la estructura de un sistema.
Estilos y patrones de arquitectura y diseño:
La dinámica incontenible de la producción de patrones en la práctica de la
arquitectura desoftware, su carácter entusiasta, cuando no militante, y la profusión de sus
manifestaciones han atenuado la idea de que los patrones de diseño constituyen sólo uno de
los paradigmas, marcos o formas del diseño arquitectónico, cada uno de los cuales posee
una historia y una fundamentación distinta, y presenta, como todas las cosas en este terreno,
sus sesgos, sus beneficios y sus limitaciones. Todo el mundo acepta que existen diversas
clases de patrones: de análisis, de arquitectura (divididos en progresivamente estructurales,
sistemas distribuidos, sistemas interactivos, sistemas adaptables), de diseño (conductuales,
creacionales, estructurales), de organización o proceso, de programación y los llamados
idiomas, entre otros. Cada autor que escribe sobre el asunto agrega una clase diferente, y
los estándares en vigencia no hacen ningún esfuerzo para poner un límite a la proliferación
de variedades y ejemplares. Como sea, concentrémonos inicialmente en los patrones de
diseño.

15. Un patrón de diseño, obviamente, debe encajar por un lado con otros tipos de
patrones imaginables y por el otro con la teoría, la práctica y los marcos que en general
rigen el diseño. ¿Cuáles son las grandes estrategias de diseño, si puede saberse? Una vez
más, cuando llega el momento de disponer en un mapa las estrategias, los marcos de
referencia o los paradigmas de diseño disponibles se encuentra multitud de propuestas
clasificatorias que a veces no coinciden siquiera en la identificación de la disciplina en que
se formulan. De todas maneras, estimo que es razonable pensar que las estrategias mayores
de diseño pueden subsumirse en un conjunto relativamente manejable de cuatro o cinco
tipos, uno de los cuales es, precisamente, el diseño orientado por patrones. Estas estrategias
no necesariamente son excluyentes y antagónicas, pero se encuentran bastante bien
delimitadas en la literatura usual.

16. Conclusión

Durante la década de los setentas el concepto de arquitectura deambuló por
el aire sin una semántica clara y carente de una expresión pragmática.

En la década de los ochentas, aparece el paradigma de la orientación a
objetos.

Hacia finales de los ochenta y principios de los noventa, comienza a gestarse
de manera más clara la idea de que las aplicaciones tienen una morfología, una estructura.

Un estilo es un concepto descriptivo que define una forma de articulación u
organización arquitectónica.

LosFrameworksson
una estructura conceptual y tecnológica de soporte
definido, que puede servir de base para la organización y desarrollo de software.

Las virtudes de la arquitectura del software son:Comunicación mutua,
Decisiones tempranas, Restricciones constructivas. Reutilización, o abstracción transferible
de un sistema, Evolución, Análisis y Administración.