Análisis de la Arquitectura de Sistemas

1. UNIVERSIDADESTATAL DE BOLIVAR
FACULTAD DE CIENCIAS ADMINISTRATIVAS GESTION
EMPRESARIAL E INFORMATICA
ASIGNATURA: ARQUITECTURA DE SOFTWARE
TEMA: ANÁLISIS DE LA ARQUITECTURA DE
SISTEMAS
ESTUDIANTES: JOHANA GONZALEZ-OSCAR
ALAVA-JOEL YANZA-FREDY CHAVEZ
PERIODO ACADEMICO: NOVIEMBRE 2022-
MARZO 2023

2. 1. Introducción
El análisis de arquitectura se centra en definir arquitecturas
candidatas y limitar las técnicas arquitectónicas utilizadas en el
sistema. Restringe y centraliza la arquitectura para que los
esfuerzos no se desperdicien en redescubrirla en base a una
colección de experiencias adquiridas en sistemas o dominios de
problemas similares. El análisis de arquitectura se puede omitir
para los sistemas que ya tienen una arquitectura bien definida.

3. 2. OBJETIVO DE LA
PRACTICA
Definir una arquitectura candidata para el sistema basada en la
experiencia obtenida de sistemas similares o dominios de
problemas parecidos.
Definir los patrones de arquitectura, los mecanismos clave y los
convenios de modelado del sistema.

4. 3. Descripción del
desarrollo de la práctica:

5. 3.1.Descripcion general de la arquitectura de desarrollo
El modelo arquitectónico a emplearse para el sistema web AUTOREP es el modelo 4+1 puesto que este se
adapta más a este proyecto, es fácil de entender y diseñar la arquitectura de desarrollo del sistema de
manera más clara y sencilla.
La vista lógica representa la funcionalidad que el sistema proporcionará a los usuarios finales.
La vista de despliegue muestra cómo están organizados los diferentes módulos y componentes del
sistema desde el punto de vista del desarrollador
La vista de procesos que como su nombre lo indica muestra cada uno de los procesos que hay en el
sistema y la forma en que se comunican.
La vista física puede mostrar cómo están distribuidos los componentes del sistema en términos de
hardware y redes
La vista de escenarios que une y relaciona las otras 4 vistas detalladas anteriormente.

6. 3.2.Inspeccionar los activos disponibles
Los activos cumplen básicamente tres necesidades:
La recopilación de artefactos para solucionar un problema
La manipulación y reciclaje o reúso en diversos contextos
Ser duraderos en el tiempo, transformables y personalizables en ejecución.
Es por esta razón que para tener una buena gestión de los activos que son necesarios en este
proyecto, se llevó a cabo un registro actualizado y exacto de todo el software y hardware
utilizado

7. 3.3.Identificar abstracciones clave
Para representar e identificar las abstracciones claves del sistema de los autorrepuestos “AUTOREP”, se
representará mediante diagrama de clases .

8. 3.4. Identificar iteraciones estereotipadas
Para ello se desarrolla el siguiente diagrama de secuencia que explica de mejor manera este paso:

9. 3.5. Desarrollar una visión general de la implementación
En este apartado se incluye el diagrama de implementación, proceso el cuál se lleva a cabo durante la
última fase del desarrollo de la arquitectura después de haber definido la estructura y todos los
componentes que conforman la arquitectura del proyecto AUTOREP.
Para el proyecto de tienda de repuestos de autos en línea, este sistema está diseñado para que el
usuario pueda acceder de manera remota.
El usuario accede al sistema de manera manual y realizará el pedido de repuestos de auto, que será
procesado una vez que el usuario haya pagado el valor asignado.

10. 3.6. Identificar mecanismos de análisis
En el presente proyecto AUTOREP, se realizan diferentes actividades centrándose en la creación de
artefactos de modelado de software y aplicación de patrones, estos permitirán obtener una vista
completa de los requisitos que necesita el usuario. El presente proyecto AUTOREP, tendrá diferentes
actividades:
Para la calidad del proyecto arquitectónico se revisarán la relación de escenarios y los atributos de
calidad.
El desarrollo se concentra en una escala de niveles, este sistema se descompone en subsistemas
conceptuales, identificando los estilos y patrones arquitectónicos, mejorando el diseño, previendo
una mejor viabilidad de este.
Una vez que se ha hecho la descomposición y llegado a nivel de componentes conceptuales se
podrán descomponer concretamente los elementos representados en el diseño arquitectónico.
En los escenarios se generaron varias arquitecturas y se selecciona una arquitectura adecuada para
el proyecto AUTOREP.

11. Análisis de requerimientos.
Arquitectura y tecnología.
Diseño de la estructura lógica y física del sitio web.
Creación de contenidos.
Diseño gráfico.
Creación de páginas estáticas.
Creación de páginas dinámicas.
Verificación del funcionamiento del sitio.
Puesta en marcha.
4. Metodología
Para el presente proyecto de una tienda en línea de repuestos de autos, la metodología que se aplica es
la expuesta por (Garcia, 2015), en su bloc personal en la que este cita la metodología de Luján (2002) la
misma que afirma que para desarrollar sitios web de una manera fácil y rápida se aplican los siguientes
pasos:

12. El concepto de arquitectura de software se refiere a la estructuración del
sistema que, idealmente, se crea en etapas tempranas del desarrollo. 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(Cervantes 2021).
5. ARQUITECTURA PROPUESTA PARA EL SISTEMA AUTOREP

13. Una vez que hemos definido lo que es arquitectura del software,
pasamos a describir el sistema web denominado AUTOREP, que
consiste en una tienda online para repuestos de vehículos, que
busca desarrollar e implantar un stock variados de repuestos de
varias marcas de autos, tendrá una pagina de inicio en la que el
usuario podrá visualizar algunas opciones como catalogo de
productos, un apartado donde podrá registrarse y otro para
contactos.
Aquí la arquitectura que mas se acomoda a las necesidades de
este proyecto es la del modelo arquitectónico de 4+1 de
5. ARQUITECTURA PROPUESTA PARA EL SISTEMA AUTOREP

14. El modelo “4+1” de Kruchten, es un modelo de vistas diseñado por el
profesor Philippe Kruchten y que encaja con el estándar “IEEE 1471-
2000” (Recommended Practice for Architecture Description of Software-
Intensive Systems) que se utiliza para describir la arquitectura de un
sistema software intensivo basado en el uso de múltiples puntos de
vista(Moya 2012)
5. MODELO 4+1

15. Es aquella que representa la funcionalidad que el sistema
brinda a los usuarios finales, es decir lo que el sistema
debe de hacer, las funciones y servicios que ofrece. Para
poder documentar esta vista se emplean los diagramas de
clases, de comunicación o de secuencia de UML.
5.1. VISTA LOGICA

16. Esta vista se muestra desde la perspectiva de un programador y
se ocupa de la gestión del software. Para documentar esta vista se
incluyen los diagramas de componentes y de paquetes UML.
5.2. VISTA DE DESPLIEGUE

17. Se muestran los proceso que hay en el sistema y la manera de como se
comunican entre estos. Se representa desde la perspectiva de un
integrador de sistemas. Para documentar esta vista se pueden emplear los
diagramas de actividad de UML.
5.3. VISTA DE PROCESOS

18. Esta vista se representa desde la perspectiva de un ingeniero en
sistemas/software, todos los componentes físicos del sistema así como las
conexiones físicas entre los componentes. Para documentar se incluyen
los diagramas de despliegue de UML.
5.4. VISTA FISICA

19. Esta vista tiene la función de unir y relacionar las otras 4 vistas entre si,
para ello se documenta utilizando los diagramas de casos de usos de UML,
los cuales permiten visualizar la manera de como se van ligando las otras 4
vistas.
5.5. VISTA DE ECENARIOS

21. 6.CONCLUSIONES
Podemos concluir que la arquitectura de software
proporciona una visión general de la arquitectura del
sistema de software.
El análisis de la arquitectura nos ayuda a definir los patrones
de arquitectura, los mecanismos clave y los convenios de
modelado del sistema.

22. 7. RECOMENDACIONES
Es importante investigar ejemplos relevantes al proyecto que estamos
desarrollando, ya que esto nos puede proporcionar nuevas ideas y mejoras en la
arquitectura que ya hemos planteado. Además, podemos aprovechar el
conocimiento y experiencia de otros autores para adaptarlo a nuestro proyecto
de repuestos y mejorar el diseño del sistema.
Es considerable saber que el arquitecto debe tener una visión global del proceso
e incluso del producto final, saber en qué aspectos se puede ahorrar gastos.

23. 8. BIBLIOGRAFIA
Garcia, G. (2015). Metodologia de desarrollo de sitios web. Obtenido de Naps
tecnologia y educacion: https://naps.com.mx/blog/metodologia-de-desarrollo-de-
sitios-web/
IBM Corp. (2006). Tool mentor: Performing architectural analysis using rational
software development platform. Egov.Bg.
http://deg.egov.bg/LP/tech.rsa/guidances/toolmentors/performing_architectural_
analysis_using_rsa_E610F162.html
Moya, R.(2012).Modelo 4+1de kruchten.Jarroba. Recuperado de:
https://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/
Garcia, F.(2020).Arquitectura del software: Concepto, Bases e Importancia. Arsys.
Recuperado de: https://www.arsys.es/blog/arquitectura-software

24. Gra
cia
s