Universidad Abierta y a Distancia de México

Ingeniería en Desarrollo de Software

Diseño y Arquitectura de Software

Unidad 1

VISTAS DE LA ARQUITECTURA DE SOFTWARE

Luis Fernando Francisco Peterson Aragón

Matrícula ES1822023565

Docente: Javier Armando Gutiérrez Hernández

Octubre, 2021

Hermosillo, Sonora

Índice

Contenido Página
Índice 1

Introducción 2

Desarrollo 3

Conclusiones 8

Referencias Bibliográficas 9

Introducción

La Asignatura Diseño y Arquitectura de Software busca desarrollar la competencia para

diseñar una arquitectura de software para establecer las bases del desarrollo de un
sistema que cubra las necesidades del usuario mediante el uso de patrones de
arquitectura de software.
La Unidad 1 tiene el propósito de desarrollar la competencia para analizar las
herramientas de arquitectura de software para identificar su importancia y ubicación en el
proceso de diseño de una aplicación mediante la relación entre las vistas, UML y los
lenguajes descriptores de arquitectura.

La actividad 3 pretende identificar los modelos de vistas de arquitectura más importantes.

Para ello, y a partir de un caso de estudio planteado se identifican y ejemplifica el uso de
vistas.

Este trabajo incluye los resultados del análisis del caso, el objetivo del sistema,
requerimientos funcionales y no funcionales y posible área de oportunidad en el que se
inserta el sistema. Se identifican y explican las vistas del Modelo Microsoft: lógica,
conceptual y física incluyendo los diagramas que emplean en cada una.

Asimismo se añaden conclusiones y las referencias bibliográficas consultadas.

Desarrollo

1. Analiza el caso de estudio “Profeco” (lo ubicas al final de este documento)

proporcionado por el docente en línea.

2. Identifica los siguientes aspectos:

 Objetivo del sistema.

Desarrollar un sistema que automatice el proceso de atención de reclamos y quejas.

 Requerimientos funcionales y no funcionales.

 Área de oportunidad en el que se inserta el sistema.

3. Identifica las vistas del Modelo Microsoft: lógica, conceptual y física. Debes de incluir
definición, cuatro características por cada vista y los diagramas que se utilizan en cada
una.

Vista lógica. Apoya principalmente los requisitos funcionales, lo que el sistema debe
brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie
de abstracciones primarias, tomadas principalmente del dominio del problema en la forma
de objetos o clases de objetos. Aquí se aplican los principios de abstracción,
encapsulación y herencia. Esta descomposición no sólo se hace para potenciar el análisis
funcional, sino también sirve para identificar mecanismos y elementos de diseño comunes
a diversas partes del sistema. Los diagramas UML que se utilizan para representar esta
vista son los Diagrama de Clase, Diagrama de Comunicación, Diagrama de Secuencia.

Vista conceptual. Se describe el sistema en términos de sus elementos principales de

diseño y las relaciones entre éstos, dentro de un dominio determinado. Esta vista es
independiente de las decisiones de implementación y enfatiza en los protocolos de
interacción entre los elementos de diseño. Utiliza el Diagrama de Paquetes, Diagrama de
Componentes y Diagrama de Actividad.

Vista física. Describe el sistema desde el punto de vista de un ingeniero de sistemas. Está
relacionada con la topología de componentes de software en la capa física (hardware), así
como las conexiones físicas entre estos componentes. Se toma en cuenta los requisitos
no funcionales del sistema tales como, disponibilidad, confiabilidad, desempeño entre
otras más. El sistema se ejecuta sobre varios nodos de procesamiento (hardware). Estos
nodos son relacionados con los elementos identificados de las vistas anteriores. En esta
vista se especifican varias configuraciones físicas. Por ejemplo, una para el desarrollo y
las pruebas, o para el despliegue del sistema en plataformas distintas. En UML se utiliza
el Diagrama de Despliegue y/o de implementación

4. Explica con base en el caso de estudio las tres vistas identificadas. Utiliza mínimo seis
líneas para desarrollar cada vista.

 Vista lógica
 Para proporcionar una base para comprender la estructura y la organización del
diseño del sistema, se usa esta vista en el flujo de trabajo de análisis y diseño.
Solo existe una vista lógica del sistema, que ilustra las realizaciones de guiones de
uso clave, subsistemas, paquetes y clases que abarcan el comportamiento
significativo arquitectónicamente. La vista lógica se perfecciona durante las
iteraciones.
 Vista conceptual
Esta guiada en gran medida por los requerimientos funcionales y no funcionales
que debe cubrir el sistema y normalmente se toma el subconjunto más importante
arquitectónicamente de dichos requerimientos para definirla.
 Vista física
Nos muestra la distribución del procesamiento entre los distintos equipos que
conforman la solución, incluyendo los servicios y procesos de base. Los elementos
definidos en la vista lógica se “mapean” a componentes de software (servicios,
procesos, etc.) o de hardware que definen más precisamente como se ejecutará la
solución.

5. Ejemplifica con base en el caso de estudio (diseño de diagramas) las vistas

identificadas: lógica, conceptual y física. TE PIDE HACER LOS DIAGRAMAS

a. Los diagramas deben diseñarse con software especializado (Microsoft Visio o

alguna aplicación en línea).

b. Es necesario enviar los archivos fuente de los diagramas. Si se omite el envío

del archivo fuente, la actividad será evaluada con 1 y contará como un intento.

c. No se permiten imágenes tomadas de Internet, si esta es tomada de Internet, la

actividad será evaluada con 1 y contará como un intento

Caso:

Descripción
El organismo federal denominado “Profeco” desea un sistema para administrar las quejas
que recibe por parte de los ciudadanos mexicanos. Al titular de la dependencia,
administradores y quejosos les interesa tener acceso al sistema.

 Titular. Podrán acceder desde cualquier lugar.

 Administradores. Podrán acceder únicamente en las instalaciones de la dependencia.

 Clientes. Podrán acceder desde cualquier lugar utilizando una app.

El titular de la dependencia y los administradores deben de acceder con todos los

privilegios.

 Pueden ver información de todos los quejosos: fecha de presentación de la queja,

descripción de la queja, empresa de la cual se queja, Estado de la república, escolaridad,
etcétera.

 Lista de empleados.

 Reportes.

 Estadísticas.

Los quejos podrán dar seguimiento a su queja vía Web:

 Estado de la queja.

 Personal quien está a cargo de la queja.

 Trámite que ha tenido la queja.

Considera que el software, de manera general debe:

 Administrar la información del personal de la institución y la de los quejosos.

 Administrar privilegios de usuarios con acceso al sistema.

 Historial de accesos y peticiones de quejas.

 Gráficas.

OBJETIVO GENERAL
Desarrollar un sistema para administrar las quejas que se reciben por parte de los ciudadanos
mexicanos.

REQUERIMIENTOS DEL SISTEMA

 Requerimientos funcionales (RF)

RF-1: El sistema permitirá el inicio de sesión de los usuarios, teniendo en cuenta el tipo de
usuario (titular, administrador o cliente).
RF-2: El sistema permitirá que el usuario tipo titular pueda acceder desde cualquier sitio.
RF-3: El sistema permitirá que el usuario tipo administrador pueda acceder únicamente
desde las instalaciones de la dependencia.
RF-4: El sistema permitirá que los usuarios tipo clientes puedan acceder desde cualquier
lugar haciendo uso de la aplicación.
RF-5: El sistema permitirá que usuarios tipo cliente puedan llenar un formulario para el
registro de una nueva queja.
RF-6: El sistema permitirá que los usuarios tipo cliente puedan dar seguimiento a su queja
(ver estado de la queja, personal a cargo de la queja, trámite que ha tenido la queja, etc.)
RF-7: El sistema permitirá que los usuarios tipo titular y tipo administrador puedan ver la
información de los clientes (estado de la república, escolaridad, etc.)
RF-8: El sistema permitirá que los usuarios tipo titular y tipo administrador puedan ver la
información de las quejas realizadas por los clientes (fecha en la que se realizó la queja,
descripción de la queja, empresa de la cual se queja, etc.)
RF-9: El sistema permitirá que los usuarios tipo titular y tipo administrador puedan ver la
lista de empleados.
RF-10: El sistema permitirá que los usuarios tipo titular y tipo administrador puedan
generar reportes acerca de las quejas realizadas.
RF-11: El sistema permitirá que los usuarios tipo titular y tipo administrador puedan
generar estadísticas sobre las quejas realizadas.
RF-12: El sistema debe administrar la información del personal de la institución y la de los
clientes.
RF-13: El sistema debe administrar los privilegios de usuarios con acceso al sistema.
RF-14: El sistema debe generar historial de accesos y peticiones de quejas.
RF-15: El sistema debe generar gráficas de las estadísticas de las quejas realizadas.

 Requerimientos no funcionales (RNF)

RNF-1: La información manejada por el sistema está protegida de acceso no autorizado y
divulgación.
RNF-2: Facilidad de acceso y uso.
RNF-3: Interfaz de usuario debe ser constante y consistente.
RNF-4: Presentar una documentación detallada del sistema.
RNF-5: Elaborar el manual de usuario del sistema.
RNF-6: El sistema sólo debe conectar a un gestor de base de datos determinado.
RNF-7: La información registrada de las quejas debe permanecer histórica.

ÁREA DE OPORTUNIDAD
La implementación del sistema busca que el área de atención a clientes, en conjunto con las
demás áreas que conforman la PROFECO puedan atender las quejas de forma rápida y eficiente.

Los beneficiarios de este sistema son los clientes, que son quienes contarán con un sitio donde
registrar sus quejas. Además, otro beneficiario son los usuarios de la PROFECO, puesto que este
sistema les permitirá agilizar el proceso de atención de las quejas realizadas por los clientes.

VISTA LÓGICA

DIAGRAMA DE CLASES

Fuente: Elaboración propia

VISTA CONCEPTUAL

Diagrama de Componentes
 Fuente: Elaboración propia

VISTA FÍSICA

Diagrama de Despliegue

Fuente: Elaboración propia

Conclusiones

No es algo nuevo que ninguna definición de la Arquitectura de Software es respaldada

unánimemente por la totalidad. Clements da la siguiente definición reconocida: “La AS es,
a grandes rasgos, una vista del sistema que incluye los componentes principales del
mismo, la conducta de esos componentes según se la percibe desde el resto del sistema
y las formas en que los componentes interactúan y se coordinan para alcanzar la misión
del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de
comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las
abstracciones.”

Los modelos arquitectónicos nos proporcionan una vista de alto nivel de los componentes
que integrarán el sistema, puesto que una sola vista nos puede dar toda la información
que se requiere para todos los miembros del equipo de desarrollo.

En términos generales, una vista es un subconjunto resultante de practicar una selección

o abstracción sobre una realidad, desde un punto de vista determinado.

Referencias Bibliográficas

https://repositorio.tec.mx/bitstream/handle/11285/619520/Tesis_Angel%20Luis%20Rivera
%20Landa.pdf?sequence=1&isAllowed=y

Gómez, O. (2021). Documentando la arquitectura de software. Recuperado de

http://www.osgg.net/omarsite/resources/papers/doc_arch.pdf

http://carlosreynoso.com.ar/archivos/carlos-reynoso-introduccion-a-la-arquitectura-de-
software.pdf

https://repositorio.unp.edu.pe/bitstream/handle/20.500.12676/2296/INF-CHA-FER-ING-
2020.pdf?sequence=1&isAllowed=y