INSTITUTO DE EDUCACION A DISTANCIA IDEAD

UNIVERSIDAD DEL TOLIMA

INFORME UNIDAD 2

Arquitectura de Software

Presentado a:
Hernández Rengifo German

Presentado por:
Maicol Felipe Quevedo
Juan Manuel Amaya
Juan José Sierra

Ibagué-Tolima
Abril 04 del 2019
Table of Contents
Introducción.................................................................................................................................3
Justificación..................................................................................................................................3
Objetivos......................................................................................................................................4
Objetivos Generales.................................................................................................................4
Objetivos Específicos................................................................................................................4
Procesos de Arquitectura.............................................................................................................5
Etapas:..........................................................................................................................................5
Extracción:................................................................................................................................5
Generalización:.........................................................................................................................5
Reutilización:............................................................................................................................5
Estilos Arquitectónicos.................................................................................................................5
Uso de Estilos Arquitectónicos.................................................................................................6
Estilos Arquitectónicos Actuales...............................................................................................6
Arquitectura Centrada en Datos..................................................................................................6
Arquitectura De Flujo de Datos....................................................................................................7
Arquitectura de Llamada y Retorno.............................................................................................7
Modelo de vista Controlador...................................................................................................7
Arquitectura Orientada a Objetos................................................................................................8
Características:.........................................................................................................................8
Arquitectura Estratificada............................................................................................................9
TECNICAS PARA LA TOMA DE DECISIONES.................................................................................10
- Epítome (o la propia Decisión).......................................................................................10
- Justificación....................................................................................................................10
- Alcance...........................................................................................................................10
- Estado.............................................................................................................................10
- Decisiones de Alto Nivel.................................................................................................11
- Decisiones de Nivel Medio.............................................................................................11
- Decisiones de Nivel de Realización.................................................................................11
Decisiones Existentes.............................................................................................................11
Prohibiciones o Decisiones de Inexistentes............................................................................11
Decisiones de Propiedad........................................................................................................11
Decisiones Ejecutivas.............................................................................................................11
Conclusiones..............................................................................................................................13
Webgrafía...................................................................................................................................14
 Introducción
El siguiente informe da a conocer el desarrollo de la unidad 2 del curso de
arquitectura de software del programa gestión de base de datos de la
Universidad del Tolima
El material desarrollado está dividido en elementos de competencia con los
cuales se busca analizar y resolver a profundidad sus significados y exponerlos
de la manera más precisas posible a partir de ejemplos cotidianos y gráficos
que se pueden apreciar en este informe.

Justificación
El informe desarrollado abarca una parte de los temas a ver durante el
transcurso del curso de “Arquitectura de Software”, el cual significa una parte
del material a desarrollar al finalizar la materia, por ende, es importante estudiar
y evaluar los conceptos en cada unidad para de esta manera apropiarse y
entender los procesos y arquitectura del desarrollo de software.
 Objetivos
Objetivos Generales
Mostrar el desarrollo de las actividades propuestas en la unidad 2 de la materia
Arquitectura de Software para lograr entender y discutir los diferentes
componentes procesos y arquitecturas que posee el desarrollo de software

Objetivos Específicos
Facilitar la comprensión de la unidad desarrollado tanto para nuestro grupo
para las personas interesadas sobre el tema
Lograr cumplir con los objetivos y metas propuestas planteadas en la guía de
desarrollo.
Desarrollar y resolver las problemáticas respecto al tema proponiendo
soluciones efectivas.
Procesos de Arquitectura
Es un proceso que involucra una metodología, principios, guías, AS tiene como
beneficios, reutilización, mejorar calidad, reducir costos, reducir tiempos de
entrega (time-to-market).

Etapas:

Extracción:

 Análisis de requerimientos, considerando diferentes perspectivas del

sistema (cliente, usuario, programador, etc.)

 Definir componentes.

Generalización:

 Identificar componentes comunes en un dominio específico (familia de

sistemas, líneas de productos).

 Definir una colección de componentes.

Reutilización:

 Definir una librería de componentes reutilizables en el dominio.

 Nuevos sistemas utilizarán los componentes en la Librería.

Estilos Arquitectónicos
Un estilo arquitectónico determina el vocabulario de componentes y conectores
que pueden ser usados, así como un conjunto de restricciones de cómo
pueden ser combinados.
Los estilos arquitectónicos están basados en los patrones de arquitecturas que
se usen. Los estilos agrupan clases, englobando una serie de estilos
arquitectónicos que comparten características.
Generalmente los estilos proveen guías para crear una clase amplia de
arquitectura, donde los patrones se enmarcan en darle solución a problemas
más pequeños y más específicos dentro de un estilo dado.

Uso de Estilos Arquitectónicos

-Sirven para sintetizar estructuras de soluciones.

-Pocos estilos abstractos encapsulan una enorme variedad de configuraciones

concretas.

-Definen los patrones posibles de las aplicaciones.

-Permiten evaluar arquitecturas alternativas con ventajas y desventajas

conocidas ante diferentes conjuntos de requerimientos no funcionales.

Estilos Arquitectónicos Actuales

-Arquitectura centrada en datos.

-Arquitectura de flujo de datos.
-Arquitectura de llamada y retorno.
-Arquitectura Orientada a Objetos.
-Arquitectura Estratificada.

Arquitectura Centrada en Datos

En esta arquitectura, como su nombre lo indica, las decisiones de diseño están
orientadas a la centralización de los datos. En este estilo, el software accede a
un almacén centralizado de los datos para agregar, eliminar, modificar o
recuperar alguno de los datos contenidos en él.
La ventaja de este modelo consiste en la independencia de los datos, es decir,
el software debe estar construido de tal manera que si uno de sus
componentes es sustituido no se verá afectado el almacén de datos.
Arquitectura De Flujo de Datos
Esta arquitectura se centra en la transformación de los datos de entrada para
obtener los datos de salida.
Para lograr esto se utiliza los componentes del software como tuberías, estas
tuberías están interconectadas entre sí trabajando en forma independiente.
Cada tubería solo está consciente de que debe recibir los datos de cierta
manera y generar una salida para la siguiente tubería, esto significa que cada
tubería desconoce la forma en que trabajan las demás, sólo conoce que debe
recibir la otra tubería si es que están interconectadas.

Arquitectura de Llamada y Retorno

Reflejan la estructura del lenguaje de programación. Permite al diseñador del
software construir una estructura de programa relativamente fácil de modificar y
ajustar a escala. Se basan en la bien conocida abstracción de procedimientos,
funciones y métodos.
-Son utilizados en grandes sistemas de software.
-Persiguen escalabilidad y modificabilidad.

Modelo de vista Controlador

El MVC es un patrón de diseño arquitectónico de software, que sirve para
clasificar la información, la lógica del sistema y la interfaz que se le presenta al
usuario. En este tipo de arquitectura existe un sistema central o controlador que
gestiona las entradas y la salida del sistema, uno o varios modelos que se
encargan de buscar los datos e información necesaria y una interfaz que
muestra los resultados al usuario final.
Arquitectura Orientada a Objetos
Los componentes de un sistema encapsulan los datos y las operaciones que se
deben realizar para manipular los datos. La comunicación y la coordinación
entre componentes se consigue a través del paso del mensaje.
Es un estilo de arquitectura de TI que se apoya en la orientación a servicios. La
orientación a servicios es una forma de pensar en servicios, su construcción y
sus resultados. Un servicio es una representación lógica de una actividad de
negocio que tiene un resultado de negocio específico (ejemplo: comprobar el
crédito de un cliente, obtener datos de clima, consolidar reportes de
perforación)

Características:
Estar basado en el diseño de servicios que reflejan las actividades del negocio
en el mundo real, estas actividades hacen parte de los procesos de negocio de
la compañía.
Representar los servicios utilizando descripciones de negocio para asignarles
un contexto de negocio.
Tener requerimientos de infraestructura específicos y únicos para este tipo de
arquitectura, en general se recomienda el uso de estándares abiertos para la
interoperabilidad y transparencia en la ubicación de servicios.
Estar implementada de acuerdo con las condiciones específicas de la
arquitectura de TI en cada compañía.
Arquitectura Estratificada
En esta arquitectura se crea una cantidad definida de capas, cada capa tiene
una responsabilidad claramente definida. Las capas externas se orientan al uso
del sistema y las capas internas se orientan a la manipulación de la
computadora.
Dependiendo de cómo se aplique el estilo puede tener dos a más capas, de
manera tradicional se utilizan tres capas:

– La primera tiene como responsabilidad la presentación de los datos al

usuario,
– La segunda tiene como responsabilidad ejecutar la lógica de negocio, y
– La tercera tiene como responsabilidad la manipulación de los datos.
TECNICAS PARA LA TOMA DE DECISIONES
A medida que los sistemas software han ido creciendo en complejidad, se ha
hecho imprescindible la necesidad de aislar los detalles de implementación
para poder prestar atención al comportamiento e interacción de los elementos
que integran el sistema y poder diseñar sistemas que posean las propiedades
deseadas
Dentro de los atributos de una decisión de diseño arquitectónico señala los
siguientes:
- Epítome (o la propia Decisión): dentro de este atributo se realiza
una breve declaración textual de la decisión de diseño, en unas pocas
palabras o una línea. Este texto sirve para resumir las decisiones,
enumerarlas, etiquetarlas en diagramas, etc.
- Justificación: en este atributo se realiza una explicación textual del
"por qué" de la decisión, su justificación. Se debe tener cuidado de no
simplemente parafrasear o repetir información capturada en otros
atributos, sino para agregar valor.
- Alcance: algunas decisiones pueden tener un alcance limitado, en el
tiempo, en las organizaciones, o en el diseño y la implementación. Por
defecto, (si no se documenta) la decisión es universal. El alcance podría
delimitar la parte de un ciclo de vida, o una parte de la organización a la
que se aplica la decisión.
- Estado: al igual que los informes de problemas o el código, las
decisiones de diseño evolucionan de una manera que puede ser descrita
por una máquina de estado
Se pueden distinguir tres niveles de decisiones:
- Decisiones de Alto Nivel: son aquellas que afectan a todo el
producto, aunque no necesariamente son siempre las decisiones que se
debaten o se piensan más. A menudo, las personas que no están
involucradas en la realización del proyecto (Por ejemplo, los arquitectos
de gestión o de empresa) afectan mucho a estas decisiones. Se resalta
que cambiar estas decisiones suele tener un enorme impacto.
- Decisiones de Nivel Medio: las decisiones de nivel medio implican
la selección de componentes o marcos específicos, o describen cómo se
correlacionan componentes específicos entre sí de acuerdo con
patrones arquitectónicos específicos. Estas decisiones se discuten a
menudo, donde la arquitectura y el desarrollo son evaluados, cambiados
y desechados según sea necesario. Tienen un alto impacto en las
propiedades (no funcionales) del producto y son relativamente costosos
de cambiar.
- Decisiones de Nivel de Realización: las decisiones de nivel de
realización implican la estructura del código, la ubicación de
responsabilidades específicas o el uso de API específicas. Estas
decisiones son relativamente fáciles de cambiar y tienen un impacto
relativamente bajo en las propiedades del sistema.
Investigaciones concluyen que las decisiones arquitectónicas más difíciles de
tomar son las decisiones de nivel medio por las siguientes razones:
a) estas decisiones tienen un alto impacto sobre las propiedades funcionales y
no funcionales del sistema
b) cambian constantemente, especialmente en comparación con las
decisiones de alto nivel que sólo cambian cuando se rehace el sistema.
c) son costosos de cambiar debido al impacto en el sistema
Por otro lado, existen definiciones como:
Decisiones Existentes: en la implementación de sistemas ya diseñados o
implementados se encuentran decisiones existentes que satisfacen
requerimientos funcionales o requerimientos no funcionales que se capturan
para poyar otras alternativas
Prohibiciones o Decisiones de Inexistentes: es lo contrario de una
decisión existente, indicando que algún elemento no aparecerá en el diseño o
la implementación. Las decisiones de prohibición se hacen a menudo cuando
se eliminan gradualmente las posibles alternativas.
Decisiones de Propiedad: Una decisión de propiedad establece un rasgo
duradero, general o la calidad del sistema
Decisiones Ejecutivas: Estas son las decisiones que no se relacionan
directamente con los elementos de diseño o sus cualidades, sino que son
impulsadas más por el entorno empresarial (financiero) y afectan el proceso de
desarrollo (metodológico), las personas (educación y formación), la
organización y, a una amplia gama de opciones de tecnologías y herramientas.

¿Quién toma decisiones?

Toma de decisiones bajo riesgo:

Las decisiones son tomadas por lo general bajo tres condiciones importantes
como lo es la: incertidumbre y el riesgo.
El estilo de la toma de decisiones por lo general la información se recolecta,
procesa y se usa en forma de parámetro según sea el estilo de la toma de
decisiones. Y es por eso que los tomadores de decisiones son analíticos o
heurísticos.
Tomador de decisiones Heurístico: 1. Aprende actuando 2. Usa prueba y error y
valora la experiencia
Tomador de decisiones analítico: 1. Aprende mediante análisis 2. Usa
procedimientos paso a paso 3. Valora la información cuantitativa y los modelos
4. Constituye modelos matemáticos y algoritmos 5. Busca soluciones óptimas
 Conclusiones
Podemos concluir que con el siguiente informe se resaltó y estudio los temas
propuestos desarrollados en la unidad 2 de la materia “Arquitectura de
Software” esto con el fin de lograr cumplir con las metas propuestas.
Se obtuvo información valiosa al momento de estudiar el material, dando como
resultado un campo de experiencia esto para en un futuro planear y poder dar a
conocer todos los componentes que hacen parte del tema que hace parte el
presente informe.
 Webgrafía
https://www.cipydo.com/proyectos/soa-arquitectura-orientada-a-objetos.html

https://www.ingennus.com/la-arquitectura-orientada-objetos-aoo/

http://codingornot.com/mvc-modelo-vista-controlador-que-es-y-para-que-sirve/mvc-modelo-
vista-controlador

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html

https://prezi.com/gjtimc-be3c_/estilo-de-artquitectura-de-llamada-y-retorno/

https://www.monografias.com/trabajos107/introduccion-ingenieria-software-arquitectura-
software/introduccion-ingenieria-software-arquitectura-software2.shtml

https://tareasuniversitarias.com/estilos-arquitectonicos.html

http://sistemascentradosendatos.blogspot.com/2013/10/sistemas-centrados-en-datos-
repositorios.html

https://www.ecured.cu/EcuRed:Enciclopedia_cubana#Utilizaci.C3.B3n_de_los_estilos_arquite
ct.C3.B3nicos