UNIVERSIDAD AGRARIA DEL ECUADOR
CARRERA DE INGENIERÍA EN CIENCIAS DE LA COMPUTACIÓN
AUTORES:
ALVAREZ LARREA DIEGO ADRIAN
BUENAÑO KLINGER IVANNA JANETH
CONSUEGRA ARIA KENIA ALEJANDRA
CUESTA BELTRAN RICARDO IVAN
ROJAS GUERRERO STEVEN GALO
LUZARDO TATEZ ANTHONY MARTIAL
DOCENTE CÁTEDRA INTEGRADORA:
ING. JOHANA SACHEZ
PERIODO: 2021-2022
CIUDAD-ECUADOR
Capítulo 6
6.1. Cuando se describe un sistema, explique por qué es posible que
deba diseñar la arquitectura del sistema antes de completar la
especificación de requerimientos.
La razón es porque una vez determinado el diseño de la arquitectura de
software de cualquier proyecto, se puede implementar los requerimientos
funcionales y no funcionales, además los requerimientos no funcionales
dependen de la arquitectura del sistema, es decir, la forma en que dichos
componentes se organizan y comunican. Por ende, los requerimientos no
funcionales están influidos por componentes individuales de la arquitectura de
software que sin duda es la influencia dominante.
6.2. Se le pide preparar y entregar una presentación a un administrador
no técnico para justificar la contratación de un arquitecto de sistemas
para un nuevo proyecto. Escriba una lista que establezca los puntos clave
de su presentación. Por supuesto, debe explicar qué se entiende por
arquitecto de sistemas.
Lista:
1. Capacidad de trabajo con marcos para el desarrollo de arquitecturas
dejk software.
2. Conocimientos de UML, para la estructuración del proyecto a plantear.
3. Conocimientos de lenguaje de programación.
4. Conocimiento en base de datos.
5. Conocimiento de metodologías agiles de desarrollo.
6. Experiencia en diseño e implementación de arquitectura de software.
El arquitecto de sistemas, diseñan y desarrollan sistemas y aplicaciones de
software. Pueden crear software a medida para clientes o productos
orientados a consumidores, como juegos o aplicaciones.
Son responsables de la toma de decisiones de alto nivel en el proceso de
desarrollo. Deciden sobre el diseño, las medidas técnicas, las plataformas o las
normas de programación que se emplearán en el proyecto. Los arquitectos de
software tienden a supervisar y trabajar estrechamente con otros miembros de
un equipo de desarrollo, como los programadores.
6.3. Exponga por qué pueden surgir conflictos de diseño cuando se
desarrolla una arquitectura para la que tanto los requerimientos de
disponibilidad como los de seguridad son los requerimientos no
funcionales más importantes.
Inevitablemente, cuando intervienen diversas áreas en este caso (seguridad y
disponibilidad), los requerimientos entrarán en conflicto. Esto en ocasiones se
logra usando diferentes patrones arquitectónicos para distintas partes del
sistema, para encontrar y resolver conflictos de requerimientos se realiza
mediante reuniones para resolver las diferencias y estar de acuerdo con el
compromiso de los requerimientos.
6.4. Dibuje diagramas que muestren una vista conceptual y una vista de
proceso de las arquitecturas de los siguientes sistemas:
Un sistema automatizado de emisión de boletos que utilizan los
pasajeros en una estación de ferrocarril.
Vista conceptual
Vista de proceso
Un sistema de videoconferencia controlado por computadora, que
permita que los datos de video, audio y computadora sean al mismo
tiempo visibles a muchos participantes.
Vista conceptual
Vista de proceso
Un robot limpiador de pisos cuya función sea asear espacios
relativamente despejados, como corredores. El limpiador debe detectar
las paredes y otros obstáculos.
Vista conceptual
Vista de proceso
6.5. Explique por qué usted usa normalmente muchos patrones
arquitectónicos cuando diseña la arquitectura de un sistema grande.
Además de la información sobre los patrones estudiados en este capítulo,
¿qué información adicional puede serle útil al diseñar sistemas grandes?
Son necesarios en sistemas grandes porque ayudan a resolver los problemas
relacionados con el estilo arquitectónico, representa de una mejor forma la
relación entre los componentes de todo el sistema y sus pequeños módulos por
los que está compuesto. Además, provee un conjunto de subsistemas
predefinidos donde se especifican sus responsabilidades e incluyen reglas y
guías para organizar las relaciones entre ellos. Los patrones arquitectónicos
tienen un gran impacto en la base del código de estos sistemas, ya que con
mayor frecuencia afectan toda la aplicación, ya sea horizontal o verticalmente,
pues expresan un esquema organizativo estructural para sistemas de software
grandes.
6.6. Sugiera una arquitectura para un sistema (como iTunes) que se use
para vender y distribuir música por Internet. ¿Qué patrones
arquitectónicos son la base para esta arquitectura?
Sugiero la arquitectura cliente-servidor, ya que él cliente solicita varios
servicios, mientras que el servidor sería el encargado de la música. La base
para este proyecto serían los patrones arquitectónicos de capas y de
repositorio.
6.7. Especifique cómo usaría el modelo de referencia de entornos CASE
(disponibles en las páginas Web del libro), para comparar los IDE
ofrecidos por diferentes proveedores de un lenguaje de programación
como Java.
Uno de los IDE es Pycharm es uno de los más completos ya que tiene
funciones inteligentes para su productividad, tiene una interfaz personalizable
Otro de ellos es visual studio code el cual busca adaptarse a las necesidades
específicas de codificación, interfaz inteligente como resultado de sintaxis,
autocompletado y navegación de código
Oracle SQL entra en los entornos case gracias a que ofrece una gestión de
base de datos, herramienta de control de calidad revisando cada uno de los
datos, elaboración de informe
Podemos encontrar otro IDE el cual es Eclipse que cuenta con soporte de
una biblioteca basta de información, también se encarga en poder asistir
junto con poder depurar errores
6.9. Con el modelo básico de un sistema de información, como se
presentó en la figura 6.16, sugiera los componentes que puedan ser parte
de un sistema de información que permita a los usuarios consultar
información de los vuelos que llegan y salen de un aeropuerto específico
Interfaz de usuario
forma de acceso(login) Menú de consulta Datos del aeropuerto
Gestor de inf. de salida de aviones Gestor de inf. de entrada, de aviones seguridad de la información
Gestión de transacción de base de datos de aviones
6.10 ¿debe existir una profesion separada de “arquitectura de software”
cuyo papel sea trabajar de manera independiente con un cliente para
diseñar la arquitectura de un sistema de un sistema de software?
Entonces, una compañía de software aparte implementaría el sistema.
¿cuál serían las dificultades de establecer tal profesión?
Arquitecto de software. Este rol dirige el desarrollo de la arquitectura de
software del sistema, que incluye la promoción y la creación de soporte para
las decisiones técnicas clave que restringen el diseño global y la
implementación para el proyecto.
La definición de la arquitectura se trata de la introducción de la estructura,
directrices, principios y liderazgo de los aspectos técnicos de un proyecto de
software. Por lo tanto, se requiere de una figura dedicada a pensar en estos
aspectos, es decir, alguien tiene que asumir la propiedad del proceso de
definición de la arquitectura y esto es sin duda, parte de las competencias del
Arquitecto de Software.
Capítulo 9
9.1. Con el uso de la arquitectura de una casa o edificio como metáfora,
establezca comparaciones con la arquitectura del software. ¿En qué se
parecen las disciplinas de la arquitectura clásica y la del software? ¿En
qué difieren?
La arquitectura normal y la arquitectura de software se parecen porque las dos
son estilos de construcción que conllevan procesos o métodos para lograr su
objetivo final que es diseñar componentes que se adapten al cambio. Cada una
de las arquitecturas diseñan pensando en fallos.
Estas difieren en que la arquitectura normal se basa en la construcción física
de algún edificio o alguna ciudad, y la arquitectura de software son estructuras
del sistema, lo que comprende a los componentes del software, sus
propiedades externas visibles y las relaciones entre ellos.
9.2. Diga dos o tres ejemplos de aplicaciones para cada uno de los estilos
arquitectónicos mencionados en la sección 9.3.1.
Arquitectura centrada en datos: Un conjunto de tablas asociadas por
campos y tipos de datos en un sistema de gestión de base de datos.
Arquitectura por capas: una aplicación web ya que está compuesta por
una capa de presentación que es la que interactúa con el usuario, y una
capa de negociación que interfiere con el servidor y una capa de datos
que realiza la funcionalidad relacionada con el acceso a los datos.
Arquitecturas orientadas a objetos: Aplicaciones Móviles, Aplicaciones
Web
Arquitectura de flujos de datos: data were-house
Arquitecturas en capas: aplicaciones de Red y sistemas operativos.
9.3. Algunos de los estilos arquitectónicos citados en la sección 9.3.1
tienen naturaleza jerárquica, mientras que otros no. Elabore una lista de
cada tipo. ¿Cómo se implementarían los estilos arquitectónicos que no
son jerárquicos?
Arquitecturas orientadas a objetos.
Arquitecturas de llamar y regresar
Arquitecturas en capas.
Arquitecturas centradas en los datos
Arquitecturas de flujo de datos.
Lo ideal para poder implementar los estilos arquitectónicos no jerárquicos seria
poderlos combinar con los que son jerárquicos para de esta manera poder
llevar una estructura organizada y definida sobre el objetivo.
9.4. Los términos estilo arquitectónico, patrón arquitectónico y marco
(que no se estudia en este libro) surgen con frecuencia en los análisis de
la arquitectura del software. Investigue y describa en qué difiere cada uno
de ellos de los demás.
Estilo arquitectónico:
Describen una categoría del sistema que contiene; un conjunto de
componentes, que realizan una función requerida por el sistema, un conjunto
de conectores que posibilitan la comunicación, coordinación y la cooperación
entre los componentes; restricciones que definen como se puede integrar los
componentes que forman el sistema; y modelos semánticos que permiten al
diseñador entender las propiedades globales de un sistema analizar las
propiedades conocidas de sus partes constituyentes.
Los estilos arquitectónicos sirven para:
Simplifica estructuras de soluciones
Pocos estilos 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.
Patrón arquitectónico:
Es la solución general y reutilizable a un problema común en la arquitectura de
software dentro de un contexto dado. Los patrones arquitectónicos son
similares al patrón de diseño de software, pero tiene un alcance más amplio.
Entre los patrones arquitectónicos más comunes se encuentran:
Patrón de capas
Patrón de cliente – servidor
Patrón maestro -esclavo
Patrón de filtro de tubería
Patrón intermediario
Patrón de igual a igual
Patrón de bus de evento
Modelo – vista – controlador
Patrón de pizarra
Patrón de interprete
Marco de trabajo:
Definen una arquitectura adaptada a las particularidades de un determinado
dominio de aplicación. Definiendo de forma abstracta una serie de
componentes y sus interfaces estableciendo las reglas y mecanismos de
interacción entre ellos.
Suele incluirse la implementación de algunos de los componentes e incluso
varias implementaciones alternativas.
Ejemplos:
El usuario, selecciona, instancia y reutiliza los componentes del marco.
Completa la arquitectura con nuevos componentes específicos dentro de
las relaciones estructurales del marco.
Básicamente se presentan como un diseño reutilizable de todo o parte
de un sistema, representado por un conjunto de componentes abstractos
y la forma en que los componentes interactúan.
9.5. Seleccione una aplicación con la que esté familiarizado. Responda
cada una de las preguntas planteadas para el control y los datos de la
sección 9.3.3.
CONTROL
1. ¿Cómo se administra el control dentro de la arquitectura?
Se plasman en una serie de entregables: especificación de requisitos
(propósito y funciones del sitio) como:
Blueprints (diagramas o planos del sitio): los blueprints son diagramas
donde se especifican la estructura del sitio, así como los diversos
elementos que van a conformar cada área.
Wireframes (representación gráfica y conceptual del sitio, que puede
funcionar como maqueta): Hay quien dice que los wireframes deben ser
mucho más espartanos y no tener apenas diseño gráfico, pero en el
caso de Ibai Intranets, la sintonía entre el arquitecto de información y el
diseñador era tal que fue casi imposible separar concepto y diseño.
Test de usuarios sobre un prototipo: Con la estructura ya definida y con
la casi realidad que brindaban los wireframes del sitio, se hizo un
sencillo ensayo de usabilidad. La prueba se hizo sobre un prototipo que
se obtuvo dotando de interactividad (navegabilidad, en realidad) a los
wireframes que habíamos diseñado.
Resultado final: En las ejecuciones del proyecto, surgieron dudas sobre
aspectos muy puntuales, pero el hecho de haber consensuado en la
fase de diseño y en los tests de usuario la estructura de navegación
consiguió evitar problemas mayores derivados de la toma de decisiones
arbitrarias basadas en impresiones personales.
2. ¿Existe una jerarquía de control distinta?
La elección de esta herramienta se fundamentó más en factores de
arquitectura de la información, usabilidad y findability que en los meramente
tecnológicos. De hecho, Movable Type cuenta con soporte para categorías, poli
jerarquía, que resultaban clave a la hora de permitir la localización de
contenidos.
3. ¿Cuál es el papel de los componentes dentro de esta jerarquía de
control?
Buscador por relevancia configurable muy potente.
Estructuración de los contenidos en campos (metadata) que permiten su
reutilización por las diferentes páginas del sitio web.
Funciones out-of-the-box (sin necesidad de configuración, tal y como
viene) muy interesantes, como la posibilidad de incluir elementos de
ayuda a la navegación función "Ver más" (para consultar un artículo
completo), "Enviar este artículo por e- mail a un amigo", gestión
automática del archivo de artículos (por fecha, por categoría, etc.) y
elaboración automática de vínculos al artículo anterior, al posterior,
listado de los n últimos artículos.
Generación automática de salida apta para la sindicación de contenidos
(RSS, RDF) basada en XML, que contribuye a la facilidad de consulta de
novedades en el sitio.
4. ¿Cómo transfieren el control los componentes dentro del sistema?
Dentro de este sistema cada elemento realiza funciones en donde ciertos
rasgos son trasladados de uno a otro, transfiriendo ciertos dominios o controles
necesitados en su módulo los cuales están ordenados, teniendo en cuenta la
necesidad de cada uno de los elementos involucrados.
5. ¿Cómo lo comparten?
Lo comparten mediante la conexión realizada entre cada una de las partes
interrelacionadas jerárquicamente.
6. ¿Cuál es la topología del control?
Posee una topología de control centrada ya que los conocimientos y contenidos
en la organización fluyen más rápidamente hacia el exterior de la misma; ya
que tiene la arquitectura de elementos comunes a todas las páginas.
7. ¿El control está sincronizado o los componentes operan en forma
asincrónica?
Lo componentes operan de forma asincrónica, por lo que pueden disponer de
un espacio siendo posible establecer un canal de comunicación con los clientes
que les permitirá estar enterados sobre sus nuevas novedades y
actualizaciones. También se puede enviar información por email a otros sin
necesidad de que estén al mismo tiempo los dos usuarios conectados.
DATOS
1. ¿Cómo se comunican los datos entre los componentes?
Los datos en la red Telegram se comunican mediante las operaciones que los
usuarios aplican para manipularlos. La comunicación y coordinación entre los
componentes se consigue mediante la transmisión de mensajes de texto, de
voz, videos, llamadas, etc.
2. ¿El flujo de datos es continuo o los objetos de datos pasan al
sistema en forma esporádica?
El flujo de datos de los objetos en este caso suele ser por lo regular continuo ya
que los usuarios se comunican emisor con receptor a través de un flujo de
datos que surgen con eficacia, pero existen ocasiones en las cuales estos
objetos no pasan a la aplicación con frecuencia debido a la capacidad de
transmisión de la red.
3. ¿Cuál es el modo de transferencia de datos (pasan de un
componente a otro o se dispone de ellos globalmente para
compartirse entre los componentes del sistema)?
El modo de transferencia de datos de esta aplicación es de un componente a
otro ya que en el intercambio de datos de entrada se transforma en datos de
salida a través de una serie de componentes computacionales.
4. ¿Existen componentes de datos (como un pizarrón o depósito) y,
si así fuera, cuál es su papel?
Si, existe un componente de datos que cumple una función parecida a la del
pizarrón o repositorio, que consiste en almacenar datos o información de los
usuarios, en este caso por ser una red social muy utilizada por gran cantidad
de usuarios esta información se almacena en los servidores web.
5. ¿Cómo interactúan los componentes funcionales con los
componentes de datos?
Los componentes funcionales de la aplicación vendrían a ser los componentes
que realizan la interfaz con el sistema operativo del dispositivo y que trabajan
internamente con los componentes de la capa de interfaz y las capas
intermedias que proveen servicios de utilerías y funciones de software de
aplicación y todos estos componentes a su vez funcionan de manera iterativa
para visualizar la interfaz final.
6. ¿Los componentes de datos son pasivos o activos (el componente
de datos actúa activamente con otros componentes del sistema)?
Los componentes de datos de la aplicación Telegram son activos debidos que
esta aplicación interactúa o se relaciona con otras para así poder llegar con
más impacto a los clientes
7. ¿Cómo interactúan los datos y el control dentro del sistema?
En la aplicación Telegram los datos interactúan debido que en esta aplicación
puedes enviar y recibir datos con un control estrictamente limitado que tiene
este sistema para seguridad de la empresa y de los usuarios.
9.6. Investigue el ATAM (en [Kaz98]) y presente un análisis detallado de
los seis pasos presentados en la sección 9.5.1.
Escenarios de investigación: Se centra en la descripción de estilos de
arquitectura y las vistas que está pueda tener del sistema. También
realiza una recopilación y vista general de los escenarios que se tuvieron
en cuenta por los participantes del proyecto de software. De la misma
forma se identifican los riesgos, se realiza sensibilización acerca de
estos mismos con el fin de cumplir a cabalidad con los requerimientos de
calidad y seguridad del software.
Obtención de los requerimientos y restricciones, y descripción del
ambiente: en primer lugar, se organiza la interacción que se presenta
entre los actores, arquitectos y equipo de evaluación para entender
mejor la generación de la información. El proceso de evaluación genera
todo lo referente a la documentación arquitectónica. Se disminuyen los
gastos los cuales dan viabilidad al proyecto.
Descripción de los estilos o patrones de arquitectura elegidos para
abordar los escenarios y requerimientos: Trade-off sensibilización para
generar productos de calidad. Discusión del escenario a explorar para la
obtención de información. Realización de lista de cuestiones u opciones
que no habían contemplado aún dentro del desarrollo del proyecto.
Evaluación de los atributos de calidad, considerando cada atributo por
separado: Descripción de las Vistas de Arquitectura y estilos: la
arquitectura se presenta en la medida, especificando cada detalle cómo
se hace actualmente. Durante este paso, el arquitecto también identifica
la calidad y los planteamientos arquitectónicos específicos (atributos y
estilos)
Identificación de la sensibilidad de los atributos de calidad de varios
atributos arquitectónicos para un estilo de arquitectura específico:
Identificación de Riesgos / Sensibilidad / soluciones de compromiso:
como resultado de la asignación de escenarios y el análisis
subsiguiente, los grupos de riesgos, los puntos de sensibilidad, y las
compensaciones quedan documentados.
Crítica de las arquitecturas candidatas (desarrollado en el paso 3) con el
uso del análisis de sensibilidad realizado en el paso 5.
El SEI describe este enfoque, una vez determinados los puntos sensibles de la
arquitectura, la detección de puntos de negociación es simplemente la
identificación de los elementos de la arquitectura a los que atributos múltiples
son sensibles. Por ejemplo, el desempeño de una arquitectura cliente-servidor
podría ser muy sensible al número de servidores (aumenta el desempeño, en
cierto rango, con el incremento del número de servidores). Entonces, el número
de servidores es un punto de negociación con respecto de esta arquitectura.
9.8 utilice un diagrama de flujo y una narración del procesamiento para
describir un sistema basado en computadora que tenga distintas
características de transformación de flujo. Defina las fronteras del
sistema y mapee el diagrama de flujo de los datos en una arquitectura del
software con el ejemplo de la técnica descrita en la selección.
La planificación se puede considerar como el instrumento fundamental de la
dirección empresarial al abordar y responder cuestiones como el propósito, la
línea de actuación y los objetivos a conseguir ver los recursos y los puntos
relevantes para el proyecto y su implementación.
Mediante este método se miden y se rectifican las actividades planificadas.
