AODELACONSOLIDACINDELMARDEGRAU

Trabajo
Monogrfico

Integrante

:AriasRetegui,ErickHarold.
GuevaraAller,GerardoRafael.
MogollonCalvo,LuisEnrique.
LinaresChumbe,SauloPatrick.
VelaChung,Akemi.
JaraPalacios,EricJos.

Carrera

:Ing.SistemaseInformtica.

Grado

:Universitario.

Curso :IngenieradeSoftware02.
Profesor

:Ing.IsraelDanielLozanodelCastillo.

Tema

:DefinicionesdeArquitecturadeSoftware.
ElRoldelArquitectodeSoftware.
ArquitecturayTecnologasdeSoftware.

Septiembrede2016
IquitosPer

DEFINICIN DE ARQUITECTURA DE SOFTWARE

EL ROL DEL ARQUITECTURA DE SOFTWARE
ARQUITECTURA Y TECNOLOGA DE SOFTWARE

DEDICATORIA

Queremos dedicar esta vez a al nombre de nuestro padre Dios porque

me cuida en los momentos difciles, y para enfrentar esa gran valla va
ser difcil pero no imposible de rebasar, tenemos la voluntad de
demostrar toda nuestra amplitud de estudios.

INDICE
I.

Ttulo

II.

Dedicatoria

III.

Introduccin

IV.

Captulos
Captulo I: Definicin del Arquitectura de Software.
1.1. Definicin.
1.2. Resea Histrica.
1.3. Caractersticas.
1.4. Ciclo de Desarrollo de la Arquitectura.
1.5. Para qu sirve la Arquitectura de Software?
1.6. Cul es su Funcin?
1.7. Qu no Hace un Arquitecto de Software?
Captulo II: El Rol del Arquitecto de Software.
2.1. Definicin.
2.2. Caractersticas del Arquitecto de Software.
2.3. Responsabilidades de un Arquitecto de Software.
2.4. Tipos de Arquitecto de Software.
2.5. Fases en que Participa un Arquitecto de Software.
Captulo III: Arquitecturas y Tecnologa de Software.
3.1. Modelos Arquitectnicos.
3.2. Estilos Arquitectnicos.
3.3. Lenguajes de Descripcin de Arquitectura.
3.4. Diseo.
3.5. Patrones de Arquitectura.
3.6. Definicin de Vistas.
3.7. Vista Usuario y Proveedores.

V.

CONCLUSIN.

VI.

WEBGRAFA.

INTRODUCCIN

En este trabajo presentaremos la muestra terica de las definiciones de

arquitectura de software, cul es su rol ahora en la actualidad y como est
relacionado con tecnologa con la arquitectura. Si hablamos Arquitectura de
Software hablamos de forma lgica, Por qu? Porque se abarca por patrones
abstractas que el arquitecto disea mediante los objetivos (requisitos) y
restricciones. El protagonismo del arquitecto de software se muestra por la
escalabilidad, la disponibilidad, auditora, etc. Es decir que est encargado de
gestionar los proyectos de software, asumir la propiedad del proceso del
desarrollo del producto; pero esto embarca una relacin que coexisten durante
mucho tiempo que es la tecnologa de software porque gracias a la evolucin
de las herramientas se optimizo los procesos y consiguiente se redujo el
consumo de recursos o se pueden hacer software ms complejo.

CAPTULOS

Captulo I: Definicin del Arquitectura de Software:

1.1.

Definicin:

Una Arquitectura de Software, tambin denominada Arquitectura lgica,

consiste en un conjunto de patrones y abstracciones coherentes que
5

proporcionan un marco definido y claro para interactuar con el cdigo fuente del
software. Los componentes que llevan a cabo alguna tarea de computacin,
sus interfaces y la comunicacin entre ellos. Una arquitectura de software se
selecciona y disea con base en objetivos (requerimientos) y restricciones. Los
objetivos son aquellos prefijados para el sistema de informacin, pero no
solamente los de tipo funcional, tambin otros objetivos como la mantenibilidad,
flexibilidad e interaccin con otros sistemas de informacin. La arquitectura de
software de un programa o de un Sistema computacional est definida por la
estructura, comprendida por los elementos de software, las propiedades
visibles de esos elementos y las relaciones entre ellos.
1.2.

Resea Histrica.

Todava no se ha escrito una historia aceptable de la AS. Desde que Mary

Shaw o David Garlan researan escuetamente la prehistoria de la especialidad
a principios de los 90. Situar las inflexiones de la breve historia de la AS en un
contexto temporal, asimismo, ayudar a comprender mejor cules son sus
contribuciones perdurables y cules sus manifestaciones contingentes al
espritu de los tiempos y a las modas tecnolgicas que se han ido sucediendo.
Si bien la AS acostumbra remontar sus antecedentes al menos hasta la dcada
de 1960, la historia de la arquitectura de software se reconoce que, en un
principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnolgica de
Eindhoven. Aunque Dijkstra no utiliza el trmino arquitectura para describir el
diseo conceptual del software, 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
6

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.

1.3.

Caractersticas:

Representacin de alto nivel de la estructura del sistema describiendo las

partes que lo integran.

Puede incluir los patrones que supervisan la composicin de sus

componentes y las restricciones al aplicar los patrones.

Trata

aspectos

del

diseo

desarrollo

que

no

pueden

tratarse

adecuadamente dentro de los mdulos que forman el sistema.

Parte del diseo de software.

Nivel del diseo de software donde se definen la estructura y propiedades

globales del sistema.

Incluye

sus componentes,

las

propiedades

observables

de

dichos

componentes y las relaciones que se establecen entre ellos.

Un aspecto crtico: Una arquitectura errnea puede llevar a problemas

incontables.

1.4.

Ciclo de Desarrollo de la Arquitectura:

Dentro de un proyecto de desarrollo, e independientemente de la metodologa

que se utilice, se puede hablar de desarrollo de la arquitectura de software.
Este desarrollo, que precede a la construccin del sistema, est dividido en las
siguientes etapas:

Requerimientos: La etapa de requerimientos se enfoca en la captura,

documentacin y priorizacin de requerimientos que influencian la
arquitectura.

Diseo: La etapa de diseo es la etapa central en relacin con la

arquitectura y probablemente la ms compleja. Durante esta etapa se
definen las estructuras que componen la arquitectura. La creacin de
estas estructuras se hace en base a patrones de diseo, tcticas de
diseo y elecciones tecnolgicas.

Documentacin: Una vez creado el diseo de la arquitectura, es

necesario poder comunicarlo a otros involucrados dentro del desarrollo.
La comunicacin exitosa del diseo muchas veces depende de que
dicho diseo sea documentado de forma apropiada.

Evaluacin: Dado que la arquitectura de software juega un papel crtico

en el desarrollo, es conveniente evaluar el diseo una vez que este ha
sido documentado con el fin de identificar posibles problemas y riesgos.
1.5.

Para qu sirve la Arquitectura de Software?

La arquitectura de un sistema de software nos ayuda a satisfacer los requisitos

de calidad que debe cumplir un sistema de software permitiendo que la
solucin creada sea confiable, mantenerlo, estable, usable.
Una buena arquitectura nos ayuda a realizar estos cambios con menos tiempo
y esfuerzo, adems de facilitar la implementacin de una estrategia de re-uso.
1.6.

Cul es su Funcin?

Diseo preliminar o de alto nivel.

Organizacin a alto nivel del sistema, incluyendo aspectos como la

descripcin y anlisis de propiedades relativas a su estructura y control
global, los protocolos de comunicacin y sincronizacin utilizados, la
distribucin fsica del sistema y sus componentes, etc.

1.7.

Qu no hace un Arquitecto de Software?

Diseo detallado.
8

 Diseo de algoritmos.
Diseo de estructuras de datos.

Captulo II: El Rol del Arquitecto de Software.

2.1.

Definicin:
9

El Arquitecto de Software debe ser una persona con amplios conocimientos

tcnicos, gran experiencia en programacin, liderazgo y que ejerza las
siguientes funciones:

Gestin de los requisitos no funcionales y definicin de la Arquitectura

de Software:
En muchos proyectos de software se suele preguntar a los usuarios qu
caractersticas desean en el producto a desarrollar, pero muchas veces
se pasan por alto los requisitos no funcionales (tienen que ser
especficos, medibles, alcanzables y comprobables, para

poder

satisfacerlos). Se caracteriza por el rendimiento, la escalabilidad, la

disponibilidad, auditora, etc. El siguiente paso es pensar en cmo se
resolvern los problemas expuestos y definir la arquitectura.

Seleccin de la Tecnologa:
Suele ser un ejercicio con una serie de desafos interesantes y en el cual
se debe tomar en cuenta un universo de factores como el coste, las
licencias, la relacin con los proveedores, la estrategia de la tecnologa,
la compatibilidad e interoperabilidad, poltica de actualizaciones, etc.
Adicionalmente hay que conocer si las tecnologas funcionan realmente
y se adaptan o no a los requerimientos del software.

Mejora continua de la Arquitectura:

Es imposible pensar en el desarrollo de software sin tomar en cuenta
procesos de evaluacin y feedback que permitan conocer si el software
satisface las expectativas del usuario.
De igual manera es necesario someter a la arquitectura de software a
dichos procesos, para demostrar que funciona, que efectivamente
resuelve los requisitos no funcionales y por tanto reducir el riesgo
general de fracaso del proyecto.

Facilitador:
10

La arquitectura del software debe ser conocida y entendida no solo por

el equipo de desarrollo sino tambin por otras reas como seguridad
informtica, base de datos, operaciones, el equipo de mantenimiento,
etc.
Facilitador para la colaboracin entre estos grupos de inters de manera
de garantizar que la arquitectura se integrar con xito en el entorno
empresarial.

Lder y Formador:
El Arquitecto de Software debe asumir la direccin tcnica, para
asegurar que todos los aspectos de la arquitectura se estn
implementando de manera correcta.
Debe proporcionar orientacin tcnica y dar apoyo al equipo de
desarrollo.

Aseguramiento de la Calidad.
Garantizar la calidad es parte fundamental del rol de un Arquitecto de Software,
el cual debe apoyarse en procesos de integracin continua que utilicen
herramientas automatizadas de anlisis de cdigo fuente, pruebas unitarias y
cobertura de cdigo, para asegurar el cumplimiento de las normas, polticas y
mejores prcticas establecidas.
Desafortunadamente, en la actualidad pocos arquitectos de software que
laboran en la industria han recibido una formacin terica respecto al
tema. Esto se debe a que no es sino hasta pocas recientes que se han
establecido de manera ms formal los conceptos relacionados con la
arquitectura de software, y que actualmente pocas instituciones ofrecen
cursos enfocados en el tema.

11

2.2. Caractersticas del Arquitecto de Software:

Investiga nuevas tecnologas y comprende Frameworks arquitectnicos y las

mejores prcticas.
Desarrolla rpidamente profundo conocimiento en una tecnologa.
Tiene liderazgo y autoridad.
Sigue y dirige a la vez.
Es un buen comunicador.
Entiende el dominio del negocio.
Es un negociador.
Posee fuerte visin para los negocios.
Entiende la poltica de la empresa.
Puede trabajar con informacin ambigua o incompleta.
Identificar e interactuar con los interesados en el proyecto para asegurarse

que sus necesidades son satisfechas.

Se orienta por objetivos y pro-actividad.
Debe poseer la madurez, visin y tener un juicio crtico.

2.3.

Responsabilidades de un Arquitecto de Software:

Elaborar la arquitectura correcta para solucionar el problema que se encuentra

desarrollando es solo una parte de la responsabilidad del arquitecto.

Define y documenta la solucin, asegurndose que est acorde con el

sistema deseado y que adems es la forma correcta para su soporte y

evolucin.
Se asegura que todos los involucrados estn utilizando la solucin

elaborada y la estn utilizando bien.

Conoce cuales cualidades sistmicas, deben alcanzarse y en qu

medida.
Responde sobre las inquietudes relacionadas con la seleccin de

herramientas y ambientes de desarrollo.

Resuelve conflictos y ayuda a generar acuerdos.
Mantiene la moral, tanto en el interior del grupo de arquitectura como al
exterior.

2.4. Tipos de Arquitecto de Software:

Arquitecto empresarial (Corporativo): Esta mayor variedad, en general,
apunta a grandes organizaciones, donde cada funcin est claramente
12

dividida y, sobre todo, limitada, transformando al arquitecto en un ente con

responsabilidades restringidas.

Arquitecto de soluciones (funcional): Validan diseos; guan a los

desarrolladores, para que cumplan con las expectativas de calidad tomando
mtricas, organizando y promoviendo la documentacin y las buenas
prcticas; aseguran que el proyecto no se desve de la arquitectura
previamente definida.

Arquitecto Tcnico: probablemente, est asignado a uno o varios proyectos

al mismo tiempo. Algunas de sus responsabilidades suelen ser: definir los
lineamientos de diseo, su arquitectura y dems cuestiones tcnicas de los
proyectos.

Arquitecto de Infraestructura: requiere un conocimiento integral de la

arquitectura y prctica tcnica para que usted pueda planificar de acuerdo
con el dimensionamiento de la infraestructura de implementacin y las
expectativas de rendimiento, cumplir la poltica de tecnologas de la
informacin (TI) de la empresa y satisfacer los requisitos funcionales y de
integracin del usuario final.

2.5.

Fases en que Participa un Arquitecto de Software.

Pre diseo.
Anlisis del dominio.
Diseo esquemtico.
Desarrollo del diseo.
Documentacin del proyecto.
Seleccin y contratacin.
Construccin.
Post Construccin.

Captulo III: Arquitecturas y Tecnologas.

Ms all de que hoy existan numerosos conceptos en el plano detallado de las
tcnicas y metodologas, la AS se articula alrededor de unos pocos conceptos y
principios esenciales y unas pocas herramientas caractersticas.
3.1.

Modelos Arquitectnicos:

1. Modelos estructurales: Sostienen que la AS est compuesta por

componentes, conexiones entre ellos y (usualmente) otros aspectos tales
13

como configuracin, estilo, restricciones, semntica, anlisis, propiedades,

racionalizaciones, requerimientos, necesidades de los participantes. El
trabajo en esta rea est caracterizado por el desarrollo de lenguajes de
descripcin arquitectnica (ADLs).
2. Modelos de Frameworks: Son similares a la vista estructural, pero su
nfasis primario radica en la (usualmente una sola) estructura coherente
del sistema completo, en vez de concentrarse en su composicin. Los
modelos de framework a menudo se refieren a dominios o clases de
problemas especficos.
3. Modelos dinmicos: Enfatizan la cualidad conductual de los sistemas.
Dinmico puede referirse a los cambios en la configuracin del sistema, o
a la dinmica involucrada en el progreso de la computacin, tales como
valores cambiantes de datos.
4. Modelos de proceso: Se concentran en la construccin de la arquitectura,
y en los pasos o procesos involucrados en esa construccin. En esta
perspectiva, la arquitectura es el resultado de seguir un argumento (script)
de proceso. Esta vista se ejemplifica con el actual trabajo sobre
programacin de procesos para derivar arquitecturas.
5. Modelos funcionales: Una minora considera la arquitectura como un
conjunto de componentes funcionales, organizados en capas que
proporcionan servicios hacia arriba.

Es tal vez til pensar en esta visin como un framework particular. Ninguna de estas
vistas excluye a las otras, ni representa un conflicto fundamental sobre lo que es o
debe ser la AS. Por el contrario, representan un espectro en la comunidad de
investigacin sobre distintos nfasis que pueden aplicarse a la arquitectura: sobre sus
partes constituyentes, su totalidad, la forma en que se comporta una vez construida, o
el proceso de su construccin. Tomadas en su conjunto, destacan ms bien un
consenso.
3.2.

Estilos Arquitectnicos:

En el texto fundacional de la AS, Perry y Wolf establecen el razonamiento sobre

estilos de arquitectura como uno de los aspectos fundamentales de la
disciplina. Un estilo es un concepto descriptivo que define una forma de
articulacin u organizacin arquitectnica.

14

El conjunto de los estilos cataloga las formas bsicas posibles de estructuras

de software, mientras que las formas complejas se articulan mediante
composicin de los estilos fundamentales.
Sucintamente descriptos, los estilos conjugan elementos (o componentes),
conectores, configuraciones y restricciones. Al estipular los conectores como
elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se
sita en un orden de discurso y de mtodo que el modelado orientado a objetos
en general y UML en particular no cubren satisfactoriamente. La descripcin de
un estilo se puede formular en lenguaje natural o en diagramas, pero lo mejor
es hacerlo en un lenguaje de descripcin arquitectnica o en lenguajes
formales de especificacin.

3.8.

Lenguajes de Descripcin de Arquitectura

Los lenguajes de descripcin de arquitecturas, o ADLs, ocupan una parte

importante del trabajo arquitectnico desde la fundacin de la disciplina. Se
trata de un conjunto de propuestas de variado nivel de rigurosidad, casi todas
ellas de extraccin acadmica, que fueron surgiendo desde comienzos de la
dcada de 1990 hasta la actualidad.
Los ADLs permiten modelar una arquitectura mucho antes que se lleve a cabo
la programacin de las aplicaciones que la componen, analizar su adecuacin,
determinar sus puntos crticos y eventualmente simular su comportamiento.
Los ADLs son bien conocidos en los estudios universitarios de AS, pero muy
pocos arquitectos de industria parecen conocerlos y son menos an quienes
los utilizan como instrumento en el diseo arquitectnico de sus proyectos.

3.4.

Diseos:

Descomposicin Modular.
El principal objetivo de la descomposicin modula es de componer los
problemas difciles en problemas sencillos de tal manera sera ms eficiente el
desarrollo del sistema. La descomposicin modular se enfoca en reutilizar
15

cdigo, adems debido a esta descomposicin cada mdulo es desarrollado

con un fin especfico, de esta manera los futuros programadores comprendern
fcilmente la funcin de cada mdulo.

Diseo de Software de Arquitectura Multiprocesador.

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios
procesos de forma concurrente, un multiprocesador es aquel que cuenta con
dos o ms microprocesadores. Permite que se ejecuten varios procesos de
forma concurrente. conjunto de tareas que pueden ser completadas
rpidamente si hay varias unidades de proceso ejecutndolas.
Los objetivos de la programacin paralela, son:
Reducir el tiempo de cmputo.
Reducir la complejidad del algoritmo,
Aprovechar al mximo la capacidad de las computadoras multiproceso.

Diseo de Arquitectura de Software Cliente - Servidor.

La arquitectura cliente-servidor es un modelo de aplicacin distribuida en el que
las tareas se reparten entre los proveedores de recursos o servicios, llamados

16

servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones

a otro programa, el servidor, quien le da respuesta.
En esta arquitectura la capacidad de proceso est repartida entre los clientes y
los servidores, aunque son ms importantes las ventajas de tipo organizativo
debidas a la centralizacin de la gestin de la informacin y la separacin de
responsabilidades.
La arquitectura cliente-servidor sustituye a la arquitectura monoltica en la que
no hay distribucin, tanto a nivel fsico como a nivel lgico.

Caractersticas En la arquitectura C/S el remitente de una solicitud es conocido

como cliente. Sus caractersticas son:

Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en

la comunicacin (dispositivo maestro o amo).

Espera y recibe las respuestas del servidor.
Por lo general, puede conectarse a varios servidores a la vez.
Normalmente interacta directamente con los usuarios finales mediante

una interfaz grfica de usuario.

Al contratar un servicio de redes, se debe tener en cuenta la velocidad de
conexin que le otorga al cliente y el tipo de cable que utiliza, por ejemplo:

cable de cobre ronda entre 1 ms y 50 ms.

Al receptor de la solicitud enviada por el cliente se conoce como servidor.

Diseo de Software de Arquitectura Distribuida.

Prcticamente todos los grandes sistemas informticos son en la actualidad
sistemas distribuidos. Un sistema distribuido es un sistema en el que el
procesamiento de informacin se distribuye sobre varias computadoras en vez
de estar confinado en una nica mquina. Arquitecturas de objetos distribuidos.
En este caso, no hay distincin entre servidores y clientes, y el sistema puede
ser visto como un conjunto de objetos que interaccionan cuya localizacin es
irrelevante.
No hay distincin entre un proveedor de servicios y el usuario de estos
servicios. Ambas arquitecturas (Arq. Distribuida y Arq. Cliente Servidor) se
usan ampliamente en la industria, pero la distribucin de las aplicaciones
generalmente tiene lugar dentro de una nica organizacin.
Los

sistemas

distribuidos

se

desarrollan

normalmente

utilizando

una

aproximacin orientada a objetos. Estos sistemas estn formados por partes

17

independientes pobremente integradas, cada una de las cuales pueden

interaccionar directamente con los usuarios o con otras partes del sistema.

Diseo de Software de Arquitectura de Tiempo Real.

El software de tiempo real est muy acoplado con el mundo externo, esto es, el
software de tiempo real debe responder al mbito del problema en un tiempo
dictado por el mbito del problema.
Debido a que el software de tiempo real debe operar bajo restricciones de
rendimiento

muy

rigurosas,

el

diseo

del

software

esta

conducido

frecuentemente, tanto por la arquitectura del hardware como por la del

software, por las caractersticas del sistema operativo, por los requisitos de la
aplicacin y tanto por los extras del lenguaje de programacin como prospectos
de diseo.

3.5.

Patrones de Arquitectura:

Los patrones de la arquitectura son formularios pre-confeccionados que

solucionan los problemas recurrentes de la arquitectura. Un framework (marco
de trabajo) de arquitectura o una infraestructura de arquitectura (middleware)
es un conjunto de componentes sobre los cuales pude construir un cierto tipo
de arquitectura. Muchas de las dificultades ms grandes que presenta la
18

arquitectura pueden ser resueltas en el framework o en la infraestructura,

usualmente enfocada hacia un dominio especfico: comando y control, MIS,
sistema de control y as sucesivamente.
Ejemplos de Patrones de Arquitectura
Agrupa patrones de arquitectura de acuerdo a las caractersticas de los
sistemas en los que son ms aplicables, con una categora tratando cuestiones
ms generales de la estructuracin.
La tabla las categoras presentadas en y los patrones que contienen.

Categora

Patrn

Estructura

Layers
Pipes and Filters
Blackboard

Sistemas Distribuidos

Broker

Sistemas Interactivos

Model-View-Controller
Presentation-Abstraction-Control
Reflection
Microkernel

Sistemas Adaptables

3.6.

Definicin de Vistas.

3.6.1. Consistencia entre los puntos de

vista.
Los puntos de vista son consistentes en cuanto a la viabilidad del
desarrollo del proyecto puesto que bsicamente se trata de satisfacer
las necesidades de los usuarios y proveedores, por lo cual la vista de los
desarrolladores se

basa especficamente en los requerimientos

predefinidos anteriormente.

3.6.2. Vista desarrolladores del sistema.

19

La vista lgica del sistema est comprendida en 3 paquetes principales:

Interfaz de Usuario, Lgica de Negocio y Almacenamiento de
informacin.
La Interfaz de Usuario contiene clases para cada una de las formas con
las cuales los usuarios se comuniquen con el sistema.
La lgica del Negocio contiene las clases controladoras para el manejo
de la lgica del negocio su funcin principal ser la de recibir las
peticiones de la capa Web en cuanto a las consultas de componentes y
presentar los resultados a la capa Web,
Almacenamiento de Informacin contiene las tablas que representan los
metadatos de los componentes descritos en el estndar .

Web

Vista
*
*

Usuario

Negocio

Interfaz

Controlador

Servlet

- JNDI
*

Contenedor EJB
Modelo

- JNDI

- JNDI
EJB Sesion

**

EJB Entity
*

DAO

- JDBC

Datos
*
- JDBC

20

3.7.

Vista Usuarios y Proveedores

Usuario o Proveedor

Servidor
Http

Browser

Repositorio

JDBC

21

CONCLUSIONES
En este trabajo concluimos que el arquitecto de software en su mayora de
estereotipos, es un lder que mediante patrones ser proporciona de un marco claro el
cual guiara para definir la estructura del sistema, que mediante requerimientos de va
capturando lo necesario para luego disear, despus de documentar para que ltimo
evalu el desarrollo del proyecto de software mediante feedback.
El arquitecto de software se encuentra incluido dentro de toda la rama de desarrollo de
la solucin ya que puede asistir sobre consultas o inconvenientes que pueden llegar a
darse durante la elaboracin del mismo.
En el rea de tecnologa el arquitecto de software interacta como varios modelos los
cuales organizarn la descripcin arquitectnica mediante varios componentes que
darn valor ms adelante a futuros procesos.

22

WEBGRAFA

http://www.guiaacademica.com/educacion/queestudiar/home/detalleCarrera.aspx?CARR=J9UFJ488GvQ=

http://www.pmoinformatica.com/2013/11/rol-arquitecto-software-2daparte.html

https://sg.com.mx/revista/33/el-rol-del-arquitectosoftware#.V9zs0fB9600

https://es.wikipedia.org/wiki/Arquitectura_de_software

https://www.fing.edu.uy/cpap/cursos/arquitectura-de-software

23