Auditoria II

ARQUITECTURA DE
SOFTWARE
INGENIERÍA DE SISTEMAS
 Arquitectura de Software
sfs

© Corporación Universitaria
Remington

Medellín, Colombia
Derechos Reservados ©2011
Primera edición
2021
Ingeniera de Sistemas
Piedad María Metaute Paniagua
Facultad de Ingenierías

Comité académico
Jorge Mauricio Sepúlveda Castaño
Decano de la Facultad de Ingenierías
[email protected]

David Ernesto González Parra

Director de Educación a Distancia y Virtual
[email protected]

Francisco Javier Álvarez Gómez

Coordinador CUR-Virtual
[email protected]

Edición y Montaje
Dirección de Educación a Distancia y Virtual
Equipo de diseño gráfico

www.uniremington.edu.co
[email protected]

Derechos reservados: El módulo de estudio del curso de

ARQUITECTURA DE SOFTWARE es propiedad de la Corporación
Universitaria Remington; las imágenes fueron tomadas de diferentes
fuentes que se relacionan en los derechos de autor y las citas en la
bibliografía. El contenido del módulo está protegido por las leyes de
derechos de autor que rigen al país. Este material tiene fines
educativos y no puede usarse con propósitos económicos o
comerciales. El autor(es) certificó (de manera verbal o escrita) No
haber incurrido en fraude científico, plagio o vicios de autoría; en caso
contrario eximió de toda responsabilidad a la Corporación Universitaria
Remington y se declaró como el único responsable.

Esta obra es publicada bajo la licencia Creative Commons.

Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia
 Arquitectura de Software
sfs

3
TABLA DE CONTENIDO
Pág.

1 UNIDAD 1. GENERALIZACIONES DE LA ARQUITECTURA DE SOFTWARE 8

1.1 MAPA CONCEPTUAL 8

1.2 RELACIÓN DE CONCEPTOS 8

1.3 OBJETIVO GENERAL 9

1.4 OBJETIVOS ESPECÍFICOS 9

1.5 PRUEBA INICIAL 10

1.6 TEMA 1. CONCEPTUALIZACIÓN Y CONTEXTUALIZACIÓN DE LA ARQUITECTURA DE SOFTWARE 11

1.6.1 EJERCICIO DE APRENDIZAJE 14
1.6.2 TALLER DE ENTRENAMIENTO 14

1.7 TEMA 2. PAPEL DEL ARQUITECTO DE SOFTWARE 15

1.7.1 EJERCICIO DE APRENDIZAJE 18
1.7.2 TALLER DE ENTRENAMIENTO 19

1.8 TEMA 3. CICLO DE VIDA DE LA ARQUITECTURA DE SOFTWARE 19

1.8.1 EJERCICIO DE APRENDIZAJE 23
1.8.2 TALLER DE ENTRENAMIENTO 23

1.9 TEMA 4. LA INGENIERÍA DE REQUISITOS EN LA ARQUITECTURA DE SOFTWARE 24

1.9.1 EJERCICIO DE APRENDIZAJE 27
1.9.2 TALLER DE ENTRENAMIENTO 28

1.10 TEMA 5. CARACTERÍSTICAS DE CALIDAD (ISO25000-2014) 29

1.10.1 EJERCICIO DE APRENDIZAJE 35
1.10.2 TALLER DE ENTRENAMIENTO 36

1.11 TEMA 6. RESTRICCIONES DE SOFTWARE 37

1.11.1 EJERCICIO DE APRENDIZAJE 38
1.11.2 TALLER DE ENTRENAMIENTO 38

2 UNIDAD 2. PATRONES ARQUITECTÓNICOS 40

2.1.1 MAPA CONCEPTUAL 40

2.2 RELACIÓN DE CONCEPTOS 40

2.3 OBJETIVO GENERAL 40

2.4 OBJETIVOS ESPECÍFICOS 41

 Arquitectura de Software
sfs

4
2.5 PRUEBA INICIAL 41

2.6 TEMA 1. PATRONES DE DISEÑO DE SOFTWARE Y FRAMEWORKS 41

2.6.1 EJERCICIO DE APRENDIZAJE 42
2.6.2 TALLER DE ENTRENAMIENTO 43

2.7 TEMA 2. PATRÓN CLIENTE-SERVIDOR 43

2.7.1 EJERCICIO DE APRENDIZAJE 45
2.7.2 TALLER DE ENTRENAMIENTO 45

2.8 TEMA 3 PATRÓN ARQUITECTURA POR CAPAS 46

2.8.1 EJERCICIO DE APRENDIZAJE 49
2.8.2 TALLER DE ENTRENAMIENTO 49

2.9 TEMA 4 ARQUITECTURA DE SOFTWARE MODELO-VISTA-CONTROLADOR (MVC) 49

2.9.1 EJERCICIO DE APRENDIZAJE 51
2.9.2 TALLER DE ENTRENAMIENTO 51

2.10 TEMA 5 ARQUITECTURAS ORIENTADAS A SERVICIOS 51

2.10.1 EJERCICIO DE APRENDIZAJE 55
2.10.2 TALLER DE ENTRENAMIENTO 55

2.11 TEMA 6. TENDENCIAS ACTUALES 55

3 UNIDAD 3. GESTIÓN DE LA ARQUITECTURA DE SOFTWARE 57

3.1 MAPA CONCEPTUAL 57

3.2 RELACIÓN DE CONCEPTOS 57

3.3 OBJETIVO GENERAL 58

3.4 OBJETIVOS ESPECÍFICOS 58

3.5 PRUEBA INICIAL 58

3.6 TEMA 1. DRIVER ARQUITECTÓNICOS 59

3.6.1 EJERCICIO DE APRENDIZAJE 71
3.6.2 TALLER DE ENTRENAMIENTO 71

3.7 TEMA 2. DISEÑOS ARQUITECTÓNICOS 74

3.7.1 EJERCICIO DE APRENDIZAJE 87
3.7.2 TALLER DE ENTRENAMIENTO 87

3.8 TEMA 3. DOCUMENTACIÓN DE LA ARQUITECTURA 90

3.8.1 TALLER DE ENTRENAMIENTO 97

3.9 TEMA 4. EVALUACIÓN DE LA ARQUITECTURA 98

 Arquitectura de Software
sfs

5
3.10 TEMA 5. IMPLEMENTACIÓN DE LA ARQUITECTURA 99

4 PISTAS DE APRENDIZAJE 125

5 GLOSARIO 127

6 BIBLIOGRAFÍA 129
 Arquitectura de Software
sfs

PROPÓSITO GENERAL
ARQUITECTURA DE
SOFTWARE

Con el desarrollo del módulo, se pretende dar bases que permitan la elaboración de
propuestas relacionadas con el diseño arquitectónico para una necesidad real, en la cual
se puedan aplicar, técnicas, patrones, herramientas de diseño, donde se visualicen
soluciones arquitectónicas viables, antes de la construcción del producto de software.
 Arquitectura de Software
sfs

ARQUITECTURA DE
SOFTWARE
a

OBJETIVO GENERAL

Diseñar arquitecturas de software, teniendo en cuenta las necesidades del cliente, métodos
y patrones arquitectónicos, así como las tendencias actuales de la arquitectura de software,
buscando calidad en el software que se desea construir de acuerdo con las expectativas
requeridas.

OBJETIVOS ESPECÍFICOS
➢ Identificar generalidades de la arquitectura de software, en relación con el papel del
arquitecto, ciclo de vida de la arquitectura y los componentes del Driver Arquitectónico.
➢ Identificar los componentes de algunos patrones de diseño arquitectónico, así como sus
ventajas y desventajas.
➢ Analizar cada una de las etapas del ciclo de vida de la arquitectura, así como las
herramientas y elementos que componen los drivers arquitectónicos, los diseños, la
documentación, la evaluación y la comunicación de la arquitectura del software.

UNIDAD 1 UNIDAD 2 UNIDA 3

Generalizaciones de la Gestión de la
Patrones Arquitectónicos
Arquitectura de Software Arquitectura de Software
 Arquitectura de Software
sfs

8
1 UNIDAD 1. GENERALIZACIONES DE LA ARQUITECTURA
DE SOFTWARE
1.1 MAPA CONCEPTUAL

Fuente: elaboración propia

1.2 RELACIÓN DE CONCEPTOS

• Arquitectura de Software: Corresponde a guías generales que, basadas en los requisitos
del software, las características de calidad y las restricciones se diseñan con el fin de
orientar el proceso de ingeniería de software, en relación con su estructura física, lógica y
dinámica.

• Características de calidad del software: Son atributos que deberá cumplir el software
como por ejemplo de seguridad, usabilidad, eficiencia, buscando con ello cumplir con
requisitos de calidad.

• Ciclo de vida: Son fases que se deben tener en cuenta para la realización de procesos,
donde integrados constituyen un producto o un servicio.
 Arquitectura de Software
sfs

9
• Desarrollo de software: Consiste en la construcción de un producto de software, basado
en los requisitos funcionales y no funcionales.

• Driver Arquitectónicos: Corresponde a la primera fase del ciclo de vida de la arquitectura

de software, la cual se construye basada en los requisitos funcionales del software, las
características de calidad que se le desee aplicar al software y las restricciones del mismo.

• Patrones de diseño: Es un esquema o base para el diseño, al cual se le adiciona una serie
de elementos que integrados buscan solucionar una necesidad.

• Requisitos de software: Son necesidades del cliente traducidas a una especificación de

software con el fin de buscar el desarrollo del software.

• Restricciones del software: Corresponde a limitaciones del software basadas en las

necesidades reales, teniendo en cuenta lo que debe hacer y hasta donde lo debe hacer.

1.3 OBJETIVO GENERAL

➢ Identificar generalidades de la arquitectura de software, en relación con el papel del
arquitecto, ciclo de vida de la arquitectura y los componentes del driver arquitectónico,
teniendo mayor claridad sobre los requerimientos de la arquitectura a la cual se le
pretende la realización del diseño.

1.4 OBJETIVOS ESPECÍFICOS

➢ Identificar los aspectos generales de la contextualización de la arquitectura de software,
como aporte a la ingeniería de software.

➢ Diferenciar las principales características que debe tener el Arquitecto de Software

➢ Identificar las principales diferencias entre el ciclo de vida de la arquitectura de software

y el ciclo de vida de la ingeniería de software.

➢ Analizar la importancia que tiene la ingeniería de requisitos en la arquitectura de software

➢ Interpretar la importancia de las características de calidad en los drivers arquitectónicos.

➢ Identificar el aporte de las restricciones del software para el diseño arquitectónico.

 Arquitectura de Software
sfs

10
1.5 PRUEBA INICIAL
Ubicar el número del concepto, en el paréntesis del significado que corresponda. Ver tabla 01.
Conceptualización General sobe Arquitectura de Software.

Tabla 01. Conceptualización General sobre Arquitectura de Software.

Nro Concepto Nro Significado

Arquitectura de Requerimientos, diseño, documentación, evaluación,

1 ( )
Software implementación.

Consiste en traducir los requerimientos del cliente en

Arquitecto de
2 ( ) aquello que se debe desarrollar para cumplir con las
Software
diferentes funcionalidades del software.

Patrón Arquitectónico conformado por tres elementos

Patrón
3 ( ) principales (almacenamientos, reglas del negocio
arquitectónico
codificadas, interfaz de usuario).

Fases para el
Lenguaje de Modelamiento Unificado, aplicable a todo
diseño de una
4 ( ) el ciclo para la elaboración de un producto
arquitectura de
informático.
software.

Conjunto de patrones que proporcionan un marco de

5 ISO 25000 ( ) referencia necesario para guiar la construcción de un
software.

Es un tipo de diagrama UML, que muestra las

Requisitos de
6 ( ) condiciones físicas y lógicas para la instalación de un
software
producto de software.
 Arquitectura de Software
sfs

11
Persona encargada de pensar todos los aspectos de la
arquitectura, de todas las directrices, principios y
7 MVC ( )
desarrollo de los aspectos técnicos de un proyecto de
software.

Consiste en un esquema de organización estructural

8 UML ( ) esencial para un sistema de software, que consta de
subsistemas, sus responsabilidades e interrelaciones.

Estándar que se encarga de dar pautas sobre la calidad

9 SCRUM ( )
de un producto de software.

Diagrama de
10 ( ) Metodología ágil para el desarrollo de software.
despliegue

1.6 TEMA 1. CONCEPTUALIZACIÓN Y CONTEXTUALIZACIÓN DE

LA ARQUITECTURA DE SOFTWARE
El concepto de arquitectura de software se refiere a la estructuración del sistema que,
idealmente, se crea en etapas tempranas del desarrollo, con el fin de satisfacer ciertos
requerimientos clave para el sistema. Esta estructuración representa un diseño de alto nivel del
sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño,
seguridad, modificabilidad), y servir como guía en el desarrollo.

De acuerdo con el Software Engineering Institute (SEI), la Arquitectura de Software se refiere a

“las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma
externa y las relaciones que existen entre ellos.” Los elementos pueden ser entidades que existen
en tiempo de ejecución (objetos, hilos (subdivisión de tareas), entidades lógicas que existen en
tiempo de desarrollo (clases, componentes) y entidades físicas (nodos, directorios). Las relaciones
entre elementos dependen de propiedades visibles (o públicas) de los elementos, quedando
ocultos los detalles de implementación. La arquitectura está compuesta por distintas estructuras.

El Diseño Arquitectónico, es una etapa intermedia en el ciclo de vida del software y se ubica
seguida de la Ingeniería de Requisitos, antes de los diseños del software. Es así como estos diseños
 Arquitectura de Software
sfs

12
arquitectónicos generan beneficios importantes tanto para quienes elaboran el software como
para quienes lo requieren.

• Algunos Beneficios del Diseño Arquitectónico antes de construir el software

Entre algunos beneficios que genera el diseño arquitectónico se encuentran que este sirve
de guía, facilita la intervención del código, presenta claridad tanto para usuarios
informáticos como para usuarios no informáticos, minimiza el riesgo ya que de antemano
se ha considerado varios aspectos que ayuda a clarificar posibles inconvenientes que se
pueden presentar en el desarrollo, visualizando su impacto y de suceder el abordaje del
riesgo. De igual forma la arquitectura previa al desarrollo permite definir el alcance de la
aplicación, siendo útil además para aumentar la rentabilidad ya que disminuye con
reprocesos los que normalmente están relacionados con el aumento en el consumo de
recursos. A continuación, se amplía un poco más.

• La Arquitectura como guía

No es lo mismo trabajar aplicando una guía que ya fue analizada y validada, que realizar
un producto o un proceso utilizando la improvisación. Un ejemplo que se puede abordar
para realizar un comparativo puede ser un paseo familiar improvisado y otro planeado,
donde el improvisado tiene más riesgo de que el tiempo no se utilice de forma adecuada,
los costos para visitar lugares pueden ser más altos, los lugares no estén disponibles, entre
otros aspectos. En el caso del paseo planeado, ya se conocen los lugares a visitar, el tiempo
en cada lugar, el costo, el número de días programado, entre otros. En ese caso se
recomienda que antes de construir el software se elabore el diseño de la arquitectura.

• Facilita la depuración de código

La arquitectura orienta la forma como se organizan los elementos a codificar y la forma

como se comunican estos, facilitando la detección de errores y su posterior corrección,
evitando así utilizar más recursos de los requeridos.

• Facilita que tanto los informáticos como los usuarios finales estén informados

Una buena arquitectura, da claridad sobre la forma como se estructurará todos los
componentes del software, desde la parte específica del programa hasta la parte física
que se requerirá para su funcionamiento, dando información suficiente de acuerdo al
interés, donde al usuario final le interesará aspectos más externos como funcionalidad,
 Arquitectura de Software
sfs

13
máquinas requeridas, entre otras, mientras que a los usuarios informáticos les interesará
estructuración interna del programa y una visión clara sobre los recursos para su
implementación.

• Reduce el riesgo

Permite tener una visión más amplia sobre la proyección de recursos en el tiempo, como
por ejemplo la adaptabilidad que deberá tener el software ante un cambio de tecnología,
cambio de reglas del negocio, nuevas legislaciones gubernamentales, entre otras,
ayudando así para que el software siga vigente ante determinados ajustes.

• Define el alcance de programa

La arquitectura define los límites a los cuales puede llegar el sistema, sin ningún
inconveniente, como por ejemplo el nivel de seguridad, de rendimiento, disponibilidad,
fiabilidad, interoperabilidad, mantenibilidad, entre otros, siempre teniendo en cuenta la
calidad tanto en los requisitos funcionales como en los requisitos no funcionales.

• Aumento de la rentabilidad

Para el cliente es importante que el software cumpla con sus necesidades, pero de igual
forma que su precio sea asequible y para ello la arquitectura a través de su diseño muestra
la infraestructura tecnológica requerida para cubrir las expectativas (Servidores, servicios,
equipos de escritorio, dispositivos móviles, así como el tipo de base de datos, Sistemas
operativos, entre otros.

Es así como una buena arquitectura de software permite realizar mejores programas, de forma
más rápida, utilizando los costos adecuados y mayor seguridad en lo que se construye. Ver imagen
01. Algunos Beneficios del Diseño Arquitectónico antes de construir el software.

Imagen 01. Algunos Beneficios del Diseño Arquitectónico antes de construir el software
 Arquitectura de Software
sfs

14

Fuente: elaboración propia

➢ Video: ¿QUÉ ES ARQUITECTURA DE SOFTWARE?

➢ ” Ver Video”: https://www.youtube.com/watch?v=7ukajubprdE&t=28s

1.6.1 EJERCICIO DE APRENDIZAJE

Según el vídeo. Escriba todas las definiciones dadas de lo que es Arquitectura de Software.

1.6.2 TALLER DE ENTRENAMIENTO

1) Consultar mínimo cuatro autores diferentes (guardar apellidos del autor, nombre, año del
documento, nombre del documento, fuente de consulta).
• Arquitectura de software. (importancia, aplicabilidad, ventajas para la
construcción de software).
• Riesgos a nivel de la arquitectura de software.
2) Realizar un ensayo que contenga las siguientes partes:
• Título
• Introducción (no se escribe la palabra introducción, se desarrolla. Es un aporte
personal)
• Desarrollo (no se escribe la palabra desarrollo, se desarrolla escribiéndose el
aporte de cada autor, con el respectivo aporte de cada uno de ustedes)
 Arquitectura de Software
sfs

15
• Conclusión (no se escribe la palabra conclusión, se desarrolla. Es un aporte
personal)
• Referentes.
Nota: debe contener una página completa en letra Arial, tamaño 12.

TIPS
Una buena arquitectura de software define el alcance del programa,
ofrece pautas claras para la construcción del software, reduce el
riesgo, facilita la comunicación y aumenta la rentabilidad.

1.7 TEMA 2. PAPEL DEL ARQUITECTO DE SOFTWARE

Según Velasco, Cervantes y Castro, (2016). Las actividades del ciclo de desarrollo son
responsabilidad del rol del arquitecto de software, y esta función puede ser cubierta por uno o
más individuos (en cuyo caso sería un equipo de arquitectura). Aunque de manera un tanto
simplista, este arquitecto debe ser visto como un líder técnico cuya tarea principal es tomar
decisiones de diseño pertinentes, a efecto de satisfacer los drivers arquitectónicos y demás
requerimientos del sistema (debe tener idealmente un buen conocimiento del dominio del
problema).

El Arquitecto de Software, juega un papel muy importante en la construcción de un producto de

software, donde este deberá tener conocimientos en programación, herramientas y
metodologías técnicas con excelente liderazgo, ya que deberá cumplir entre otras con las
siguientes funciones. Ver imagen 02. Arquitecto de Software.
 Arquitectura de Software
sfs

16
Imagen 02. Arquitecto de Software

Fuente: https://jucaripo.com/wp-content/uploads/2019/05/arquitectura-software.jpg

• Gestión de los requisitos no funcionales y definición de la Arquitectura de Software

Es función del Arquitecto de Software, el análisis sobre las características de calidad que
deberá tenerse en cuenta en el software, siendo importante que ese tipo de requisitos
puedan ser medibles, alcanzables y comprobables y de igual forma deberá quedar claro la
prioridad de los atributos como por ejemplo si la seguridad es más importante que el
rendimiento, si la usabilidad es más importante que la escalabilidad, pero teniendo en
cuenta todos los que se requieran para que el software tenga calidad.

• Selección de la Tecnología

La selección de la tecnología es uno de los riesgos que debe correr el Arquitecto de

Software, ya que deberá tener claro el tipo de tecnología requerida, la compatibilidad e
interoperabilidad con el sistema, los costos, la forma de negociación con el proveedor, la
proyección de la tecnología, el ambiente de ejecución, entre otros aspectos de los cuales
deberá hacerse responsable.

• Mejora continua de la Arquitectura

 Arquitectura de Software
sfs

17
El Arquitecto deberá tener mentalidad abierta, con la capacidad de realizar ajustes
significativos en el caso que se requiera, todo ello basado en proceso de evaluación y
retroalimentación que en definitiva deberá satisfacer las necesidades de los clientes, tanto
en su funcionalidad como en su calidad.

• Facilitador

El arquitecto deberá ser un facilitador en el sentido que servirá de apoyo tanto al equipo
de desarrollo como a equipos de otras áreas como por ejemplo los de seguridad
informática, los de base de datos, los de gobierno TI y todas aquellas que de una u otra
forma se relacionen con la arquitectura de software.

• Líder y Formador

Deberá estar en capacidad de trabajar de forma colaborativa y cooperativa en lo que tiene

que ver con la parte de formación especialmente en la parte técnica y de integración,
teniendo alto conocimiento en todo lo que tiene que ver con los sistemas informáticos.

• Aseguramiento de la Calidad

Deberá tener amplios conocimientos en modelos, normas, metodologías, patrones para

la fundamentación teórica, que aparte de la experiencia en el ramo y el conocimiento de
herramientas de automatización, el análisis de código fuente, junto con las buenas
prácticas le permitirán la realización de grandes aportes para lograr calidad en el software.
Ver imagen 03. Algunas de las funciones del Arquitecto de Software.
 Arquitectura de Software
sfs

18
Imagen 03. Algunas de las funciones del Arquitecto de Software

Fuente: elaboración propia

➢ Video: Actividades que hace un ARQUITECTO DE SOFTWARE - Introducción a la arquitectura

➢ ” Ver Video”: https://www.youtube.com/watch?v=rWh7RtVJzhA

1.7.1 EJERCICIO DE APRENDIZAJE

De acuerdo con el vídeo y al módulo. Realizar un listado sobre las diferentes actividades y
funciones que debe realizar un buen Arquitecto de Software.
 Arquitectura de Software
sfs

19
1.7.2 TALLER DE ENTRENAMIENTO
Teniendo en cuenta la información del ejercicio de aprendizaje anterior. Elaborar un mapa
conceptual, utilizando una herramienta de software como por ejemplo Cmaptools. El mapa
conceptual debe quedar muy claro y concreto. Consultar normas para realizar un mapa
conceptual.

TIPS
El Arquitecto de Software, deberá ser un líder, con gran capacidad de
integrar equipos de trabajo y amplios conocimientos administrativos y
técnicos en temáticas relacionadas con la tecnología informática.

1.8 TEMA 3. CICLO DE VIDA DE LA ARQUITECTURA DE

SOFTWARE
La arquitectura de software, al igual que la ingeniería de software posee un ciclo de vida el cual
busca aportar elementos importantes que le permitan al arquitecto guiarse para diseñar las
arquitecturas requeridas. Los componentes del ciclo de vida en mención son: requerimientos de
la arquitectura, el diseño, la documentación, la evaluación y la implementación.

Siendo importante tener en cuenta que la arquitectura de software se fundamenta en los

requisitos del software, los atributos de calidad y las restricciones para con esta información
aportar a la construcción del producto informático. Ver imagen 04. Ciclo de vida de la Arquitectura
de Software.

Imagen 04. Ciclo de vida de la Arquitectura de Software

Fuente: elaboración propia

 Arquitectura de Software
sfs

20
A continuación, se realiza descripción de cada una de las fases del ciclo de vida de la arquitectura
de software.

• Requerimientos

En el contexto de la ingeniería de software, la ingeniería de requerimientos es la disciplina

que engloba las actividades relacionadas con la obtención, análisis, documentación y
validación de estos. Según definición tomada de del libro Software Requirements (Wiegers,
2013), Requerimiento es una especificación que describe alguna funcionalidad, atributo o
factor de calidad de un sistema de software. Puede describir también algún aspecto que
restringe la forma en que se construye ese sistema.)

Para la arquitectura de Software, la etapa de requerimientos está conformada por los

siguientes elementos:

• La captura, documentación y priorización de los requisitos especificados por la

Ingeniería de Software, donde la arquitectura toma de las especificaciones los
Requisitos Funcionales primarios.

• Los atributos de calidad, corresponde a los requisitos no funcionales que deberán ser
medibles, alcanzables y comprobables, de acuerdo con las funcionalidades que se
requiera en el software.

• Las restricciones, se relacionan con la limitación que tendrá el software en cuanto a

funcionalidad, equipos, tiempos, rendimiento, reglas del negocio, entre otros.

Driver Arquitectónicos

Los Driver Arquitectónicos, corresponden al conjunto de los requisitos funcionales, los atributos
de calidad y las restricciones. A continuación, se ejemplifica la conformación de los drivers. Ver
imagen 05. Conformación Driver Arquitectónicos.
 Arquitectura de Software
sfs

21
Imagen 05. Conformación Driver Arquitectónicos

Fuente: elaboración propia

• Diseño

La etapa de diseño se fundamenta en los drivers arquitectónicos, constituyéndose en la

parte central de la arquitectura. En esta se definen las estructuras fundamentales
soportadas en patrones de diseño, tácticas de diseño, metodologías y herramientas
tecnológicas, las que son elegidas de acuerdo con la necesidad del software a construir.

• Documentación

La documentación de la arquitectura cumple un papel muy importante en la comunicación

de los involucrados en el diseño, facilitando el entendimiento de los diferentes diseños,
sus diagramas, interacción entre componentes, especificaciones y demás información que
permita fácilmente la interpretación de lo que se desea mostrar. Para ello la arquitectura
presenta metodologías que indican el proceso para la realización de la documentación.

• Evaluación

Corresponde a la etapa que se encarga de la revisión de todo el proceso de diseño y

documentación de la arquitectura, buscando detectar problemas e inconsistencias, así
como posibles riesgos que puedan afectar el cumplimiento de los diferentes requisitos del
 Arquitectura de Software
sfs

22
software, antes de iniciar la codificación, lo que permite realizar ajustes que, de ser
detectados en otras etapas, generaría sobre costos y reproceso. Aunque la evaluación
realmente se puede evidenciar cuando el software se encuentra en producción.

• Implementación

Consiste en entregar el diseño arquitectónico a la fase de diseño de la ingeniería de

software, para que a través de este se construyan los diferentes artefactos, módulo,
componentes que permitirá a través de las herramientas propias de la ingeniería de
software basado en el diseño de software la consolidación de un producto totalmente
funcional y que cumpla con cada uno de los requisitos del cliente, bajo los parámetros de
calidad requeridos.

La arquitectura de software se elabora con los fundamentos del proceso de la ingeniería

de software, donde la arquitectura toma como insumo los requisitos funcionales, los no
funcionales, además de las restricciones que deberá tener el software. Realiza su proceso
(diseño, documentación y evaluación de la arquitectura) y devuelve a la ingeniería de
software, dicho diseño arquitectónico, que será utilizado para construir el software. Ver
imagen 06. Ciclo de la arquitectura de Software asociado al ciclo de vida del software.

Imagen 06. Ciclo de la arquitectura de Software asociado al ciclo de vida del software

Fuente: elaboración propia.

 Arquitectura de Software
sfs

23
➢ Video: 35 COSAS QUE NO SABÍAS SOBRE ARQUITECTURA DE SOFTWARE
➢ ” Ver Video”: https://www.youtube.com/watch?v=HJIG_sLZJd4

1.8.1 EJERCICIO DE APRENDIZAJE

Consulta:

• En qué consiste el principio SOLID

• En qué consiste el principio GRASP

1.8.2 TALLER DE ENTRENAMIENTO

Diligencia en siguiente cuadro, ubicando en forma de ítems las características de los principios
SOLID y GRASP. Realizar una conclusión para ambos principios. Ver tabla 02. Principios SOLID Y
GRASP.

Tabla 02. Principios SOLID Y GRASP.

Principio SOLID Principio GRASP

Conclusión
 Arquitectura de Software
sfs

24

TIPS
Antes de realizar un diseño arquitectónico, es necesario tener claro
los requisitos funcionales del software, los atributos de calidad que
debe cumplir, así como sus restricciones.

1.9 TEMA 4. LA INGENIERÍA DE REQUISITOS EN LA

ARQUITECTURA DE SOFTWARE
En el contexto de la ingeniería de software, la ingeniería de requerimientos es la disciplina que
engloba las actividades relacionadas con la obtención, análisis, documentación y validación de
estos. Según definición tomada de del libro Software Requirements (Wiegers, 2013),
Requerimiento es una especificación que describe alguna funcionalidad, atributo o factor de
calidad de un sistema de software. Puede describir también algún aspecto que restringe la forma
en que se construye ese sistema.

Es así como la ingeniería de requisitos en la arquitectura de software se enfoca en el estudio de

la captura, documentación y priorización de requisitos, los atributos de calidad y las
restricciones, donde todo ello recibe el nombre de Driver Arquitectónicos.

Para la ingeniería de software, los requerimientos pueden partir de una necesidad, una idea, un
reto o una oportunidad de negocio que requiera ser sistematizada a través de medios
informáticos, donde un cliente y/o usuario real o proyectado (por los creadores de software),
tiene determinada necesidad de software, la que es transmitida al equipo de desarrollo, el cual
analiza los requerimientos, los convierte en requisitos de software plasmándolo en documentos
que reciben el nombre de Especificación, donde además se incorpora los requisitos no
funcionales (requisitos de calidad que se espera que tenga el software), así como sus restricciones
o limitaciones tanto funcionales, tiempos de entrega del producto y los costos en los cuales se
puede incurrir para su elaboración. Ver imagen 07. Problema y Solución Informática.
 Arquitectura de Software
sfs

25
Imagen 07. Problema y Solución Informática

Fuente: Elaboración propia.

Abordaje de los requerimientos y requisitos

• Desde el lado del cliente

Cuando se habla de cliente, se hace alusión a aquella persona natural o jurídica que paga
por el producto informático, es así como las necesidades normalmente están alineadas a
una misión, visión o expectativas, bajo reglas o lineamientos con sus respectiva
limitaciones o restricciones que pueden ser de índole procedimental o a nivel de recursos.
Para la arquitectura de software se deberá crear un documento, donde se clarifique la
visión y alcance que tendrá el producto.

• Desde el lado del usuario final

El usuario final será aquella persona o sistema que utilizará el software, donde no
necesariamente es el que paga por su elaboración. Se tiene en cuenta los requerimientos
del usuario, así como los atributos de calidad que deberá aplicársele al producto. Para la
arquitectura de software se deberá crear un documento, donde se clarifique los
requerimientos de usuario y los atributos o características de calidad.

• Desde el equipo de desarrollo

El equipo de desarrollo se conforma por todos aquellos perfiles que de alguna u otra forma
contribuyen con la creación del producto de software (Arquitecto, programadores,
diseñadores, analistas…), los que se encargarán de tomar los requerimientos de usuario y
sacar los requisitos del sistema, los requisitos funcionales detallados, elaborar las
 Arquitectura de Software
sfs

26
interfaces externas y analizar las restricciones. Para la arquitectura de software se deberá
crear un documento, donde se especifique los requisitos del software. Ver imagen 08.
Abordaje de los requerimientos y requisitos.

Imagen 08. Abordaje de los requerimientos y requisitos

Fuente: elaboración propia.

Ubicando un ejemplo de acuerdo con el nivel de abstracción, con relación a los interesados, el
documento de visión y alcance deberá evidenciar puntualmente los objetivos que se esperan
cumplir. Desde el lado del usuario final los requerimientos y atributos de calidad se deberán
evidenciar a través del uso de herramientas de ingeniería de software como por ejemplo casos
de uso, historias de usuario o cualquier otra herramienta apta para su interpretación que
posteriormente se pueda plasmar en etapas más avanzadas para su desarrollo. Ver imagen 09.
Ejemplo de Requerimientos y Requisitos e imagen 10. Herramientas para requerimientos de
usuario
 Arquitectura de Software
sfs

27
Imagen 09. Requerimientos y Requisitos

Fuente: elaboración propia.

Imagen 10. Herramientas para requerimientos de usuario

• Contiene: nombre del caso de uso, • Especificaciones cortas escritas

actores involucrados, objetivos de en una o dos frases utilizando el
negocio relacionados, lenguaje del usuario final.
precondiciones y postcondiciones,
así como descripciones de los
Los casos
flujos dede uso
interacciones principales,
alternativas y de error.
Representación visual en
forma de elipse en el
diagrama de casos de
uso, incluyen una Las historias de usuario
descripción textual que
detalla la secuencia de
interacciones entre el
sistema y los actores.

Fuente: elaboración propia

➢ Video: REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

➢ ” Ver Video”: https://www.youtube.com/watch?v=tF88eNhNSb4

1.9.1 EJERCICIO DE APRENDIZAJE

Observar el vídeo.
 Arquitectura de Software
sfs

28
1.9.2 TALLER DE ENTRENAMIENTO
Marca una X, según corresponda (si el Requisito es Funcional (RF) o si es Requisito No Funcional
(RNF)). Ver tabla 03. Requisitos Funcionales y No Funcionales.

Tabla 03. Requisitos Funcionales y No Funcionales

Señalar
Nro Requisitos
con una
X
Registro de clientes RF RNF

1 Manejo de usuario y contraseña

2 Informe de facturación

3 Mil transacciones por minuto

4 Facilidad para aprender sin necesidad de manual de usuario

5 Procesamiento ágil y funcional

6 Interoperabilidad con otros sistemas

7 Fácil detección de errores al realizar interacción el usuario

8 Matrículas en línea

9 Compra de productos Online

10 Informe de ventas en el último semestre

TIPS
De una buena especificación de los Requisitos Funcionales y los
Requisitos No Funcionales, dependerá que la Arquitectura de
Software se soporte sobre bases firmes.
 Arquitectura de Software
sfs

29
1.10 TEMA 5. CARACTERÍSTICAS DE CALIDAD (ISO25000-2014)
Las características o atributos de calidad forman parte importante en el diseño de la arquitectura
de software, ya que su relevancia apunta hacia la satisfacción de los objetivos del negocio del
sistema, es decir, su importancia para el cliente.

Las características de calidad están representadas por los requisitos no funcionales como son:
Adecuación funcional, eficiencia en el desempeño, compatibilidad, usabilidad, fiabilidad,
seguridad, mantenibilidad, portabilidad. Todo ello con sus respectivas sub-características que
son elegidas de acuerdo con la necesidad que se requiera implementar en el software.

Para la Arquitectura de Software, su relevancia radica en la satisfacción de los objetivos del

negocio del sistema, es decir, su importancia para el cliente, así como la complejidad técnica que
representa su implementación. Ver imagen11. Características de Calidad según ISO25000.

Imagen 11. Características de Calidad según ISO25000.

Fuente: elaboración propia.

 Arquitectura de Software
sfs

30
Cada característica se divide en varias sub-características o sub-atributos de calidad, que en caso
de elegirse para el software algunas de ellas, deberá evidenciarse la forma en que puedan ser
medibles, evidenciables para cumplir con los requisitos no funcionales requeridos. Ver imágenes
de sub-características de calidad ISO 25000.

Sub Características de Calidad según ISO25000

• Adecuación Funcional

Representa la capacidad del producto software para proporcionar funciones que

satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en las
condiciones especificadas. Esta característica se subdivide a su vez en las siguientes sub-
características. Ver imagen12. Sub característica de calidad Adecuación Funcional.

Imagen12. Sub característica de calidad Adecuación Funcional

Fuente: elaboración propia.

• Eficiencia de desempeño

Esta característica representa el desempeño relativo a la cantidad de recursos utilizados

bajo determinadas condiciones. Esta característica se subdivide a su vez en las siguientes
subcaracterísticas. Ver imagen13. Sub característica de calidad Eficiencia de Desempeño.

Fuente: elaboración propia.

 Arquitectura de Software
sfs

31
• Compatibilidad

Capacidad de dos o más sistemas o componentes para intercambiar información y/o llevar a
cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software. Esta
característica se subdivide a su vez en las siguientes subcaracterísticas. Ver imagen14. Sub
característica de calidad Compatibilidad.

Imagen14. Sub característica de calidad Compatibilidad

Fuente: elaboración propia.

• Usabilidad

Capacidad del producto software para ser entendido, aprendido, usado y resultar atractivo para
el usuario, cuando se usa bajo determinadas condiciones. Esta característica se subdivide a su
vez en las siguientes sub-características. Ver imagen15. Sub característica de calidad Usabilidad.

Imagen15. Sub característica de calidad Usabilidad

Fuente: elaboración propia.

 Arquitectura de Software
sfs

32
• Fiabilidad

Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando

se usa bajo unas condiciones y periodo de tiempo determinados. Esta característica se subdivide
a su vez en las siguientes sub-características. Ver la imagen16. Sub característica de calidad
Fiabilidad.

Imagen16. Sub característica de calidad Fiabilidad

Fuente: elaboración propia.

• Seguridad

Capacidad de protección de la información y los datos de manera que personas o sistemas no

autorizados no puedan leerlos o modificarlos. Esta característica se subdivide a su vez en las
siguientes sub características. Ver imagen17. Sub característica de calidad Seguridad.

Imagen17. Sub característica de calidad Seguridad

Fuente: elaboración propia

 Arquitectura de Software
sfs

33

Fuente: elaboración propia

• Mantenibilidad

Esta característica representa la capacidad del producto software para ser modificado efectiva
y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica
se subdivide a su vez en las siguientes sub-características. Ver imagen18. Sub característica de
calidad Mantenibilidad

Imagen18. Sub característica de calidad Mantenibilidad

Fuente: elaboración propia

• Portabilidad
 Arquitectura de Software
sfs

34
Capacidad del producto o componente de ser transferido de forma efectiva y eficiente de un
entorno hardware, software, operacional o de utilización a otro. Esta característica se subdivide
a su vez en las siguientes sub-características. Ver imagen19. Sub característica de Portabilidad.

Imagen19. Sub característica de calidad Portabilidad

Fuente: elaboración propia

Las diferentes validaciones que se proponga para la evaluación de los requisitos no funcionales
dependerán del tipo de software, de sus requisitos funcionales, de las necesidades del cliente
y demás factores relacionados con las reglas del negocio, el alcance del software y todo aquello
que tenga relación con su especificidad. Teniendo como base esas necesidades, el arquitecto
procederá a evidenciar esos cuestionamientos en el diseño arquitectónico. En la siguiente imagen
se plantean algunos cuestionamientos. Ver imagen20. Algunos cuestionamientos para medir los
requisitos no funcionales.

Imagen20. Algunos cuestionamientos para medir los requisitos no funcionales

 Arquitectura de Software
sfs

35

➢ Video: REQUISITOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE

➢ ” Ver Video”: https://www.youtube.com/watch?v=eul8XkUUqXY

1.10.1 EJERCICIO DE APRENDIZAJE

De acuerdo con el anterior video. Responder:

• ¿Qué importancia tienen los requisitos no funcionales o atributos de calidad los productos
de software?
 Arquitectura de Software
sfs

36
1.10.2 TALLER DE ENTRENAMIENTO
Analizar y responder bajo tu punto de vista las preguntas planteadas, relacionadas con los
Requisitos No Funcionales aplicables a los sistemas informáticos. Ver tabla 04. Aplicabilidad de
los atributos de calidad.

Tabla 04. Aplicabilidad de los atributos de calidad.

Responder los
Característica Preguntas cuestionamientos planteados,
desde tu punto de vista.

Adecuación ¿Qué pasaría si el sistema no arroja los

funcional resultados con la precisión requerida?

¿Qué opciones se pueden plantear en

Eficiencia de
caso de que el software requiera más
desempeño
recursos de los planteados?

¿Qué posibles soluciones se podrían

plantear en caso de que el sistema no
Compatibilidad
tenga compatibilidad con otro sistema
requerido?

¿Cuál sería el impacto si el sistema no

tiene todos los requisitos de usabilidad
Usabilidad
para personas con alguna
discapacidad?

¿Qué impacto podría tener la perdida

Fiabilidad de información en caso de una caída del
sistema?

¿Qué pasaría si no se tuviera un log de

Seguridad seguimiento de alguna transacción en
el sistema?
 Arquitectura de Software
sfs

37
¿Qué impacto se tendría si el
Mantenibilidad desempeño del software baja por
alguna modificación a éste?

¿Qué problema tendría el hecho de que

Portabilidad el software solo funcione sobre algunos
sistemas operativos?

TIPS
Las características o atributos de calidad equivalen a los requisitos no
funcionales (RNF) del software, el usuario no los solicita, pero el
experto (a) informático los debe incorporar.

1.11 TEMA 6. RESTRICCIONES DE SOFTWARE

Las restricciones al igual que los requisitos funcionales y las características de calidad, entran a
formar parte de los drivers arquitectónicos, donde las restricciones se orientan hacia la
restricciones técnicas (Métodos de diseño o implementación, productos de hardware, lenguajes
de programación, personal de desarrollo, entre otras) y las restricciones administrativas
(Proceso de desarrollo del sistema, costo y tiempo de desarrollo, equipo de desarrollo, elección
de productos de hardware en el cual se implantará el sistema, incorporación de componentes
comerciales, entre otras). Ver imagen21. Algunas restricciones Técnicas y Administrativas.

Imagen21. Algunas Restricciones Técnicas y Administrativas

• RESTRICCIONES TÉCNICAS
✓ Métodos de diseño o implementación utilizado.
✓ Productos de hardware disponibles.
✓ Lenguajes de programación disponible.
✓ Personal de desarrollo disponible.
 Arquitectura de Software
sfs

38
• RESTRICCIONES ADMINISTRATIVAS
✓ Proceso de desarrollo del sistema requerido.
✓ Costo y tiempo de desarrollo.
✓ Equipo de desarrollo.
✓ Elección de productos de desarrollo.
✓ Hardware en el cual se implantará el sistema.
✓ Incorporación de componentes comerciales.

Tanto los requisitos funcionales, como los no funcionales y las restricciones son el insumo para la
conformación del DRIVER ARQUITECTÓNICO, a utilizarse en la primera etapa de la Arquitectura
de Software que corresponde a la etapa de los Requerimientos de la Arquitectura.

➢ Video: RESTRICCIONES Y PREMISAS

➢ ” Ver Video”: https://www.youtube.com/watch?v=0xnEHgx-3lk

1.11.1 EJERCICIO DE APRENDIZAJE

Defina los siguientes conceptos en relación con el software:

1. ¿Qué es un requerimiento?

2. ¿Qué es un requisito funcional?

3. ¿Qué es un requisito no funcional?

4. ¿Qué es una restricción?

1.11.2 TALLER DE ENTRENAMIENTO

Marca con una X, si el ítem es verdadero o falso. Ver Tabla 05. Prueba de Entrenamiento.
 Arquitectura de Software
sfs

39
Tabla 05. Prueba de Entrenamiento

Señalar con una

X (V o F)
Nro ÍTEM
V F
Los requisitos no funcionales, son solicitados directamente por el
1
cliente o usuario.
Un requerimiento tiene que ver con una solicitud que hace el cliente o
2
usuario.
3 Las restricciones son condicionamientos para realizar o no un proceso.
Los drivers arquitectónicos están compuestos por los requisitos
4
funcionales, los requisitos no funcionales y las restricciones.
El perfil de arquitecto de software no requiere que la persona sea
5
experta en temas de Ingeniería de Software.
Una buena arquitectura de software minimiza reproceso en la
6
construcción del software y puede generar mayor rentabilidad.
Para el diseño de la arquitectura de software, no necesariamente se
7
deben tener los drivers arquitectónicos.
Las características de calidad no son lo mismo que los requisitos no
8
funcionales.
9 La seguridad es una de las características de la calidad de software.
La garantía de la calidad del software tiene que ver tanto con el
10
cumplimiento de requisitos funcionales como con los no funcionales.

TIPS
Tanto los requisitos funcionales, como los no funcionales y las
restricciones son el insumo para la conformación del DRIVER
ARQUITECTÓNICO, a utilizarse en la primera etapa de la
Arquitectura de Software que corresponde a la etapa de los
Requerimientos de la Arquitectura.
 Arquitectura de Software

40
2 UNIDAD 2. PATRONES ARQUITECTÓNICOS
2.1.1 MAPA CONCEPTUAL

2.2 RELACIÓN DE CONCEPTOS

• Patrón Cliente-Servidor: Es un modelo para el diseño de software, donde el servidor es el
proveedor de recursos y servicios y el cliente es quien demanda eso recursos y servicios,
a través de peticiones.
• Patrón por Capas: Es un modelo que permite realizar una división del sistema, buscando
con ello que el diseño del software quede más entendible y fácil de manejar.
• Patrón Orientado a Servicios: SOA, acrónimo de Service-Oriented Architectures, que
permite integrar el software con sistemas ya existentes.
• Patrones de arquitectura de software: Equivale a una solución general que es reutilizable
para problemas similares. En la arquitectura de software se puede tomar un patrón o
realizar una mezcla de varios de ellos y dar solución de acuerdo con las necesidades del
cliente.

2.3 OBJETIVO GENERAL

➢ Identificar los componentes de algunos patrones de diseño arquitectónico, así como sus
ventajas y desventajas.
 Arquitectura de Software

41
2.4 OBJETIVOS ESPECÍFICOS
➢ Analizar la importancia de diferentes patrones arquitectónicos para el diseño de la
arquitectura de software.
➢ Diferenciar aspectos importantes de la arquitectura Cliente-Servidor, para la utilización en
diseños arquitectónicos.
➢ Identificar los principales aportes de la arquitectura por Capas para diseños
arquitectónicos
➢ Identificar los principales aportes de la arquitectura Modelo Vista y Controlador para los
diseños arquitectónicos.
➢ Diferenciar los principales componentes de la arquitectura orientada a servicios.

2.5 PRUEBA INICIAL

Responder las siguientes preguntas:

1) ¿Para qué sirven los patrones arquitectónicos de software?

2) ¿Qué diferencia existe entre patrón y estilo arquitectónicos?

3) ¿Qué aporte le hace la arquitectura de software al ciclo de vida del software?

4) ¿Qué aporte le hace los drivers arquitectónicos al diseño de la arquitectura?

5) ¿Por qué es importante la arquitectura de software, en los procesos de calidad del

software?

2.6 TEMA 1. PATRONES DE DISEÑO DE SOFTWARE Y

FRAMEWORKS
En 1994 apareció el primer catálogo de patrones de diseño que, hasta la fecha, sigue siendo una
obra de referencia, y que se llama Patrones de diseño: elementos de software orientado a objetos
reutilizables (Gamma, Helm, Johnson y Vlissides, 1994). Este libro, cuyos autores son conocidos
como el “GoF”, o “Gang of Four” (banda de los cuatro) documenta 23 patrones enfocados a
problemas de diseño de granularidad relativamente fina.
 Arquitectura de Software

42
Los patrones son soluciones conceptuales. Esto significa que no pueden usarse de forma directa,
sino que deben ser “instanciados”, es decir, adecuados al contexto y al problema específico que
se busca resolver.

Tanto patrones como tácticas son conceptos de diseño abstractos que deben adecuarse al
problema particular y ser implementados posteriormente en el código. Existen, sin embargo,
otros conceptos de diseño, los cuales no son abstractos, sino que son código concreto: los
frameworks (marcos de trabajo). Estos son elementos reutilizables de software que proveen
funcionalidad genérica y se enfocan en la resolución de un problema específico, como puede ser
la construcción de interfaces de usuario o la persistencia de objetos en una base de datos
relacional. Frameworks, patrones y tácticas están relacionados pues, en general, los primeros
implementan una variedad de patrones y de tácticas. Un ejemplo de ello son los frameworks
enfocados en la creación de interfaces de usuario que, frecuentemente, implementan el patrón
llamado Modelo-Vista-Controlador. Ver imagen22. Frameworks Arquitectónicos.

Imagen22. Framework Arquitectónico

➢ Video: ¿QUÉ ES UN FRAMEWORK?

➢ ” Ver Video”: https://www.youtube.com/watch?v=TALDLVNs2ss

2.6.1 EJERCICIO DE APRENDIZAJE

Visualizar el anterior vídeo.
 Arquitectura de Software

43
2.6.2 TALLER DE ENTRENAMIENTO
Resolver las siguientes preguntas:

• Qué es un frameworks

• Qué diferencia existe entre un frameworks y una librería

• Consulte y explique dos frameworks

TIPS
La reutilización de código corresponde a una técnica que se puede
utilizar, sólo se debe verificar si los componentes a utilizar son de uso
libre o pago.

2.7 TEMA 2. PATRÓN CLIENTE-SERVIDOR

En la arquitectura el patrón cliente-servidor, es uno de los modelos que tiene un alto nivel de
utilización, el cual consiste en que las tareas son repartidas de tal forma que los proveedores de
recursos o servicios, llamados servidores, y los demandantes, llamados clientes, realizan tareas
específicas, es así como un cliente realiza peticiones a otro programa y el servidor es quien genera
las respuestas a las peticiones.

Componentes de un modelo Cliente-Servidor

Permite integrar diferentes componentes en una sola estructura arquitectónica. Ellos son:

• Presentación/Captación de la información.

• Procesos.

• Almacenamiento de la información.

• Puestos de trabajo

• Comunicaciones.
 Arquitectura de Software

44
Ver imagen23. Patrón Arquitectónico Cliente-Servidor

Imagen23. Patrón Arquitectónico Cliente-Servidor

Características de la arquitectura cliente servidor

➢ Tanto el cliente como el servidor pueden realizar tareas en conjunto, pero de igual forma
tienen independencia par realizar tareas de forma individual.

➢ Pueden compartir la misma plataforma o estar ubicados en plataformas individuales.

➢ Tanto la plataforma del cliente como la del servidor, podrá sufrir modificaciones,
actualizaciones, sin que el usuario final se de cuenta de lo que se está realizando,
permitiendo aplicar una de las características de calidad como es la escalabilidad.

➢ La utilización de datos y recursos de la arquitectura cliente servidor, se hace fácil ya que

tanto hardware como software se encuentran debidamente sincronizados.

➢ Los centros de trabajo (cliente) poseen su propio software de operación, accediendo al

servidor cuando requiera de datos o recursos que se encuentran centralizados. Ejemplo
servidor de datos, servidor de impresión, entre otros).

Entre algunas ventajas y desventajas se tienen:

 Arquitectura de Software

45
Ventajas

• Puede ser escalable fácilmente.

• La arquitectura Cliente-Servidor ha evolucionado con el tiempo incorporándose cada día
nuevas tecnologías que han permitido tener el modelo vigente.
• Centralización del control: los accesos, recursos y la integridad de los datos son
controlados por el servidor (Facilidad para actualizar datos)
• Se facilita el mantenimiento, tanto al lado del cliente como al lado del servidor, ya que
existen de igual forma independencia.

Desventajas

• Puede generarse lentitud en las respuestas esperadas, cuando los recursos instalados no
soporten altos tráficos de procesos e información.
• Cuando el servidor sale de funcionamiento por cualquier motivo, afecta significativamente
al cliente, ya que los servicios no estarán disponibles.
• Los servidores normalmente requieren software y hardware de alta capacidad para
soportar los servicios de los clientes, generando respuestas oportunas, lo que aumenta los
costos de implementación y mantenimiento.
• No existe interacción directa entre clientes, ya que existe de por medio un servidor, que
se encarga de recibir y entregar procesos e información a los clientes.

➢ Video: CLIENTE-SERVIDOR
➢ ” Ver Video”: https://www.youtube.com/watch?v=SPmbxvvT7Aw

2.7.1 EJERCICIO DE APRENDIZAJE

Observar el vídeo sugerido

2.7.2 TALLER DE ENTRENAMIENTO

En la Arquitectura de Software, qué importancia tiene el patrón Cliente-Servidor. Justifica la
respuesta.
 Arquitectura de Software

46

TIPS
El patrón Cliente-Servidor, permite optimizar procesos y recursos.

2.8 TEMA 3 PATRÓN ARQUITECTURA POR CAPAS

La arquitectura por capas, se encarga de organizar el sistema por niveles que son la capa de
presentación o interfaz del usuario (formularios y los controles que se encuentran en los
formularios, entre otros), la capa de negocio (objetos que van a ser manejados o utilizados por
toda la aplicación), la capa de datos (base de datos, clases, procedimientos almacenados, entre
otros), donde cada una cumple funciones específicas pero interrelacionadas buscando que el
conjunto de ellas cumplan con los requisitos del cliente.

La arquitectura basada en capas se fundamenta en el ROL en relación con la interacción que tiene
la capa con otras capas, de igual forma cada capa posee RESPONSABILIDADES donde se deberá
tener claridad sobre la funcionalidad que deberá ser desarrollada.

Componentes de la Arquitectura por capas

• Capa de presentación o interfaz de usuario

Es la capa más cercana al usuario final, está compuesta por las vistas de usuario o
formularios y sus respectivos controles, donde esta capa debe estar en capacidad de
identificar los tipos de datos y mensajes que se pueden devolver para la interfaz de
usuario.

• Capa de la lógica del negocio

Está compuesta por los diferentes componentes de la aplicación, entre ellos clases,
objetos, métodos, interrelaciones. Es la parte central del programa, ya que hace posible
que los datos que ingresan a través de la capa de presentación sean procesados de
acuerdo con las condiciones del negocio y entrelazados con los almacenamientos de
datos.

• Capa de Acceso a Datos

 Arquitectura de Software

47
Es la capa que permite la interacción con las bases de datos, utilizando componentes,
procedimientos almacenados que buscan la inserción y extracción de los datos. Permite
la comunicación de la lógica del negocio con la base de datos. Ver imagen24. Patrón
Arquitectónico Capas.

Imagen24. Patrón Arquitectónico Capas

Fuente: https://arevalomaria.files.wordpress.com/2011/03/componentes.png

Características de la arquitectura por capas

• Cada capa posee una responsabilidad clara, con interacción entre una capa y otra para
intercambiar información.
 Arquitectura de Software

48
• Los recursos físicos donde se ubican las capas (computadora), puede darse en la misma
máquina o distribuir capas en diferentes máquinas, estando en capacidad de compartir
información.

• Para que exista comunicación entre un componente y otros de diferentes capas, se debe
realizar una excelente definición que obedece a funcionamientos claramente definidos.

• Las funcionalidades se definen claramente entre capas, donde cada capa asigna
información y abstracción a la capa superior, es así como la vista o capa de presentación
asigna responsabilidades a la capa de la lógica del negocio y esta a su vez a la de datos.

Entre algunas ventajas y desventajas se tienen:

Ventajas

• Reutilización de capas: Facilita la reutilización de componentes, tanto dentro de mismo

software, con en otros programas.
• Facilita la estandarización: Permite estandarización, integrando procesos y componentes
dándole un plus propio al programa.
• Aplicación de cambios: Se puede realizar ajustes o cambios, sin que otras capas del sistema
se vean afectadas.
• Permite ampliar su rendimiento: al distribuir las capas en varios sistemas físicos,
aumentando la escalabilidad, el rendimiento y la tolerancia a fallos como atributos de
calidad que deben tener los sistemas informáticos.

Desventajas

• En ocasiones se deben aplicar cambios a varias capas, generado por un cambio que afecta
a varios componentes, ya sea entre la misma capa u otras.
• Pueden existir redundancias entre varias capas, lo que puede generar ineficiencias en
funcionalidad.
• Dificultad de diseñar correctamente partes muy pequeñas de las capas (granularidad)

➢ Video: ARQUITECTURA POR CAPAS

➢ ” Ver Video”: https://www.youtube.com/watch?v=uFDT-NHPe-s
 Arquitectura de Software

49
➢ Video: ARQUITECTURA DEL SOFTWARE MULTICAPA
➢ ” Ver Video”: https://www.youtube.com/watch?v=kHvxX1E9vIU

2.8.1 EJERCICIO DE APRENDIZAJE

Observar los siguientes vídeos sugerido

2.8.2 TALLER DE ENTRENAMIENTO

En la Arquitectura de Software, qué importancia tiene el patrón por Capas. Justifica la respuesta.

TIPS
El patrón por Capas permite estructuras el software en partes donde
se establecen límites, pero de igual forma permite realizar
integraciones para conformar un todo funcional.

2.9 TEMA 4 ARQUITECTURA DE SOFTWARE MODELO-VISTA-

CONTROLADOR (MVC)
Es un estilo arquitectónico de software que separa los datos, las vistas de usuario o interfaz y la
parte lógica del programa en diferentes componentes, cada uno con su funcionalidad bien
definida. Es un modelo que ha alcanzado un nivel de madurez importante, siendo utilizado en
múltiples lenguajes y plataformas.

Elementos de MVC

• Modelo

El modelo hace alusión a los datos del dominio (entidades que sirven para almacenar y
recuperar información del sistema), representado por aquellos elementos que permiten
el almacenamiento y manejo de datos, tanto las estructuras de base de datos como
estructuras tipo clases y la implementación de reglas, acciones y restricciones
relacionadas con las entidades del dominio.
 Arquitectura de Software

50
• Vista

Corresponde a la interfaz de usuario, representada en las vistas y los diferentes controles

que permiten la interacción con el sistema, donde la vista se encarga de representar de
forma fácil y entendible los datos e información acorde a los requisitos del sistema.

Las vistas deberán ser diseñadas, teniendo en cuenta los parámetros de usabilidad
facilitándole al usuario final su entendimiento de forma natural, ya que los elementos de
interacción constituyen la puerta de entrada del producto de software.

• Controlador

El controlador, permite integrar los Datos, con la Vista, ya que sirve de intermediario al
traducir las necesidades del usuario en información que, de acuerdo con la solicitud,
realiza el proceso y para ello utiliza los datos acorde a las reglas del negocio. El controlador
se convierte en el Coordinador entre la vista y los datos. Ver imagen25. Patrón
Arquitectura MVC

Imagen25. Patrón Arquitectónico MVC

Ventajas

• Facilidad de escalabilidad y mantenimiento, ya que se tiene claridad sobre la funcionalidad

de cada elemento del MVC.
• Es un modelo fácil de entender, ya que cada elemento está bien definido.
 Arquitectura de Software

51
• La aplicación de pruebas unitarias se facilita, debido a que cada componente tiene una
funcionalidad específica.
• Se puede reutilizar los componentes, ya sea dentro del mismo programa u otros
programas.
• Se adapta fácilmente a equipos de desarrollo y a diversas tecnologías.

Desventajas

• Se requiere mayor dedicación de tiempo, debido al mayor número de componentes que

se deben construir.
• Se requiere la construcción inicial de una arquitectura que permita comunicar, notificar y
actualizar las tareas de los diferentes módulos de la aplicación, basándose en las clases
modelo, vista, controlador.
• Se dificulta su aplicación con leguajes que no siguen el patrón orientado a objetos.

➢ Video: PATRÓN ARQUITECTÓNICO MODELO VISTA CONTROLADOR

➢ ” Ver Video”: https://www.youtube.com/watch?v=TQ1cQ9Wd1DE

2.9.1 EJERCICIO DE APRENDIZAJE

Observar el vídeo sugerido

2.9.2 TALLER DE ENTRENAMIENTO

En la Arquitectura de Software, qué importancia tiene el patrón por MVC. Justifica la respuesta.

2.10 TEMA 5 ARQUITECTURAS ORIENTADAS A SERVICIOS

La Arquitectura Orientada a Servicios (SOA), se fundamenta en la construcción de software que
utiliza servicios disponibles y los integra a sus necesidades. Sus principales características tienen
que ver con la flexibilidad de reutilización, su versatilidad al permitir compartir servicios con otros
negocios y su optimización de trabajo y recursos. SOA, se centra en la reusabilidad de recursos,
la interoperabilidad entre aplicaciones, entre otras características de calidad aumentando la
eficiencia, disminuyendo la inversión.

Elementos de la Arquitectura Orientada a Servicios

 Arquitectura de Software

52
Según UAH (2015), presenta un modelo donde puede observarse, un esquema dividido en 2
zonas; una que abarca el ámbito funcional de la arquitectura y otra vinculada a la calidad de
servicio. Ver imagen26. Elementos de la Arquitectura Orientada a Servicios.

Imagen26. Elementos de la Arquitectura Orientada a Servicios

El autor describe brevemente los elementos representados en la figura anterior:

Funciones

• Transporte: es el mecanismo utilizado para llevar las demandas de servicio desde un

consumidor de servicio hacia un proveedor de servicio, y las respuestas desde el
proveedor hacia el consumidor.
• Protocolo de comunicación de servicios: es un mecanismo acordado a través del cual un
proveedor de servicios y un consumidor de servicios comunican qué está siendo solicitado
y qué está siendo respondido.
• Descripción de servicio: es un esquema acordado para describir qué es el servicio, cómo
debe invocarse, y qué datos requiere el servicio para invocarse con éxito.
• Servicio: describe un servicio actual que está disponible para utilizar.
• Procesos de Negocio: es una colección de servicios, invocados en una secuencia particular
con un conjunto específico de reglas, para satisfacer un requisito de negocio.
 Arquitectura de Software

53
• Registro de Servicios: es un repositorio de descripciones de servicios y datos que pueden
utilizar los proveedores de servicios para publicar sus servicios, así como los consumidores
de servicios para descubrir o hallar servicios disponibles.

Calidad de Servicio

• Política: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio

hace el servicio disponible para consumidores.
• Seguridad: es un conjunto de reglas que pueden aplicarse para la identificación,
autorización y control de acceso a consumidores de servicios.
• Transacciones: es el conjunto de atributos que podrían aplicarse a un grupo de servicios
para entregar un resultado consistente.
• Administración: es el conjunto de atributos que podrían aplicarse para manejar los
servicios proporcionados o consumidos.

Ver imagen27. Patrón orientado a servicios (SOA).

Funcionamiento de la Arquitectura SOA Arquitectura Orientado a Servicios

Fuente: Fuente:
https://ingenieriadelsoftwareuah2015.files.wor https://magmdf2014.files.wordpress.com/
dpress.com/2015/03/soa-11.jpg 2014/12/soablog5.png

Características

• Deberá ofrecer altos niveles de comunicación

• Deberá facilitar la Integración de Servicios
 Arquitectura de Software

54
• Deberá satisfacer requisitos de calidad como rendimiento, fiabilidad, disponibilidad,
seguridad.
• Permite agilizar los procesos para que puedan hacer negocios de manera más eficiente.
• Proporciona espacios para que los clientes se adapten fácilmente al cambio y avance
tecnológico.

Motiva hacia la implementación de nuevas estrategias, acordes con las necesidades económicas
y sociales.

Algunas ventajas y desventajas son

Ventajas

• Su flexibilidad, que permite la reutilización.

• Su versatilidad, que hace posible que los servicios puedan ser consumidos por los clientes
en aplicaciones o procesos de negocio distintos.
• Sus posibilidades, que optimizan el trabajo con datos y su coordinación.
• Aumenta la eficiencia en los procesos.
• Amortiza la inversión realizada en sistemas.
• Reduce costes de mantenimiento.
• Fomenta la innovación orientada al desarrollo de servicios.
• Simplifica el diseño, optimizando la capacidad de organización
• Es fácil de testear
• El monitoreo se puede hacer de forma precisa
• Facilita la interoperabilidad
• Simplifica la reutilización
• Permite definir la seguridad de una forma más concreta.

Desventajas

• Para su implementación requiere ajustarse a estándares de comunicación, siguiendo los

protocolos establecidos para acceder al o los servicios.
• No es práctico para aplicaciones con alto flujo de datos
 Arquitectura de Software

55
• Exige altos niveles de conocimiento del negocio, para seleccionar procesos, clasificarlos y
agrupar los que son comunes, con el fin de formar capas de servicios para ser accedidas
en el momento que se requieran.
• La actualización de un servicio a nivel de interfaz, codificación, entre otros requiere de
evaluaciones donde se evidencie su impacto, poniendo a prueba el buen diseño del
servicio.

➢ Video: ARQUITECTURA DE ORIENTADA A SERVICOS

➢ ” Ver Video”: https://www.youtube.com/watch?v=3fRmah7o9GU

➢ Video: ARQUITECTURA DE MICROSERVICIO

➢ ” Ver Video”: https://www.youtube.com/watch?v=QxqkmOC-eQY

2.10.1 EJERCICIO DE APRENDIZAJE

Observar el vídeo sugerido

2.10.2 TALLER DE ENTRENAMIENTO

En la Arquitectura de Software, qué importancia tiene el patrón SOA. Justifica la respuesta.

TIPS
El patrón Orientado a Servicios (SOA), favorece el uso de servicios de
terceros que pueden ser integrados a programas propios

2.11 TEMA 6. TENDENCIAS ACTUALES

El software evoluciona rápidamente y lo que hoy es tendencia, el día de mañana queda obsoleto,
es así como el ingeniero de sistemas se ve abocado a revisar cada día nuevos métodos, prácticas,
modelos, tendencias que le permitan innovar y proponer de acuerdo con sus expectativas.
 Arquitectura de Software

56
Este tema se orienta hacia la indagación de tendencias y el análisis que se debe realizar para
abordar patrones que se estén proponiendo para mejorar o revaluar los ya existentes.

No es difícil reconocer la relación causal entre la inversión en agilidad técnica y cualquier número
de potenciales beneficios estratégicos y operacionales. Por ejemplo, una arquitectura moderna,
flexible, proporciona el fundamento que se necesita para respaldar el desarrollo y despliegue
rápidos de soluciones que, a su vez, permiten innovación y crecimiento. En un panorama
competitivo que continuamente es redibujado por la disrupción tecnológica, el tiempo-al-
mercado puede ser un diferenciador del mercado. A la luz de esto, financiar consistentemente
iniciativas de modernización de la pila de tecnología – al tiempo que se permanece consciente de
los intercambios – puede bien valer la pena la inversión.

los arquitectos de iniciativa son responsables por el diseño de un proyecto o de una iniciativa de-
cara-al-negocio. Trabajan con unidades de negocio para ayudarles a definir y dar forma a sus
necesidades de tecnología para acondicionarlas con las metas de la empresa ágil general,
utilizando capacidades entregadas a través de los servicios de la empresa.

Video: Super Tendencias en Arquitectura y Desarrollo de Software en el 2020Super Tendencias

en Arquitectura y Desarrollo de Software en el 2020

➢ Video: SUPER TENDENCIAS EN ARQUITECTURA Y DESARROLLO DE SOFTWARE EN EL 2020

➢ ” Ver Video”: https://www.youtube.com/watch?v=xnxzSmBzRXs

TIPS
Lo que hoy se constituye como última tecnología, mañana estará
obsoleto
 Arquitectura de Software

57
3 UNIDAD 3. GESTIÓN DE LA ARQUITECTURA DE
SOFTWARE
3.1 MAPA CONCEPTUAL

Fuente: elaboración propia

3.2 RELACIÓN DE CONCEPTOS

• Diseño Físico: Establece el detalle de los componentes y configuraciones como por
ejemplo las máquinas y su distribución.
• Diseño Lógico: Se encarga de refinar organizar y detallar la especificación de como se
quiere que funciones el sistema.
• Diseño de Comportamiento: Muestra la interacción de los diferentes componentes, a
través del flujo de información que va evolucionando a lo largo del proceso.
• Guía de Usuario: Son instrucciones del cómo funcionan determinados componentes.
• Manual de procedimientos: Indica el paso a paso para desarrollar cualquier actividad.
• Políticas: Se refiere a reglas, protocolos que son definidos para realizar los procesos.
• Restricciones técnicas: Indica los recursos, métodos, materiales y la forma como se debe
operar colocando límites para su manejo.
 Arquitectura de Software

58
3.3 OBJETIVO GENERAL
➢ Analizar cada una de las etapas del ciclo de vida de la arquitectura, así como las
herramientas y elementos que componen los drivers arquitectónicos, los diseños, la
documentación, la evaluación y la comunicación de la arquitectura del software.

3.4 OBJETIVOS ESPECÍFICOS

➢ Integrar los elementos para la conformación de los Driver Arquitectónicos, como insumo
para el diseño de la arquitectura de software.

➢ Realizar el diseño arquitectónico para un sistema de software.

➢ Identificar algunos métodos de documentación, para la arquitectura de software

➢ Identificar algunas herramientas que permiten la evaluación de diseños arquitectónicos.

➢ Clarificar la importancia de la comunicación de la arquitectura a los expertos informáticos

y al cliente.

3.5 PRUEBA INICIAL

Ubicar una X, en caso de que la afirmación sea Verdadera o falsa. Ver tabla 06. Diseño lógico, de
comportamiento y físico.

Tabla 06. Diseño lógico, de comportamiento y físico.

Señalar con una

X (V o F)
Nro ÍTEM
V F
El Diseño de Comportamiento se encarga de refinar organizar y
1
detallar la especificación de cómo se quiere que funciones el sistema.
Diseño Lógico muestra la interacción de los diferentes componentes, a
2 través del flujo de información que va evolucionando a lo largo del
proceso.
 Arquitectura de Software

59
El Diseño Físico tiene que ver con mostrar el detalle de los
3 componentes y configuraciones como por ejemplo las máquinas y su
distribución.
El diseño del software y su codificación son etapas que se desarrollan
4
antes de realizar los diseños arquitectónicos.
Una buena arquitectura del software permite detectar errores antes
5
de construir el producto informático.

3.6 TEMA 1. DRIVER ARQUITECTÓNICOS

Los drivers arquitectónicos corresponden a la primera etapa del diseño arquitectónico y permiten
realizar una especificación de los principales casos de uso (requerimientos más importantes o
difíciles de comprender) que se utilizarán en el diseño, así como las características o atributos de
calidad requeridos para el sistema, teniendo en cuenta que estos corresponden a los RNF
(requisitos no funcionales) y las restricciones que se deberán tener en cuenta en relación con
restricciones técnicas o administrativas.

Requerimientos del cliente

Objetivo: Identificar los drivers arquitectónicos de acuerdo con la situación planteada, en cuanto
a la visión y alcance del negocio y los requerimientos de la arquitectura, donde se desea mejorar
cada día el servicio de tanqueo, en las diferentes estaciones de servicio de Texaco en Envigado y
sabaneta.

Situación: En las estaciones de gasolina Texaco del municipio de Envigado y del municipio de
Sabaneta (municipios cercanos a Medellín), se requiere un software que maneje la información
de los diferentes tanqueos que se realizan (autoservicio), donde los vehículos pueden ser de
varios tipos (moto, automóvil, escalera, bus, entre otros). Cuando el vehículo llega por primera
vez, deberá ser registrado por el conductor, donde un lector tomará la placa del vehículo y en una
pantalla táctil de forma ágil, se podrá ubicar información para terminar el registro, como por
 Arquitectura de Software

60
ejemplo la identificación del dueño del vehículo, la cual será sincronizada y verificada
automáticamente con las bases de datos donde se encuentre matriculado dicho vehículo
(Secretaría de Tránsito), si el vehículo ya ha sido registrado en cualquier estación de Texaco
Envigado y Sabaneta, bastará con pasar por el punto donde se encuentra el lector de placa para
iniciar su proceso de abastecimiento de combustible.

Para el proceso de abastecimiento de combustible, se podrá elegir un tanqueo por valor o por
cantidad de galones, ya sea corriente, extra, diésel, entre otras opciones, donde el software
deberá sincronizarse con el servicio de pago, a través de tarjeta débito o crédito, NO permitirá el
pago en efectivo.

De igual forma el sistema deberá enviar al dueño del vehículo un mensaje de texto al teléfono
móvil, donde se le informe lugar del tanqueo, fecha, hora, tipo de combustible, cantidad.

El sistema deberá permitir los siguientes informes para el Gerente (listado de tanqueos diarios,
mensuales, vehículos que más utilizan el servicio, recibo para el conductor).

Quienes manejan el sistema de software, son el Conductor y el Gerente.

Es importante tener en cuenta que dicha aplicación deberá ser web y móvil, y deberá contar con
servidor (es), servicios, dispositivos, aplicaciones, entre otras que garanticen calidad en el
producto y servicio.

Componentes del Driver Arquitectónico

Para desarrollar el ejemplo, se trabajará con los siguientes puntos, aclarando que esto dependerá
del formato que utilice cada Arquitecto, donde en todo caso se deberá ver reflejado los elementos
del Driver (Requisitos Funcionales, Requisitos No Funcionales y Restricciones), lo que será la base
para la segunda etapa correspondiente al Diseño de la Arquitectura.

• Visión y alcance del negocio

✓ Introducción (Visión y alcance del sistema)
✓ Contexto del negocio (antecedentes, descripción del problema).
✓ Objetivos del negocio en relación con lo que se espera del sistema, visión de la
solución, donde se elabora tabla con (id y descripción del objetivo del negocio).
✓ Características del sistema, utilizando tabla (Id, descripción, prioridad, id del
objetivo del negocio asociado).
 Arquitectura de Software

61
✓ Alcance del sistema.
✓ Contexto del sistema (tabla de interesados y diagrama de contexto)
✓ Entorno de operación, en relación con máquinas, aplicaciones, dispositivos,
sistemas externos, Sistemas Operativos, entre otros.
✓ Información adicional en caso de existir (tiempo de entrega tanto para
funcionalidad como para otros servicios, avances…)

• Requerimientos de la arquitectura
✓ Requisitos Funcionales
✓ Casos de uso o historias de usuario (derivados del documento de visión y alcance)
✓ Especificación del caso de uso.
✓ Casos de uso primarios

➢ REQUISITOS NO FUNCIONALES

• Atributos o características de calidad que deberá cumplir el software

➢ RESTRICCIONES

A continuación, se presenta el desarrollo de la Visión y alcance del negocio, así como los
Requerimientos de la arquitectura, relacionados con la situación planteada para la Gasolinera
Texaco.

Visión y alcance del negocio

Introducción (Visión y alcance del sistema)

La gasolinera TEXACO para 2022, tiene previsto incrementar sus ventas en un 30% en las
estaciones de servicio de Envigado y Sabaneta, y ser reconocida por su innovación y calidad en el
auto servicio, donde los vehículos podrán acceder al suministro de combustible con lectura a
través de dispositivo electrónico de su placa sincronizándose los datos del vehículo con el Sistema
de Tránsito donde se encuentre registrado, donde el cliente podrá realizar su pago Online,
ofreciéndosele seguridad, confiabilidad, eficiencia, compatibilidad en todo momento.

Contexto del negocio (antecedentes, descripción del problema o necesidad, reto o idea).
 Arquitectura de Software

62
La Chevron Texaco es una de las empresas líderes en el país en cuanto al suministro de
combustibles, por la calidad, ya que mezclan su producto con Techron para un mejor rendimiento
y limpieza, lo que se traduce en una mayor duración de los motores de los vehículos. La empresa
quiere fortalecer la calidad del servicio de suministro de combustible, implementando un
software que permita agilizar el procedimiento de tanqueo de los vehículos y la realización del
pago Online, así como los respectivos reportes. Para ampliar la información. Ver la situación que
se plantea arriba.

Objetivos del negocio en relación con lo que se espera del sistema, visión de la solución, donde
se elabora tabla con (id y descripción del objetivo del negocio).

Ver Tabla 07. Objetivos del Negocio.

ID Descripción del objetivo del negocio

ON-01 Aumentar las ventas en las estaciones de Envigado y Sabaneta a 2022 en un 30%.

Ser una empresa innovadora en la prestación del servicio de auto abastecimiento

ON-02
de combustible.

Permitir al usuario realizar pagos por medio de las plataformas de pago que existen
ON-03
actualmente.

Sincronizarse con las diferentes bases de datos de los Sistemas de Tránsito de los
ON-04
municipios para validar información de los propietarios de los vehículos

ON-05 Obtener informes del sistema tanto para la gerencia como para el cliente

Ofrecer seguridad, confiabilidad, eficiencia, compatibilidad en relación con la

ON-06
información.

ON-07 Gestionar la información relacionada con el auto servicio.

Fuente: elaboración propia

Características del sistema, utilizando tabla (Id, descripción, prioridad, id del objetivo del
negocio asociado). Ver
 Arquitectura de Software

63
Tabla 08. Características del Sistema

Objetivo de
ID Descripción Prioridad Negocio
Asociado

El sistema debe permitir el registro de los vehículos en

CAR-
cualquiera de las estaciones Texaco de Envigado y Alta ON-07
01
Sabaneta.
El sistema debe permitir al usuario o cliente escoger el
CAR-
modo de tanqueo, por monto o por galones, así como el Alta ON-07
02
tipo de combustible.
CAR- El registro de los vehículos debe ser realizado por medio de
Alta ON-07
03 un lector de placa.
CAR- El sistema almacenará la información tanto de los vehículos ON-07, ON-
Alta
04 como de los propietarios en una base de datos 02
CAR- El sistema almacenará la información completa del ON-17, ON-
Alta
05 autoservicio. 01, ON-02
CAR- El sistema le generará al cliente un reporte completo de la
Alta 0N-05
06 transacción realizada a su dispositivo móvil
El usuario o cliente debe realizar el pago por medio
CAR-
electrónico por intermedio de las plataformas digitales Alta ON-03
07
existentes actualmente.
CAR- El sistema debe permitirle al gerente sacar los diferentes
Alta 0N-05
08 reportes
El sistema debe permitir la consulta de información de
CAR- propietarios por medio de la información ingresada del 0N-04, ON-
Media
09 vehículo consultando las bases de datos de los Sistemas de 06
Tránsito donde esté matriculado el vehículo
CAR- El sistema deberá ofrecer seguridad en las transacciones de
Alta 0N-06
10 pago al cliente.
CAR- La información que arroje el sistema deberá ser confiable,
Alta 0N-06
11 tanto para el cliente como para la Gerencia.
CAR- El sistema deberá ser eficiente en relación con tiempos de
Alta 0N-06
12 respuesta y validez de la información.
CAR- El sistema deberá permitir el pago desde cualquier
Alta 0N-06
13 dispositivo móvil.
 Arquitectura de Software

64
El sistema deberá integrarse sincronizarse adecuadamente
CAR-
con el Sistema de Tránsito de los diferentes municipios, Alta 0N-06
14
donde esté inscrito el vehículo.

Alcance del sistema.

Tabla 09. Alcance del Sistema

Número de entrega Tema Principal ID de características a incluir

CAR-01, CAR-02, CAR-03, CAR-

1.0 Funcionalidad Básica
04, CAR-05, CAR-07

2.0 Estabilidad del Sistema CAR-06, CAR-08, CAR-09

CAR-10, CAR-11, CAR-12, CAR-

3.0 Calidad
13, CAR-14

Fuente: elaboración propia

Contexto del sistema (tabla de interesados y diagrama de contexto)

Interesados. Ver Tabla 10. Interesados y participantes del sistema.

Tabla 10. Interesados y participantes del sistema

Descripción Responsabilidades

• Brindar información completa para el levantamiento de

Administradores de
requisitos.
las Estaciones de
• Permitir las visitas a las Estaciones para el análisis del
Gasolina
proyecto.

• Levantamiento de requerimientos
Analistas • Análisis
Diseñadores • Desarrollo del sistema
• Desarrollo de la base de datos
 Arquitectura de Software

65
Desarrolladores, • Implementación del sistema
entre otros usuarios • Capacitación al personal
informáticos • Mantenimiento del sistema

• Brindarnos información por medio de encuestas y entrevistas

Clientes
para generar un mejor servicio con la aplicación.

Fuente: elaboración propia

Imagen28. Diagrama de contexto TexacoSoft

Fuente: elaboración propia

Entorno de operación, en relación con máquinas, aplicaciones, dispositivos, sistemas externos,

Sistemas Operativos, entre otros aspectos que se deberán tener en cuenta para la operación
del sistema.

• El sistema deberá poder ser usado desde los siguientes navegadores web:
o Internet Explorer 11
o Microsoft Edge
o Firefox 10+
o Google Chrome 17+
 Arquitectura de Software

66
o Safari
o Opera
• Los siguientes dispositivos móviles deberán ser soportados por el sistema:
o iPhone/iPod Touch, iOS 6+
o Android 4+
• El sistema será desarrollado en Java con el framework Sprint Boot, dependiendo del
perfil de programadores del equipo.
• Servidor de aplicación será usado un servidor DELL PowerEdge T330 tower Server cuyas
características son las siguientes:
o Sistema operativo Windows 2016 STD
o Procesador Intel Xeon E3 1230 v5 Quad Core 3.4GHz 8MB
o Memoria RAM de 32GB DDR4
o Almacenamiento de 16TB (4 x 4TB) HDD, PERC S130 RAID.
• La base de datos será gestionada sobre otro servidor DELL PowerEdge T330 tower cuyas
características se pueden ver en el punto anterior, esta base de datos será desarrollada
en MySQL.
• Se usarán tabletas de alto rendimiento para el registro ágil de los vehículos.
• Se utilizará una cámara NLGhost para hacer el escaneo de las placas, las características
de la cámara son las siguientes:
• Se usará la metodología para desarrollo ágil SCRUM.
• Se utilizará servicios web como PayPal, PSE y los de los diferentes bancos para el pago
con tarjeta y así integrar el sistema con los sistemas de pago.
• Se usará la información de las bases de datos de las Secretarias de Tránsito, inicialmente
las del municipio de Sabaneta y Envigado para la validación y registro de los vehículos.

Información adicional en caso de existir (tiempo de entrega tanto para funcionalidad como para
otros servicios, avances)

La aceptación del proyecto incluye los siguientes criterios:

• Protocolo de pruebas de aceptación aprobado al 100%
• El sistema solo tendrá formas de pago vía web.
 Arquitectura de Software

67
• El sistema debe estar completamente funcional al momento de la entrega incluyendo la
integración con las plataformas virtuales de pagos y las oficinas de tránsito a la cual
pertenecen los vehículos.
• El sistema debe ser pensado para que a futuro se pueda expandir a las diferentes
gasolineras de Chevron Texaco del país.

Requerimientos de la arquitectura

Requisitos Funcionales

Imagen29. Diagrama de casos de uso

Fuente: elaboración propia

 Arquitectura de Software

68
CUADRO DE ESPECIFICACIÓN DEL CASO DE USO

Ver Tabla 11. Especificación de Casos de Uso.

Tabla 11. Especificación de Casos de Uso

Tabla 11.
Especificación Característica
Descripción del Caso de Uso
de Casos de asociada
UsoID_CU

CAR-01, CAR-
CU-001 Registrar vehículo utilizando un lector de placa 03, CAR-09,
CAR-12

Seleccionar el tanqueo, de acuerdo con el tipo de tanqueo

CU-002 (corriente, extra, diesel), ya sea por monto o por galones CAR-02,
de combustible, así como su cantidad

CU-003 Generar informe de pago CAR-05, CAR-06

CAR-04, CAR-
Consulta la información del propietario del vehículo en las
CU-004 09, CAR-10,
bases de datos del tránsito
CAR-11

Registrar propietario, en caso de no ser encontrado en la

CU-005 CAR-04, CAR-09
base de datos del tránsito.

CAR-07, CAR-
Realizar pago utilizando un servicio a terceros, utilizando
CU-006 10, CAR-11,
tarjeta
CAR-13

CU-007 El gerente genera los informes que requiera. CAR-08

 Arquitectura de Software

69
CASOS DE USO PRIMARIOS

Se seleccionan los casos de uso principales que se deben considerar para el abordaje de la
arquitectura del software. Ver Tabla 12. Casos de Uso primarios o principales para la Arquitectura

Tabla 12. Casos de Uso primarios o principales para la Arquitectura

ID Criterios de elección (Justificación)

Registro del vehículo, utilizando un lector de placa, siendo este evento uno de
los más importantes, ya que abre todo el proceso de autoservicio de
CU-01 combustible, Interacción con las bases de datos del Tránsito, con el fin de
validar la información del dueño del vehículo, ayudando con esto a la seguridad
del vehículo.

Realizar el servicio de tanqueo, seleccionando el tipo de tanqueo (corriente,

CU-002 diesel, extra), el modo de tanque (monto o galones), así como la cantidad a
tanquear.

Realizar el pago del servicio obtenido, con la restricción que debe pagarse con
CU-006
tarjeta y utilizando un servicio de pago a terceros.

Los diversos reportes que pueda sacar el gerente son importantes para poder
CU-07 generar métricas e indicadores y así aplicar políticas de mercadeo que ayuden
a la empresa, así como el recibo de pago al usuario.

REQUISITOS NO FUNCIONALES

Atributos de calidad relevantes para el sistema (Se trabajó para este análisis con cuatro atributos
de calidad como son la Adecuación Funcional, la Seguridad, la Compatibilidad y la fiabilidad). Ver
Tabla 13. Requisitos de calidad a considerarse en la arquitectura.
 Arquitectura de Software

70
Tabla 13. Requisitos de calidad a considerarse en la arquitectura

ID Categoría Escenario Prioridad

El sistema deberá responder por la

Adecuación
EAC-01 funcionalidad, requerida por Texaco y por Alta
funcional
los usuarios/cliente.

El sistema deberá ofrecer seguridad al

usuario, en el momento de realizar los
EAC-02 Seguridad Alta
respectivos pagos, generando mensajes de
alerta, cuando se requiera.

El sistema debe tener la capacidad de

poder interactuar de manera rápida y ágil
EAC-03 Compatibilidad con las plataformas del Sistema de Alta
Tránsito y Servicio de Pagos, así con
diferentes tipos de dispositivos físicos.

El sistema debe garantizar la operatividad

EAC-04 Fiabilidad las 24 horas del día ya que las gasolineras Alta
trabajan en horario 7*24

RESTRICCIONES DEL SOFTWARE

Restricciones

Ver Tabla 14. Restricciones para tener en cuenta en el diseño de la arquitectura.

Tabla 14. Restricciones para a tener en cuenta en el diseño de la arquitectura

Tipo de restricción Descripción

Tiempos de entregas.
Del cliente
Presupuesto de acuerdo con el entorno de operación
establecido al inicio del proyecto.
Garantizar que los desarrolladores e ingenieros del proyecto
De los desarrolladores
estén familiarizados completamente con el método Ágil
Scrum.
 Arquitectura de Software

71
El tiempo del servicio en la parte de registro y tanqueo no
De los usuarios
debe ser superior a 5 minutos.

➢ Video: ARQUITECTURA DE SISTEMAS

➢ ” Ver Video”: https://www.youtube.com/watch?v=Yl_h4jGUmf0

3.6.1 EJERCICIO DE APRENDIZAJE

Analiza el ejercicio que se desarrolla en este tema (Drivers Arquitectónicos)

3.6.2 TALLER DE ENTRENAMIENTO

De acuerdo con la siguiente situación problemática. Construye la primera fase de la arquitectura
de software. Los requerimientos (Driver Arquitectónicos), teniendo como reto o situación el
siguiente planteamiento:

Objetivo: Identificar los drivers arquitectónicos de acuerdo con la situación planteada, en cuanto
a la visión y alcance del negocio y los requerimientos de la arquitectura, donde se desea mejorar
cada día el acercamiento entre institución y acudientes o padres de familia.

Situación: La institución educativa San Antonio de Prado, dentro de su visión se proyecta como
una institución reconocida por su alto nivel académico y formación humana, donde se debe
mejorar cada día entre otras cosas el acercamiento entre la institución y los acudientes o padres
de familia, ya que estos últimos muchas veces no se dan cuenta si sus niños (as) ingresaron al
colegio, donde se ha dado el caso de que algunos de ellos salen de su casa uniformados, no asisten
al colegio y regresan a casa supuestamente después de la jornada académica como si hubiesen
estado estudiando.
 Arquitectura de Software

72
De igual forma dentro del colegio se presenta muchas veces que algunos estudiantes no ingresan
a algunas clases, donde los docentes no se dan cuenta si están dentro de la institución o se
quedaron por fuera.

Es así como dicha institución requiere de un software que le ayude con dicha gestión, enviándole
un mensaje al acudiente cuando el estudiante ingrese y cuando sale de la institución, de igual
forma cuando ingresa a cada clase, teniendo en cuenta que los estudiantes cambian de salón,
para recibir cada asignatura.

El sistema también debe enviar al móvil del docente una notificación sobre que estudiante faltó
al colegio por cada grupo donde le corresponda clase ese día.

Es importante tener en cuenta que dicha aplicación deberá ser web y móvil, deberá funcionar
para las tres sedes que posee el colegio, donde se instalará un equipo en la portería de cada sede
y un dispositivo para el ingreso a cada aula, los que deberán estar conectados a un servidor en la
nube. También deberá contar con atributos de calidad que garantice la seguridad, compatibilidad,
seguridad y eficiencia en el producto de software.

El sistema no manejará notas ni hojas de vida de los estudiantes y deberá estar listo y probado en
el mes diciembre de este año.

Enlace en caso de que se requiera ampliar la información:

➢ Página Institucional:

https://www.iesanantoniodeprado.edu.co/

➢ PEI Institucional:

https://media.master2000.net/uploads/78/2019/PROYECTO_EDUCATIVO_INSTITUCION
AL_2019.pdf

Se pide:

Redactar el documento de visión y alcance del negocio

1) Construir la introducción (Visión y alcance del sistema)

2) Describir el contexto del negocio (antecedentes, descripción del problema).

 Arquitectura de Software

73
3) Objetivos del negocio en relación con lo que se espera del sistema, visión de la solución
(elaborar tabla con id y descripción del objetivo del negocio)

4) Construcción de tabla sobre características del sistema (crear tabla con Id, descripción,
prioridad, id del objetivo del negocio asociado).

5) Construir tabla de alcance del sistema.

6) Construir el contexto del sistema (tabla de interesados y diagrama de contexto)

7) Describir el entorno de operación, en relación con máquinas, aplicaciones, dispositivos,

sistemas externos, entre otros.

8) Información adicional en caso de existir (tiempo de entrega, tiempo de entrega de nuevos

servicios, entregables, entre otros).

Construir los requerimientos de la arquitectura

1) Drivers funcionales

• Construir los casos de uso (derivados del documento de visión y alcance).

• Realizar cuadro de especificación del caso de uso.

• Cuadro de casos de uso primarios

2) Driver (cuadro de atributos de calidad relevantes para el sistema, trabajar mínimo con 4).

3) Driver (cuadro de restricciones)

TIPS
Los requerimientos corresponden a la primera fase de la Arquitectura
del Software y está compuesta por los Drivers Arquitectónicos
(Requisitos Funcionales, Requisitos No Funcionales o de Calidad y las
Restricciones).
 Arquitectura de Software

74
3.7 TEMA 2. DISEÑOS ARQUITECTÓNICOS
Según Cervantes, Velasco, y Castro (2016), el diseño es la especificación de un objeto, creado por
algún agente, que busca alcanzar ciertos objetivos, en un entorno particular, usando un conjunto
de componentes básicos, satisfaciendo una serie de requerimientos y sujetándose a
determinadas restricciones, donde la etapa de diseño de la arquitectura puede verse como una
transformación, que realiza el arquitecto, de los drivers hacia las distintas estructuras que
componen a la arquitectura. Teniendo en cuenta la toma de decisiones en relación con los drivers
de la arquitectura y la creación de estructuras para satisfacerlos, la Identificación de todos los
módulos, el diseño de sus interfaces, el diseño de los detalles de implementación de módulos
previo a su codificación y prueba, los principios de diseño, el método a utilizar, el patrón
arquitectónico, así como las herramientas de diseño. Ver imagen30. Ciclo de vida de la
arquitectura de software (Diseño).

Imagen30. Ciclo de vida de la arquitectura de software (Diseño)

Fuente: elaboración propia.

 Arquitectura de Software

75
Cervantes, Velasco, y Castro (2016) Puntualizan que:

• El objeto se refiere a las distintas estructuras (físicas, lógicas, de ejecución) que componen
la arquitectura de software.
• El agente es el(los) arquitecto(s) de software u otros encargados del diseño.
• Los objetivos son la satisfacción de los requerimientos que influyen a la arquitectura (los
drivers) y la partición del sistema con el fin de realizar estimación o guiar su desarrollo.
• El entorno se refiere tanto al contexto de uso del sistema, por parte de los usuarios finales,
como al ambiente en que se desarrolla el sistema.
• Los componentes básicos son los elementos de diseño, o bien, los conceptos de diseño.
• El conjunto de requerimientos incluye la lista de drivers, tanto los requerimientos
funcionales como los no funcionales (principalmente los atributos de calidad).
• Las restricciones son todas las limitaciones impuestas ya sea por el cliente o por la
organización de desarrollo; también son parte de los drivers.

La siguiente imagen muestra los diferentes niveles de diseño, iniciando con aspectos macro, hasta
llegar a un detalle que genere mayor entendimiento. Ver imagen31. Niveles del Diseño de la
Arquitectura.

Imagen31. Niveles del Diseño de la Arquitectura

Fuente: elaboración propia.

 Arquitectura de Software

76
Para realizar el diseño arquitectónico, se deberá tener presente los siguientes principios. Ver
imagen32. Principios de diseño.

Imagen32. Principios de Diseño

Fuente: elaboración propia.

ALGUNOS CONCEPTOS DE DISEÑO (PATRONES, TÁCTICAS, FRAMEWORKS)

• PATRONES

En 1994 apareció el primer catálogo de patrones de diseño que, hasta la fecha, sigue siendo
una obra de referencia, y que se llama Patrones de diseño: elementos de software orientado
a objetos reutilizables (Gamma, Helm, Johnson y Vlissides, 1994). Este libro, cuyos autores
son conocidos como el “GoF”, o “Gang of Four” (banda de los cuatro) documenta 23 patrones
enfocados a problemas de diseño de granularidad relativamente fina.

Los patrones son soluciones conceptuales. Esto significa que no pueden usarse de forma
directa, sino que deben ser “instanciados”, es decir, adecuados al contexto y al problema
específico que se busca resolver.

El arquitecto Christopher Alexander define el término patrón de la siguiente manera:

 Arquitectura de Software

77
“Cada patrón es una regla de 3 partes, que expresa una relación entre un contexto, un
problema y una solución. Como un elemento en el mundo, cada patrón es una relación
entre un contexto, un sistema de fuerzas que ocurren repetidamente en ese contexto y
una configuración espacial que permite que esas fuerzas se resuelvan entre sí. Como
elemento de un lenguaje, un patrón es una instrucción que muestra como puede ser usada
esta configuración espacial una y otra vez para resolver el sistema de fuerzas, siempre que
el contexto lo haga relevante.”

PARA QUÉ SIRVE

Los patrones arquitectónicos se utilizan para expresar una estructura de organización base o
esquema para un software. Muestran aspectos fundamentales de la estructura de un sistema
software. Especifican un conjunto predefinido de subsistemas con sus responsabilidades y una
serie de recomendaciones para organizar los distintos componentes. Ver imagen33. Patrones

PATRONES

PATRONES
IDIOM PATRONES DE DISEÑO
ARQUITECTÓNICOS

Se centran en la estructura
Esquemas para refinar los
del sistema, en la definición
subsistemas o componentes
de subsistemas, sus
de sistema software o sus
Patrones que ayudan a responsabilidades y reglas
relaciones, describen una
implementar aspectos sobre las relaciones entre
estructura recurrente y
particulares del diseño en un ellos. Proporcionan un
común que resuelve un
lenguaje de programación conjunto predefinido de
problema de diseño dentro
específico, como los descritos subsistemas, sus
de un contexto como los
por Coplien (1991) resonsabilidades y las líneas
descritos por Gamma (1995).
guía para organizar sus
También los patrones GRASP
relaciones. Buschman (1996)
estarían en esta categoría
o Shaw y Galan (1996)

Fuente: elaboración propia.

• TÁCTICAS

Las tácticas son conceptos de diseño que influyen sobre el control de la respuesta a un atributo
de calidad particular. A diferencia de los patrones, no presentan soluciones conceptuales
 Arquitectura de Software

78
detalladas, sino que son técnicas probadas de las ciencias de la computación con las que se
resuelven problemas en aspectos particulares relacionados con diversos atributos de calidad. Ver
imagen34. Ejemplo de táctica para el atributo de seguridad.

Imagen34. Ejemplo de Táctica para el atributo de seguridad

• FRAMEWORKS

Tanto patrones como tácticas son conceptos de diseño abstractos que deben adecuarse al
problema particular y ser implementados posteriormente en el código. Existen, sin embargo,
otros conceptos de diseño, los cuales no son abstractos, sino que son código concreto: los
frameworks (marcos de trabajo). Estos son elementos reutilizables de software que proveen
funcionalidad genérica y se enfocan en la resolución de un problema específico, como puede ser
la construcción de interfaces de usuario o la persistencia de objetos en una base de datos
relacional.

Frameworks, patrones y tácticas están relacionados pues, en general, los primeros implementan
una variedad de patrones y de tácticas. Un ejemplo de ello son los frameworks enfocados en la
creación de interfaces de usuario que, frecuentemente, implementan el patrón llamado Modelo-
Vista-Controlador. Ver imagen35. frameworks Arquitectónicos.
 Arquitectura de Software

79
35. Frameworks Arquitectónicos

Fuente: https://bbarrosa.files.wordpress.com/2019/07/mejores-lenguajes-de-programacion-2018-1080x675.jpg

ALGUNOS MÉTODOS DE DISEÑO DE ARQUITECTURA

A continuación, se presentan algunos métodos para el Diseño Arquitectónico, en los cuales se

puede observar, los pasos a utilizar para la elaboración del diseño. Es importante aclarar que
existen otros métodos, donde el modelo que se seleccione dependerá de la necesidad o gusto de
quien o vaya a utilizar. Algunos de los métodos de diseño son: ADD, ACDM, Rozanski y Woods.
Ver imágenes36,37 y 38 sobre métodos de Diseño Arquitectónico.
 Arquitectura de Software

80
Imagen36. Método Diseño Guiado por Atributos (ADD) o (Attribute Driven Design, o ADD)

Fuente: elaboración propia.

 Arquitectura de Software

81
Imagen37. Método Diseño Centrado en la Arquitectura, o ACDM

Fuente: elaboración propia.

 Arquitectura de Software

82
Imagen38. Método de Definición de Arquitecturas de Rozanski y Woods

Fuente: elaboración propia.

 Arquitectura de Software

83
REPRESENTACIÓN DE LA ARQUITECTURA EN CAPAS

A continuación, se representa un diseño arquitectónico por capas, utilizando el lenguaje de

modelado UML, donde Cervantes, Velasco, y Castro (2016) dejan ver a través de sus
representaciones gráficas, el diseño de diferentes vistas como son: Vista Lógica, Vista de
Comportamiento, Vista Física, así como una descripción clara de la temática. Ver imagen39.
Ejemplo sobre estructura de diseño de una Arquitectura de Software.

Imagen39. Ejemplo sobre estructuración de diseño de una Arquitectura de Software

Fuente: https://sg.com.mx/buzz/autores/humberto-cervantes

VISTA LÓGICA

Incluyen clases, paquetes, módulos o subsistemas. Así mismo, las relaciones o formas de
organización utilizadas con frecuencia incluyen es-parte-de (que se emplea para representar una
relación de agregación o composición), depende-de (la cual se usa para indicar que la unidad
requiere de otra para funcionar correctamente), y es-un (que se utiliza para indicar que la unidad
es “hija” de otra unidad la cual funge como “padre” y, por lo tanto, la unidad “hija” posee algunas
de sus características). La relación <<usa>> se utiliza para indicar el tipo de vínculo entre los
 Arquitectura de Software

84
elementos de las vistas; <<usa>> es el mecanismo para indicar una relación depende-de en UML.
Ver imagen40. Diseño de Vista Lógica, utilizando un diagrama de paquetes.

Imagen40. Diseño de Vista Lógica

Fuente: https://sg.com.mx/buzz/autores/humberto-cervantes

VISTA DE COMPORTAMIENTO

Las vistas de comportamiento describen estructuras cuyos elementos denotan entidades visibles
en tiempo de ejecución, por ejemplo, instancias, procesos, objetos, clientes, servidores o
 Arquitectura de Software

85
almacenes de datos. Además del nombre, el tipo y la funcionalidad ofrecidos, las propiedades de
los elementos en este tipo de vistas incluyen por lo habitual información sobre valores específicos
de atributos de calidad que pueden observarse cuando se ejecuta el sistema, por ejemplo,
confiabilidad, desempeño o seguridad. Por otra parte, las relaciones describen la naturaleza de
los mecanismos o protocolos de comunicación utilizados para la comunicación entre los
elementos de la vista. De esta forma, flujo-de-datos, llamada-a-procedimiento-remoto, acceso-
compartido, broadcasting (captura de fuentes de video en tiempo real), o incluso SOAP (protocolo
estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de
intercambio de datos XML), son ejemplos válidos de relaciones que pueden emplearse durante la
documentación de vistas de comportamiento (Clements, et al., 2010). Ver imagen41. Diseño de
Vista de Comportamiento, utilizando un diagrama de secuencia.

Imagen41. Diseño de Vista de Comportamiento

Fuente: https://sg.com.mx/buzz/autores/humberto-cervantes
 Arquitectura de Software

86
Imagen42. Diseño Vista Física

Fuente: https://sg.com.mx/buzz/autores/humberto-cervantes

Ver los siguientes videos, donde se puede observar la forma de diseñar diagramas UML,
requeridos para el diseño de la arquitectura de software.

➢ Video: DIAGRAMA DE PAQUETES

➢ ” Ver Video”: https://www.youtube.com/watch?v=XR15vneBFoU

➢ Video: DIAGRAMA DE DESPLIEGUE

➢ ” Ver Video”: https://www.youtube.com/watch?v=TlMOQsWO9DQ

➢ Video: DIAGRAMA DE COMPONENTES

➢ ” Ver Video”: https://www.youtube.com/watch?v=RDTLcJLNcK4
 Arquitectura de Software

87
3.7.1 EJERCICIO DE APRENDIZAJE
Visualizar cada uno de los videos, donde se observa paso a paso cómo diseñar diagramas tipo
UML

3.7.2 TALLER DE ENTRENAMIENTO

Teniendo en cuenta la situación planteada de la Institución educativa San Antonio de Prado,
aplicar el diseño arquitectónico (Ver ejemplo de diseño arquitectónico al final del documento).
Tener en cuenta los siguientes parámetros.

Parámetros para la elaboración del Diseño Arquitectónico

1. Definir el patrón Arquitectónico

En esta sección se presenta el patrón a utilizar (Cliente-Servidor, VMC, Capas, entre otros…),
basado en el patrón arquitectónico seleccionado.

2. Diseñar un diagrama de contexto general

El diagrama general deberá mostrar los elementos del patrón elegido y los elementos principales
de la situación abordada (tema- reto). Tener en cuenta los Driver elaborados, ya que será la base
para presentar este diseño. Ver imagen43. Ejemplo de diagrama basado en capas.

Imagen43. Ejemplo de diagrama basado en Capas

 Arquitectura de Software

88
Fuente: http://repositorio.cedia.org.ec/bitstream/123456789/952/1/Documento%20de%20Arquitectura%20CAD-
CAM.pdf

3. Justificación

Describa por qué se seleccionó dicho patrón arquitectónico, en relación con la temática
planteada.

4. Definir el método a utilizar

En este caso se trabajará con el método ACDM, hasta la etapa 4, tener en cuenta que, con la
elaboración de los Driver Arquitectónicos, ya se ha desarrollado hasta la etapa 2 del método
ACDM, la etapa 3 y 4 corresponde al diseño. Ver imagen44. Apartes del método de diseño ACDM.

Imagen 44. Apartes del método de diseño ACDM

5. Realizar el diseño, utilizando UML y el patrón seleccionado., donde se pide fundamentar

el diseño los siguientes diagramas.

• Diagrama de Clase
• Diagrama de componentes.
• Diagrama de secuencia, donde se muestre los casos de uso primarios que aparecen
en el Driver.
 Arquitectura de Software

89
• Diagrama de despliegue donde aparezca el hardware y software requerido (equipos,
software)
• Modelo relacional.

Nota: Utilizar un lenguaje modelador (Enterprise Architect, ArgoUML, Umbrello, Cacoo, entre
otros). Cada diagrama deberá estar documentado.

6. Organizar en un solo documento:

✓ Los Drivers Arquitectónicos

✓ El Diseño Arquitectónico

7. Documentar, aplicando el Método de diseño centrado en la arquitectura (ACDM). Ver la

siguiente imagen45. Método para documentación de Arquitecturas_ACDM

Imagen45. Método para documentación de Arquitecturas_ACDM

Nota: recuerda que el diseño se basa en el Driver Arquitectónico solicitado en taller de

entrenamiento.
 Arquitectura de Software

90

TIPS
El diseño de la arquitectura permite visualizar la forma como definirá
las estructuras tanto físicas y lógicas para la construcción del
software.

3.8 TEMA 3. DOCUMENTACIÓN DE LA ARQUITECTURA

Se refiere a comunicar información relevante de un proceso, producto o entidad, donde se
incluyen las guías de usuario, manuales de políticas y procedimientos, así como tutoriales,
documentos técnicos o guías de referencia rápida. La etapa de documentación se centra en la
generación de documentos que describen las estructuras de la arquitectura con el propósito que
esta información pueda ser comunicada de manera eficiente a los diversos interesados en el
sistema. Ver imagen46. Ciclo de vida de la arquitectura de software.

Imagen46. Ciclo de vida de la arquitectura de software

Fuente: elaboración propia.

 Arquitectura de Software

91
Cervantes, Velasco y Castro, (2016). Plantean que la documentación permite mejora la
comunicación de información sobre la arquitectura, preserva la información sobre la
arquitectura, guía la generación de artefactos en otras fases del ciclo de vida, proveer un lenguaje
común entre diversos interesados en el sistema. Para lo cual se utilizarán métodos que describen
de manera más explícita tanto las entradas requeridas como la secuencia de acciones que
comprenden y las salidas generadas, los marcos conceptuales proveen un conjunto de conceptos
que deben considerarse al documentar la arquitectura, donde ambos buscan decidir de manera
más sistemática cuáles vistas y de qué modo elaborarlas. Algunos son: Vistas y más allá (Vers and
Beyond), 4+1 Vistas (4+1 Vers), Método de diseño centrado en la arquitectura (ACDM) Puntos de
vista y perspectivas (Verpoints and Perspectives).

Su objetivo es generar la descripción de los elementos que conforman las estructuras

arquitectónicas para que esta pueda ser comunicada de manera eficiente a los diversos
interesados en el sistema. Un concepto utilizado ampliamente durante la elaboración de los
documentos de la arquitectura es el de vista. Los tipos de vista que se emplean con frecuencia
son:

1. Vistas lógicas.

2. Vistas de comportamiento.

3. Vistas físicas.

DOCUMENTAR PARA COMUNICAR LA ARQUITECTURA

 Arquitectura de Software

92

Imagen47. Representación de las vistas

Fuente: elaboración propia

NOTACIONES

Se presentan tres tipos de notaciones. Ver imagen48 Tipos de notaciones.

 Arquitectura de Software

93
Imagen48. Tipos de notaciones

INFORMAL

No se explica claramente el
significado y relación de
cada elemento, por lo tanto,
se presta para una
inadecuada interpretación.

SEMI INFORMAL

Al ser un Estándar UML,

facilita la interpretación de
sus componentes, así como
la relación entre ellos.
Siendo importante el uso de
notaciones
 Arquitectura de Software

94
FORMAL

Algunos de los ADL más

conocidos son Acme4,
creado en la Universidad
Carnegie Mellon; AADL5,
creado tanto por miembros
de esta misma universidad
como el SEI, la Armada de
los Estados Unidos y
Honeywell Technology
Center, y XADL6 creado en
la Universidad de California
Irvine

Fuente: elaboración propia.

ALGUNOS MÉTODOS Y MARCOS CONCEPTUALES DE DOCUMENTACIÓN DE ARQUITECTURA

Algunos métodos que se pueden aplicar para la documentación de la Arquitectura de Software

son: Método Vista y más Allá, Método 4+1 Vista, Método de diseño centrado en la arquitectura
(ACDM), entre otros. Ver Tabla 15. Algunos métodos para la documentación de la Arquitectura
de Software.

Tabla 15. Algunos métodos para la documentación de la Arquitectura de Software

MÉTODO VISTA Y MÁS ALLÁ

1) Representación primaria de la vista. Es

una representación gráfica de la vista en
términos de sus principales elementos y
relaciones, así como el texto
correspondiente para describir de forma
general la información anterior.

2) Catálogo de elementos. Esta sección hace

las veces de un catálogo que contiene los
elementos de la representación primaria
 Arquitectura de Software

95
describiéndolos con detalle. La
información explícita acerca de estos
incluye, propiedades, interfaces o
comportamiento.

3) Diagrama de contexto. Permite ubicar al

lector de la documentación sobre cuál
parte del sistema es la que se describe en
la vista.

4) Guía de variabilidad. Describe los posibles

puntos de variación permisibles, si es que
existen, de los elementos y relaciones
representados en la vista. Ejemplos de
estas variaciones incluyen rangos en los
valores de las propiedades de los
componentes, o variaciones en los
protocolos de comunicación soportados
por ellos.

5) Antecedentes de la arquitectura. Explica

las razones que soportan las decisiones de
diseño tomadas por el arquitecto durante
el diseño de elementos y relaciones
representadas en la vista.

6) Otra información. En esta sección se

describe información relevante extra que
aplique a la vista. Algunos ejemplos de
ella: reglas de negocio, información sobre
el equipo de desarrollo o descripción del
sistema.
 Arquitectura de Software

96
MÉTODO 4+1 VISTA

Recomienda de modo específico la

elaboración cinco vistas:

• Vista lógica. Describe la arquitectura

desde la perspectiva de los usuarios
finales, es decir, considerando los
elementos principales que proveen a
estos los servicios del sistema.

• Vista de procesos. Explica la arquitectura

haciendo mayor énfasis en los elementos
que en tiempo de ejecución permiten
soportar aspectos como concurrencia,
rendimiento o escalabilidad.

• Vista de desarrollo. Describe la

arquitectura en términos de elementos
relevantes para los desarrolladores del
sistema.

• Vista física. Explica los componentes

físicos del sistema (es análoga a las vistas
físicas descritas en la sección 4.4.3)

• Vista “+1” tiene la función de relacionar

los elementos en las otras cuatro vistas
por medio de casos de uso o escenarios
que ilustren cómo interactúan todos estos
elementos.
 Arquitectura de Software

97
MÉTODO DE DISEÑO CENTRADO EN LA ARQUITECTURA (ACDM)

ACDM considera las vistas estáticas,

dinámicas y físicas.

Contempla además la noción de vistas mixtas

utilizadas para documentar información
necesaria para, por ejemplo, comunicar la
asignación de elementos de vista dinámica a
elementos de la vista física o a los equipos
responsables de su implementación, o bien,
comunicar la relación entre los drivers
arquitectónicos y los elementos que los
soportan en las diferentes vistas.

Mapeo: (Representación visual de la

estrategia de una organización, describe el
proceso de creación de valor mediante una
serie de relaciones de causa y efecto entre los
objetivos de las cuatro perspectivas del BSC
(Financiera,

Clientes, Procesos Internos, Aprendizaje y

Crecimiento))

Fuente: adaptado de https://sg.com.mx/buzz/autores/humberto-cervantes

3.8.1 TALLER DE ENTRENAMIENTO

Documentar el diseño realizado, aplicando el método de documentación (Método de diseño
centrado en la arquitectura (ACDM)).

Se debe tomar el documento de los Driver Arquitectónico, el del diseño, se integra y se ajusta con
el método en mención.

TIPS
Una buena documentación de la Arquitectura del software facilitará
la comunicación entre los diferentes usuarios (cliente-usuario final y
expertos informáticos).
 Arquitectura de Software

98
3.9 TEMA 4. EVALUACIÓN DE LA ARQUITECTURA
La fase de evaluación de la arquitectura permite realizar revisiones del diseño, teniendo como
objetivo principal la mitigación de riesgos asociados a la pregunta ¿El diseño de la arquitectura
satisface a los requerimientos que influyen a la arquitectura y, principalmente, a los atributos de
calidad? Para lo cual se establecen técnicas como por ejemplo Checklists y cuestionarios,
evaluaciones basadas en escenarios, en simulación, modelos matemáticas, la experiencia las
cuales buscan que el diseño sea viable en relación con la necesidad que deberá satisfacer el
sistema de software. Ver imagen49. Ciclo de vida de la arquitectura de software.

Imagen49. Ciclo de vida de la arquitectura de software

Fuente: elaboración propia.

Normalmente las técnicas las técnicas de evaluación son aplicadas cuando la arquitectura está en
producción, evaluándose de forma cualitativa, en relación con las técnicas de evaluación
cuantitativa, estas se aplican normalmente cuando el software ya ha sido terminado o
implementado.
 Arquitectura de Software

99
Entre los métodos más utilizados para la evaluación de arquitectura de software tenemos SAAM,
ATAM, ARID:

• Método de Análisis de Arquitecturas de Software (Software Architecture Analysis Method,

SAAM)
• Architecture Trade-off Analysis Method (ATAM)
• (Active ReVers for Intermediate Designs, ARID)

Los que pueden ser ampliados, de acuerdo con el interés de cada estudiante.

TIPS
La evaluación de la arquitectura permite realizar ajustes,
especialmente en los atributos de calidad.

3.10 TEMA 5. IMPLEMENTACIÓN DE LA ARQUITECTURA

La implementación se basa en la comunicación de la
arquitectura que, a través de la documentación,
facilita la interacción con los diferentes actores
comprometidos con el sistema de software (Líderes
de proyecto, analistas, diseñadores, desarrolladores,
clientes, entre otros), donde de la claridad en la
comunicación de los resultados del diseño
arquitectónico, dependerá toma de decisiones y por
consiguiente el éxito o fracaso del proyecto. Ver
imagen50. Ciclo de vida de la arquitectura de
software.

Imagen50. Ciclo de vida de la arquitectura de software

 Arquitectura de Software

100
Continuación del ejemplo que se viene desarrollando, en relación con el Diseño Arquitectónico

Para ejemplificar el diseño y la documentación, basada en los Driver Arquitectónicos, se tomó

apartes de la propuesta presentada por los estudiantes de Ingeniería de Sistemas de la
Corporación Universitaria Remington, Neftaly Mora Patiño y Juan Carlos Herrera Camaño,
quienes tenían como temática asignada para el desarrollo de la Asignatura Arquitectura de
Software, el reto que se viene tratando. Los estudiantes autorizaron la utilización de su
propuesta, para ejemplificar la temática, generando así un aporte académico.

Nota: algunos diagramas se ajustaron de acuerdo con la necesidad.

Desarrollo del Diseño Arquitectónico

• PRESENTACIÓN

Para nuestro proyecto el modelo de arquitectura que usaremos es el N-Capas, adicionalmente

para la capa de presentación en el desarrollo será usado el modelo MVC, el cual será desarrollado
con Spring MVC. Para este caso los usuarios serán todos los que hagan uso de la aplicación en
cualquiera de sus funcionalidades y habrá unos usuarios con más privilegios quienes serán los
administradores del sistema y podrán realizar ajustes, cambios y mantenimiento al mismo.

Tanto los usuarios administradores como los usuarios normales dispondrán de una aplicación
cliente que será web, para el caso de los usuarios normales, dispondrán de tabletas de alto
rendimiento por medio de las cuales podrán interactuar con la aplicación. Los usuarios
administradores podrán ingresar a la aplicación desde el mismo servidor de aplicaciones o desde
cualquier PC que cuente con un navegador web. Ver imagen. Estructura general Arquitectónica.

Estructura General Arquitectónica

 Arquitectura de Software

101

Fuente: Neftaly Mora_Juan Carlos Herrera.

• JUSTIFICACIÓN

Luego de hacer un análisis de algunos modelos de arquitectura y basándonos en las diferentes

tecnologías empleadas para la construcción de nuestra aplicación optamos por el modelo de
arquitectura entre capas ya que nos permite separar el sistema por módulos y estos a su vez en
sub-sistemas siendo esto una ventaja a la hora de considerar los atributos de calidad más
importantes para nuestro sistema.

Características como la asignación única de responsabilidades de cada una de las capas, el bajo
acoplamiento y la alta cohesión, nos dan la posibilidad diseñar aplicaciones fáciles de mantener
que permiten escalabilidad, mejorando la estabilidad del sistema lo que impacta la disponibilidad
de este dando un plus de calidad y confiabilidad por parte de nuestros clientes y usuarios.

Este modelo permite hacer sistemas más robustos a los cuales le podemos ir haciendo los ajustes
que se requieran sin sacrificar la calidad del producto.

Otra bondad de este modelo es la posibilidad de poder integrar módulos externos para que
funcionen con nuestra aplicación, esta característica se alinea con el diseño de nuestra aplicación
 Arquitectura de Software

102
ya que se tiene contemplado hacer uso de módulos como el de pago y consulta a bases de datos
de entidades externas.

• DISEÑO

Método Seleccionado

Para este caso se utilizará el Método de Diseño Centrado en la Arquitectura (ACDM), teniendo
en cuenta que ya contamos con los Drivers Arquitectónicos y con base en estos se realizará todo
el proceso de diseño de la arquitectura. De igual manera, los drivers arquitectónicos nos están
proporcionando de primera mano el alcance que tendrá el proyecto y todas las especificaciones
requeridas para el avance del proceso de diseño.

Para el desarrollo partiremos de los drivers arquitectónicos ya provistos, puntualmente de los

casos de uso considerados como primarios (CU-001, CU-002, CU-006, CU-007) y a partir de estos
plantearemos nuestro desarrollo, identificando de igual manera los actores principales del
sistema.
Caso de uso CU-001 – Registrar vehículo

Fuente: elaboración propia.

 Arquitectura de Software

103
Nombre: Registro de vehículos

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción: este es el proceso encargado de registrar los vehículos nuevos en el sistema.

Actores: Usuario (Conductor)

Precondiciones:
Ingresar con el vehículo a cualquiera de las estaciones de los municipios
de Envigado y Sabaneta.

Flujo normal:

1. Tomar la placa con el lector: Permite tomar la placa del vehículo de manera automática
con el lector de placas.
2. Comprobación de placa: Permite verificar si la placa existe en el sistema o si es una placa
nueva.
3. Conexión con la ST: Se conecta con los servicios de la secretaría de transito del
municipio para completar los datos del propietario de acuerdo con la placa recolectada
con el lector.
4. Completar datos: Por medio de una interfaz de usuario le permite al conductor
completar los datos adicionales que sean requeridos al momento del registro y aceptar
el registro para ser guardado en la base de datos.

Flujo Alternativo:
2.A - Si la placa ya está registrada en el sistema direcciona al conductor al proceso de tanqueo.
3.B - SI hay algún problema con la conexión o el cargue de datos desde la secretaría de transito
del municipio, le despliega al conductor la interfaz para que ingrese los datos requeridos.

Post condiciones:
El vehículo ha quedado registrado en el sistema con su respectivo propietario para futuras
transacciones.

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

104
Caso de uso CU-002 – Tanquear

Fuente: elaboración propia

Nombre: Proceso de tanquear

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción: Aquí se describe el proceso en el que se escoge el tipo de tanqueo y la

cantidad

Actores: Usuario (Conductor)

Precondiciones: Que el vehículo este registrado en el sistema.

 Arquitectura de Software

105
Flujo normal:
1. El sistema le despliega al usuario una interfaz con las opciones de tanqueo.
2. El conductor selecciona el tipo de combustible a tanquear.
3. El conductor indica si quiere tanquear por galones o por monto.
4. El conductor indica la cantidad de galones o monto para el tanqueo.
5. Se genera el cobro en el sistema parea ser remitido al pago.

Flujo Alternativo:
1.A - EL conductor cancela la transacción y se retira.

Post condiciones:

El sistema termina el proceso de tanqueo y genera el cobro del servicio.

Fuente: Neftaly Mora_Juan Carlos Herrera.

Caso de uso CU-006 – Realizar pago con tarjeta

Fuente: elaboración propia.

 Arquitectura de Software

106
Nombre: Realizar pago con tarjeta

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción: Proceso que describe al pago del servicio

Actores: Usuario (Conductor)

Precondiciones:
Haber realizado el proceso de tanqueo del vehículo

Flujo normal:
1. Le indica al conductor el valor total a pagar de acuerdo con el tanqueo realizado
2. Le permite al conductor seleccionar el modelo de pago y la aplicación a usar.
3. Dirige al usuario a la aplicación seleccionada para que siga con el procedimiento
de pago en ésta.
4. La aplicación seleccionada por el usuario devuelve el resultado del pago al sistema
y al usuario confirmando el pago realizado por éste.
5. El sistema carga el pago del conductor y genera el comprobante de la transacción,
el cual será enviado vía email.

Flujo Alternativo:
4.A - EL proceso de pago no fue satisfactorio y le indica al usuario que debe
seleccionar otro medio de pago.

Post condiciones:
EL conductor se retira con el carro tanqueado y con el comprobante de la
transacción vía email.

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

107
Caso de uso CU-003 y CU-007 Generar Informes

Fuente: elaboración propia.

Nombre: Generar informes

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción: Sistema de generación de reportes

Actores: Conductor / Gerente

Precondiciones:
Conductor: Haber realizado el proceso pago de un servicio.
 Arquitectura de Software

108
Gerente: Haberse logueado en el sistema.

Flujo normal:
1. El gerente genera el reporte de tanqueos realizados en un día.
2. El gerente genera el reporte de tanqueos realizados en un mes.
3. El gerente genera el reporte de vehículos que más usan el servicio.
4. El gerente genera el reporte de tanqueo de un conductor en específico.
5. El sistema le genera al conductor el comprobante de la transacción y se lo envía
por correo electrónico.

Flujo Alternativo:
Ninguno

Post condiciones:
Reportes generados.

Fuente: Neftaly Mora_Juan Carlos Herrera.

La aplicación será implementada para operar en las 4 estaciones de Sabaneta (Antioquia) y las 4
estaciones de servicio de Envigado (Antioquia). Cuando el vehículo llega por primera vez, deberá
ser registrado por el conductor, donde un lector tomará la placa del vehículo y en una pantalla
táctil de forma ágil, se podrá ubicar información para terminar el registro, como por ejemplo la
identificación del dueño del vehículo, la cual será sincronizada y verificada automáticamente con
las bases de datos donde se encuentre matriculado dicho vehículo, si el vehículo ya ha sido
registrado en cualquier estación de Texaco Envigado y Sabaneta, bastará con pasar por el punto
donde se encuentra el lector de placa para iniciar su proceso de abastecimiento de combustible.
 Arquitectura de Software

109
Diseño de los componentes

Vista Lógica

Fuente: Neftaly Mora_Juan Carlos Herrera.

Nombre: Vista Lógica

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020
 Arquitectura de Software

110
Descripción de los componentes:
• Paquete de Presentación: Representa los componentes de la capa de presentación.
• Interfaz Administrador: Representa la interfaz del administrador y sus componentes.
• Interfaz Usuario: Representa la interfaz del usuario y sus componentes.
• Paquete de Negocio: Representa los componentes de la capa de negocio
• Servicios: Representa los servicios que van a ser usados en la capa de negocio.
• Subsistemas de creación de Informes: Representa los componentes usados por el
negocio para la creación de los informes.
• Envió de Notificaciones: Representa los componentes usado por el negocio para el envió
de notificaciones.
• Paquete de Datos: Representa los componentes de la capa de Datos.
• Persistencia: Representa los componentes usados para realizar la persistencia de los
datos.

• Paquete de Datos: Representa los componentes del set de datos.

• Modelo de Datos: Representa los componentes para la lógica de uso de los datos.
• Acceso a entidades Persistidas: Representa los componentes usados que permiten el
acceso a las diferentes bases de datos.
• Paquete Interfaz: Representa los componentes de interfaces usadas en las vistas web y
móviles
• Paquete Dominio: Representa los componentes de interfaces usadas en las clases de
negocio y reglas de negocio.
• Vista Web: Representa las interfaces usadas en la presentación web.
• Vista Móviles: Representa las interfaces usadas en la presentación móvil.
• Clases de Negocio: Representa los componentes usados para aplicar las clases del
negocio.

Descripción de los flujos:

1. El paquete presentación y todos sus componentes depende del paquete negocio.
2. El paquete negocio y todos sus componentes dependen del paquete datos
3. El paquete interfaz y todos sus componentes dependen del paquete presentación.
 Arquitectura de Software

111
4. El paquete interfaz y todos sus componentes dependen del paquete negocio.
5. El paquete negocio y todos sus componentes dependen del paquete dominio.
6. El paquete datos depende del paquete dominio.

Fuente: Neftaly Mora_Juan Carlos Herrera

Diagrama de Clases

Fuente: Neftaly Mora_Juan Carlos Herrera

 Arquitectura de Software

112
Nombre: Diagrama de clases

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción de los componentes:

• Clase Persona: Representa los atributos y comportamientos
• (métodos) de esta clase padre que será heredada por sus clases hijas
• Clase Vehículo: Representa los atributos y comportamientos
• (métodos) de esta clase padre que será heredada por sus clases hijas
• Clase Combustible: Representa los atributos y comportamientos
• (métodos) de esta clase padre que será heredada por sus clases hijas
• Clase Tanqueo: Representa los atributos y comportamientos de esta clase
• Clase Pago: Representa los atributos y comportamientos de esta clase

Descripción de los flujos:

1. La clase persona es la clase padre de la clase dueño, de la clase conductor y de la clase
persona que heredarán los atributos de su clase padre.
2. La clase vehículo es la clase padre de la clase liviano, de la clase autobús de la clase
camión y de la clase carga liviana que heredarán los atributos de su clase padre.
3. La clase combustible es la clase padre de la clase corriente, de la clase Premium y de la
clase diésel que heredarán los atributos de su clase padre.
4. Para que se pueda registrar un vehículo a la app es necesario que antes exista un dueño
o un conductor.
5. Para que pueda haber un tanqueo debe esta previamente registrado el conductor o
dueño y su vehículo.
6. Para que se pueda seleccionar un tipo de combustible previamente se debe hacer la
solicitud del tanqueo y así tanquear el combustible.
7. Para poder hacer un seleccionar y hacer un tipo de pago previamente se debió hacer la solicitud
del tanqueo al vehículo registrado a un conductor o dueño que aprobará el pago.
Fuente: Neftaly Mora_Juan Carlos Herrera
 Arquitectura de Software

113
Diagrama de componentes

Fuente: Neftaly Mora_Juan Carlos Herrera.

Nombre: Diagrama de componentes

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020
 Arquitectura de Software

114

Descripción de los componentes:

• Lector de placas: es el dispositivo encargado de la lectura de las placas del vehículo al

momento de ingresar a la estación de servicio.
• Registro de vehículos: Componente encargado de registrar los vehículos en el sistema y
establecer conexión con las secretarías de tránsito.
• Tanqueo: Componente encargado de realizar el procedimiento del tanqueo.
• Proceso de pago: componente encargado de realizar todo el proceso de pago y de hacer
la comunicación con los sistemas y plataformas de pago externas.
• Generación de reportes: componente encargado de generar los reportes requeridos por
el gerente y de generar el comprobante de transacción para los conductores.
• Sistema de pagos: plataformas externas que usan los clientes para la realización del
pago por el servicio
• Bases de datos ST: base de datos a la que se conecta el sistema para poder completar el
registro de los vehículos.
• Servidor de base de datos: Servidor en el que reposara toda la información del sistema.
• Servidor de aplicaciones: servidor principal donde correrán todos los procesos
• mencionados en esta tabla, a excepción de los externos.

Descripción de los flujos:

1. El lector de placas toma la información y se la envía al componente encargado del
registro de los vehículos.
2. El componente Registro de vehículos hace uso de la base de datos para la consulta de la
placa.
3. El componente Registro de vehículos hace uso de la base de datos de la secretaría de
tránsito para la completar la información para el registro.
4. El componente Registro de vehículos le despliega una interfaz al conductor para
terminar el registro del vehículo.
5. El componente Tanqueo le despliega una interfaz al conductor para realizar el proceso.
6. El componente proceso de pago le despliega una interfaz al conductor para realizar el
proceso del pago y escogencia de la plataforma.
7. El componente proceso de pago hace uso de una interfaz de la plataforma de pago
seleccionada para continuar con el proceso.
 Arquitectura de Software

115
8. El componente Sistema de pagos le despliega una interfaz al conductor para que
realice su proceso de pago.
9. El componente Generación de reportes le despliega una interfaz al gerente para que
pueda realizar el pedido de los reportes que requiera.

Fuente: Neftaly Mora_Juan Carlos Herrera

Vista de comportamiento
Diagramas de secuencia

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

116
Nombre: CU-001 Registrar vehículo

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción:
Éste es el proceso encargado de registrar los vehículos nuevos en el sistema.

Actores: Conductor

Flujo del diagrama:

1) El conductor ingresa el vehículo a la estación de gasolina
2) EL lector escanea la placa y la envía al sistema (Placa)
3) El sistema consulta en la base de datos si la placa existe.
4) La base de datos hace la validación.
5) Devuelve el resultado de que la placa no existe en la base de datos.
6) El sistema hace la consulta en la base de datos de la secretaría de transito
7) con la placa del vehículo.
8) recibe la respuesta de la secretaría de tránsito y asocia la información a la
9) placa del vehículo para hacer el registro.
10) Le despliega la información al conductor en la interfaz para que acepte o
11) deniegue esta información.
12) El conductor confirma la información y adiciona o corrige la que sea requerida.
13) Se valida en el sistema la información aceptada por el conductor.
14) El sistema envía la información del registro del usuario a la base de datos
15) para ser almacenada.
16) La base de datos guarda la información.
17) 14. FIN

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

117

Fuente: Neftaly Mora_Juan Carlos Herrera.

Nombre: CU-002 Proceso de tanqueo

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción:
Aquí se describe el proceso en el que se escoge el tipo de tanqueo y la cantidad

Actores: Conductor

Flujo del diagrama:

1. El Sistema despliega la interfaz de tanqueo para el conductor.
2. EL conductor selecciona si quiere realizar el tanqueo por galones o por dinero.
3. El conductor el tipo de combustible a tanquear.
 Arquitectura de Software

118
4. El conductor selecciona la cantidad de combustible a tanquear.
5. El sistema toma los datos de la interfaz delo conductor y realiza el proceso de cobro.
6. El sistema genera el respectivo comprobante de pago con los datos.
7. Carga en la interfaz del conductor el comprobante de pago para aceptación y envía
también las diferentes opciones de pago para que el usuario seleccione la de su
preferencia.
8. FIN

Fuente: Neftaly Mora_Juan Carlos Herrera.

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

119
Nombre: CU-006 Proceso de pago

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción:

Proceso que describe al pago del servicio

Actores: Conductor

Flujo del diagrama:

1. El sistema carga el valor a pagar creado en la transacción de tanqueo.
2. El sistema genera el valor a pagar.
3. El sistema despliega el valor a pagar en la interfaz del conductor para que sea aprobada
por éste.
4. El conductor acepta el valor del pago.
5. El sistema recibe la aceptación del conductor y le despliega en la interfaz las las opciones
de pago que hay.
6. El conductor selecciona la aplicación y forma de pago que mas se acomode a sus
necesidades.
7. El sistema recibe la solicitud del conductor y hace el proceso de conexión con la
plataforma de pagos seleccionada enviando la solicitud de pago con el valor.
8. La plataforma seleccionada empieza la interacción directamente con el usuario y
comienza el proceso de autenticación para empezar la transacción.
9. El usuario interactúa con la plataforma de pagos y realiza el pago correspondiente.
10. La plataforma de pagos le genera el respectivo reporte del pago al usuario y también le
manda al sistema la comprobación del pago realizado.
11. El pago es aplicado en el sistema y asociado al conductor y dueño del vehículo.
12. El sistema genera el comprobante de la transacción y se lo envía al conductor
13. por medio de un correo electrónico.
14. FIN

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

120

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

121
Nombre: CU-007 Generación de Informes

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020

Descripción: Sistema de generación de reportes

Actores: Conductor / Gerente

Flujo del diagrama:

1. El gerente solicita al sistema el reporte de tanqueos realizados en un día.
2. El sistema procesa la solicitud de reporte del gerente
3. El sistema le devuelve al gerente el reporte con la información solicitada.
4. El gerente solicita al sistema el reporte de tanqueos realizados en un mes.
5. El sistema procesa la solicitud de reporte del gerente
6. El sistema le devuelve al gerente el reporte con la información solicitada.
7. El gerente solicita al sistema el reporte de los vehículos que más usan el servicio.
8. El sistema procesa la solicitud de reporte del gerente
9. El sistema le devuelve al gerente el reporte con la información solicitada.
10. El gerente solicita al sistema el reporte de la transacción realizada por un
determinado cliente en una determinada fecha.
11. El sistema procesa la solicitud de reporte del gerente
12. El sistema le devuelve al gerente el reporte con la información solicitada.
13. El sistema genera un comprobante de transacción al conductor cada que se hace una
transacción por tanqueo de combustible.
14. FIN

Fuente: Neftaly Mora_Juan Carlos Herrera.

 Arquitectura de Software

122
Vista Física
Diagrama de Despliegue

Fuente: Neftaly Mora_Juan Carlos Herrera.

Nombre: Diagrama de Despliegue

Autores: Neftaly Mora - Juan Carlos Herrera Camaño

Fecha: 14/05/2020
 Arquitectura de Software

123
Descripción de los componentes:
• Nodo Servidor de Aplicaciones: Representa los artefactos usados en este nodo
• Nodo Servidor de Base de Datos: Representa el artefacto usado para la base de datos
• Dispositivo Lector: Representa el artefacto que se usara para el lector
• Nodo Pc Cliente: Representa los artefactos que serán necesarios para la ejecución desde
el pc del cliente
• Nodo Tableta de Alto Rendimiento: representa los artefactos que serán usados
• Componente de Aplicación de Pagos Externa: Representa el artefacto de entidades de
pagos externas.
• Componente de Aplicación Consulta a Base de Datos Externas: Representa los
artefactos de las bases de datos de entidades externas.
• Dispositivos de Conexión o Acces Point: Representa los artefactos que permiten las
conexiones

Descripción de los componentes:

• Servidor DELL Power Edge T330 tower Server
• Sistema operativo Windows 2016 STD
• Procesador Intel Xeon E3 1230 v5 Quad Core 3.4GHz 8MB
• Memoria RAM de 32GB DDR4
• Almacenamiento de 16TB (4 x 4TB) HDD, PERC S130 RAID.
• Base de datos MySQL.
• Cámara NLGhost
• Internet Explorer 11, safari, Opera, Google Chrome 17+

Fuente: Neftaly Mora_Juan Carlos Herrera.

CONCLUSIONES DE LA PROPUESTA DE DISEÑO ARQUITECTÓNICO

Hemos concluido que la arquitectura de software nos permite razonar acerca de las decisiones
de diseño y atributos de calidad que deben estar presentes en el sistema que estemos diseñando.

Es importante tener en cuenta que las decisiones de diseño al momento de implementar un

patrón de arquitectura deberán estar debidamente alineados a la necesidad del proyecto que se
 Arquitectura de Software

124
vaya a desarrollar, las que servirán como guía a todo el equipo (usuarios informáticos y no
informáticos) debiendo ser debidamente documentadas y comunicadas de manera asertiva.

En cuanto a los atributos de calidad, éstos nos permiten determinar lo que va más allá de lo
funcional garantizando que el sistema funcione correctamente. Sabemos que existen muchos
atributos de calidad, donde se debe escoger cuidadosamente los requeridos garantizando su
correcto funcionamiento y la calidad del producto de software.

Es importante tener en cuenta que la arquitectura aplicada puede tener siempre distintos
elementos dependiendo de la persona, contexto o incluso la empresa encargada de revisar la
arquitectura. Esto irá en función de lo que quiera cada uno de los actores que intervengan, no es
lo mismo si lo mira el Product Owner, seguramente para él es muy importante que las
características que desea que tenga el sistema se evidencien en la arquitectura, si lo observa un
desarrollador, para él es importante por ejemplo las herramientas de desarrollo contempladas en
la arquitectura, ya que será relevante todo lo que la herramienta permita hacer. Para un usuario
final el punto de vista con seguridad sería otro, o para una persona de soporte que miraría más
la parte física de la arquitectura y los componentes de esta.

Teniendo en cuenta lo anterior podríamos decir que en la arquitectura hay muchos elementos
que son fundamentales y es que estos dependen del contexto, del equipo y las necesidades del
proyecto.

TIPS
La implementación de la arquitectura será la fase final de la
arquitectura de software, entregando así el insumo para la aplicación
de procesos técnicas y metodologías de ingeniería de software, para
el desarrollo de un software de calidad.
 Arquitectura de Software

125
4 PISTAS DE APRENDIZAJE

• Una buena arquitectura de software define el alcance del programa, ofrece pautas claras para
la construcción del software, reduce el riesgo, facilita la comunicación y aumenta la
rentabilidad.

• El Arquitecto de Software, deberá ser un líder, con gran capacidad de integrar equipos de
trabajo y amplios conocimientos administrativos y técnicos en temáticas relacionadas con la
tecnología informática.

• Antes de realizar un diseño arquitectónico, es necesario tener claro los requisitos funcionales
del software, los atributos de calidad que debe cumplir, así como sus restricciones.

• De una buena especificación de los Requisitos Funcionales y los Requisitos No Funcionales,

dependerá que la Arquitectura de Software se soporte sobre bases firmes

• Las características o atributos de calidad equivalen a los requisitos no funcionales (RNF) del
software, el usuario no los solicita, pero el experto (a) informático los debe incorporar.

• Tanto los requisitos funcionales, como los no funcionales y las restricciones son el insumo
para la conformación del DRIVER ARQUITECTÓNICO, a utilizarse en la primera etapa de la
Arquitectura de Software que corresponde a la etapa de los Requerimientos de la
Arquitectura.

• La reutilización de código corresponde a una técnica que se puede utilizar, sólo se debe
verificar si los componentes a utilizar son de uso libre o pago.

• El patrón Cliente-Servidor, permite optimizar procesos y recursos.

• El patrón por Capas permite estructuras el software en partes donde se establecen límites,
pero de igual forma permite realizar integraciones para conformar un todo funcional.

• El patrón Orientado a Servicios (SOA), favorece el uso de servicios de terceros que pueden ser
integrados a programas propios.

• Lo que hoy se constituye como última tecnología, mañana estará obsoleto.

 Arquitectura de Software

126
• Los requerimientos corresponden a la primera fase de la Arquitectura del Software y está
compuesta por los Drivers Arquitectónicos (Requisitos Funcionales, Requisitos No Funcionales
o de Calidad y las Restricciones).

• El diseño de la arquitectura permite visualizar la forma como definirá las estructuras tanto
físicas y lógicas para la construcción del software.

• Una buena documentación de la Arquitectura del software facilitará la comunicación entre

los diferentes usuarios (cliente-usuario final y expertos informáticos).

• La evaluación de la arquitectura permite realizar ajustes, especialmente en los atributos de

calidad.

• La implementación de la arquitectura será la fase final de la arquitectura de software,

entregando así el insumo para la aplicación de procesos técnicas y metodologías de ingeniería
de software, para el desarrollo de un software de calidad.
 Arquitectura de Software

127
5 GLOSARIO
• Arquitectura de Software: Corresponde a guías generales que basadas en los requisitos del
software, las características de calidad y las restricciones se diseñan con el fin de orientar el
proceso de ingeniería de software, en relación a su estructura física, lógica y dinámica.

• Características de calidad del software: Son atributos que deberá cumplir el software como
por ejemplo de seguridad, usabilidad, eficiencia, buscando con ello cumplir con requisitos de
calidad.

• Ciclo de vida: Son fases que se deben tener en cuenta para la realización de procesos, donde
integrados constituyen un producto o un servicio.

• Desarrollo de software: Consiste en la construcción de un producto de software, basado en

los requisito funcionales y no funcionales.

• Diseño de Comportamiento: Muestra la interacción de los diferentes componentes, a través

del flujo de información que va evolucionando a lo largo del proceso.

• Diseño Físico: establece el detalle de los componentes y configuraciones como por ejemplo
las máquinas y su distribución.

• Diseño Lógico: Se encarga de refinar organizar y detallar la especificación de como se quiere

que funciones el sistema.

• Driver Arquitectónicos: Corresponde a la primera fase del ciclo de vida de la arquitectura de

software, la cual se construye basada en los requisitos funcionales del software, las
características de calidad que se le desee aplicar al software y las restricciones del software.

• Guía de Usuario: Son instrucciones del cómo funcionan determinados componentes.

• Manual de procedimientos: Indica el paso a paso para desarrollar cualquier actividad.

• Patrón Cliente-Servidor: Es un modelo para el diseño de software, donde el servidor es el

proveedor de recursos y servicios y el cliente es quien demanda eso recursos y servicios, a
través de peticiones.

• Patrón Orientado a Servicios: SOA, acrónimo de Service-Oriented Architectures, que permite

integrar el software con sistemas ya existentes.
 Arquitectura de Software

128
• Patrón por Capas: Es un modelo que permite realizar una división del sistema, buscando con
ello que el diseño del software quede más entendible y fácil de manejar.

• Patrones de arquitectura de software: Equivale a una solución general que es reutilizable

para problemas similares. En la arquitectura de software se puede tomar un patrón o realizar
una mezcla de varios de ellos y dar solución de acuerdo con las necesidades del cliente.

• Patrones de diseño: Es un esquema o base para el diseño, al cual se le adiciona una serie de
elementos que integrados buscan solucionar una necesidad.

• Políticas: Se refiere a reglas, protocolos que son definidos para realizar los procesos.

• Requisitos de software: Son necesidades del cliente traducidas a una especificación de

software con el fin de buscar el desarrollo del software.

• Restricciones del software: Corresponde a limitaciones del software basadas en las

necesidades reales, teniendo en cuenta lo que debe hacer el software y hasta donde lo debe
hacer.

• Restricciones técnicas: indica los recursos, métodos, materiales y la forma como se debe
operar colocando límites para su manejo.
 Arquitectura de Software

129
6 BIBLIOGRAFÍA
Consultado de:
Este capítulo recomienda al estudiante las https://elibro.net/es/ereader/remington/56
fuentes de consulta bibliográficas y digitales 294
para ampliar su conocimiento, por lo tanto,
deben estar en la biblioteca digital de la • Carrillo, J. y Moreno, D. (2020), Normas APA
Remington. Utilice la biblioteca digital 7.ª edición. Guía de citación y referenciación.
http://biblioteca.remington.edu.co/es/ para Segunda versión revisada y ampliada 2020.
la consulta de bibliografía a la cual puede Consultado de:
acceder el estudiante. https://www.ucentral.edu.co/sites/default/f
iles/inline-files/guia-normas-apa-7-ed-2020-
FUENTES BIBLIOGRÁFICAS
08-12.pdf
• Amaya, Y. (2015), Guía metodológica ágil,
para el desarrollo de aplicaciones móviles • Cervantes, H., Velasco, P. y Castro, L. (2016).
“AEGIS-MD”. Consultado de Arquitectura de software. Conceptos y ciclo
https://www.researchgate.net/publication/ de desarrollo. ISBN: 978-607-522-456-5.
318353356_Guia_metodologica_agil_para_ Web:
el_desarrollo_de_aplicaciones_moviles_AEG https://www.researchgate.net/profile/Perla
IS-MD _Velasco-
Elizondo/publication/281137715_Arquitectu
• Anaya, R. (2012). Una visión de la enseñanza ra_de_Software_Conceptos_y_Ciclo_de_Des
de la ingeniería de software como apoyo al arrollo/links/57144e1408aeebe07c0641ab/
mejoramiento de las empresas de software. Arquitectura-de-Software-Conceptos-y-
Revista Universidad EAFIT, 42(141), 60-76. Ciclo-de-Desarrollo.pdf

• Balderas, P. Sánchez, G. (2015), Ingeniería de • Chavarría, A. y Bayona, S. y Pastor, C.

sistemas: metodologías y técnicas ISBN: (2016).Aseguramiento de la Calidad en el
9781512960723, 9786074028430 Editorial: Proceso de Desarrollo de Software utilizando
Plaza y Valdés, S.A. CMMI, TSP y PSP.
http://www.scielo.mec.pt/pdf/rist/n20/n20
• Callejas, M. Alarcón, A. Álvarez, A. (2017), a06.pdf
Modelos de calidad del software, un estado
del arte. Consultado de • Clements, Paul. Documenting Software
http://www.scielo.org.co/pdf/entra/v13n1/ Architectures: Vers and Beyond. (2011).
1900-3803-entra-13-01-00236.pdf Edición 2. Addison-Wesley.

• Campderrich, B. 2013, Ingeniería de • Corporación Universitaria Remington. (2020)

software. Editorial UOC. Base de Datos. Web:
ISBN: 9788490292570, 9788483189979.
 Arquitectura de Software
sfs

130
http://biblioteca.uniremington.edu.co/index • ISO/IEC 25000, (2014).La familia de normas
.php/login ISO/IEC 25000. Web:
https://iso25000.com/index.php/normas-
• Dolors, C. Ribera, S. Teniente, E. (2015), iso-25000
Especificación de sistemas software en UML
ISBN: 9788498801163 Editorial: Universitat • ISO/IEC 25010 (2016), Calidad del producto
Politècnica de Catalunya de software.
https://iso25000.com/index.php/normas-
• Echeverri, J. Aristizábal, M. González, L. iso-25000/iso-25010?limit=3&start=6
(2013).Reflexiones sobre ingeniería de
requisitos y pruebas de software. • Muñoz Periñán, I. L., & Gómez Arenas, L. D. S.
ISBN: 9789585807037. (2011). Vista ampliada para Gerencia de
Editorial: Corporación Universitaria Proyectos usando mejores prácticas del
Remington. Consultado de: PMBok® cuarta edición y CMMI®-SVC V. 1.2
https://elibro.net/es/ereader/remington/68 nivel de capacidad o madurez.
913?col_q=Ingenier%C3%ADa__de__Softwa
re&col_code=ELC004&prev=col • Pressman, R. (2010). Ingeniería del Software
7ed. un enfoque práctico.
• Eduardo Diez (2014. )Aseguramiento de la ISBN:9786071503145. Consultado de:
Calidad en la Construcción de Sistemas http://cotana.informatica.edu.bo/download
Basados en el Conocimiento: Un Enfoque s/ld-
Práctico. Consultado de Ingenieria.de.software.enfoque.practico.7ed
https://www.researchgate.net/publication/ .Pressman.PDF
285138688_Aseguramiento_de_la_Calidad_
en_la_Construccion_de_Sistemas_Basados_ • Pressman. Roger S. Ingeniería de Software,
en_el_Conocimiento_Un_Enfoque_Practico Un enfoque práctico. (2010). Edición 7.
Editorial McGraw Hill.
• IEEE Computer Society (2004). SWEBOK -
Guide to the Software Engineering Body of • Reinoso, Carlos Billy. Introducción a la
Knowledge, 2004. (Capítulos 4 y 5) Arquitectura de Software. (2004). Versión 1.
http://www.swebok.org/ Universidad de Buenos Aires.

• IEEE Computer Society, (2014), SWEBOK • Rodríguez, M. Pino, F. (2018). Modelo de

(Guide to the Software Engineering Body of madurez de ingeniería del software Versión
Knowledge), Version 3.0. ISBN-10: 0-7695- 2.0 (MMIS V.2). ISBN: 9788481439731,
5166-1. Web: 9788481439748. Editorial: AENOR -
http://artemisa.unicauca.edu.co/~cardila/S Asociación Española de Normalización y
WEBOKv3.pdf Certificación. Consultado de:
https://elibro.net/es/ereader/remington/53
627?col_q=Ingenier%C3%ADa__de__Softwa
re&prev=col&col_page=2&col_code=ELC004
 Arquitectura de Software
sfs

131
• Rozanski, N., Woods, E. Software Systems
Architecture. (2005). Editorial Addison-
Wesley. Software Engineering Institute,
(2019). architect of software.
https://www.sei.cmu.edu/search.cfm#stq=a
rchitect%20of%20software&stp=1

• Sevilla, G. Zapata, S., Torres, E. (2016)

Modelo de Proceso de Ingeniería de
Requisitos de Software Distribuida. Web:
https://www.researchgate.net/publication/
311427586_Modelo_de_Proceso_de_Ingeni
eria_de_Requisitos_de_Software_Distribuid
a

• Sommerville, Ian. Ingeniería de Software.

(2011). Edición 9. Editorial Pearson
Education.

• UAH (2015). Arquitectura Orientada a

Servicios. Consultado de:
https://ingenieriadelsoftwareuah2015.word
press.com/2015/03/22/arquitectura-
orientada-a-servicios-soa/

• Zapata, J. Mercado, V., Ceballos, Y.

Herramientas y buenas prácticas para el
aseguramiento de calidad de software con
metodologías ágiles. Web:
https://www.researchgate.net/publication/
299497505_Herramientas_y_buenas_practi
cas_para_el_aseguramiento_de_calidad_de
_software_con_metodologias_agiles