Está en la página 1de 12

FACULTAD DE CIENCIAS EMPRESARIALES

Trabajo integrador: Arquitectura de software

→ INTEGRANTES:
o Martin Marcelo Félix-Diaz Mija
o Roberto Alejandro Cedano Lucar
o Jhon Kerlyn Torrejon Vargas
→ CURSO: Arquitectura de software

→ DOCENTE: Roberto Oberto Giancarlo Castillo Monzón

→ CARRERA: Ing. de Sistemas Empresarial

LIMA- PERÚ

Índice
I. Marco teórico
II. Arquitectura
a. Diagramas
b. Detalle de artefactos y tecnología
III. Selección de herramienta de software (usa la arquitectura
seleccionada).
IV. Propuesta de mejoras
V. Conclusiones y recomendaciones
VI. Bibliografía

I. Marco teórico
A. Antecedentes:
Una arquitectura de software se selecciona y diseña con base en objetivos
(requerimientos) y restricciones. Los objetivos son aquellos prefijados para el
sistema de información, pero no solamente los de tipo funcional, también
otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción
con otros sistemas de información. Las restricciones son aquellas
limitaciones derivadas de las tecnologías disponibles para implementar
sistemas de información”. El origen del estudio se remonta al año 1960.
En 1968 “Edsger Dijkstra, propuso que se estableciera una estructuración
correcta de los sistemas de software antes de lanzarse a programar,
escribiendo código de cualquier manera”.
En 1972, Parnas publicó un ensayo en el cual discernir sobre la forma en que
la modularidad en el diseño de sistemas podría mejorar la flexibilidad y el
control conceptual del sistema, acortando los tiempos de desarrollo. De esta
manera se introduce el concepto de ocultamiento de información (information
hiding), siendo unos de los principios del diseño de software aún en la
actualidad.
En 1975, Brooks, el diseñador del sistema operativo OS/360 y Premio Turing
2000, comenzó a utilizar el concepto de arquitectura del sistema para
designar “la especificación completa y detallada de la interfaz de usuario”
aludiendo desde ese momento, que el arquitecto es un agente del usuario
(Jr. 1975). Por otro lado, también distinguía entre arquitectura e
implementación; mientras aquella decía qué hacer, la implementación se
ocupa de cómo.
La gestión de sistemas complejos es uno de los retos que debe afrontar la
Ingeniería del Software actual. Además, el mundo real cambia y los sistemas
deben adaptarse a él para seguir siendo útiles. Por esta razón, los ingenieros
de software deben encontrar técnicas y herramientas que le permitan adaptar
los sistemas de manera sencilla. Sin embargo, los métodos tradicionales
(métodos estructurados o paradigmas orientados a objetos) sólo permiten
una reconfiguración y adaptación parcial de los mismos.
Desde entonces, la POA y otras técnicas, centradas en la modularización del
código transversal, se agruparon bajo el nombre de Separación Avanzada de
Intereses (o en su denominación inglesa Advanced Separation of Concerns).
La idea es extraer el código relativo a los crosscutting concerns (concerns –
intereses o propiedades- que capturan requisitos y cruzan varios módulos del
sistema AOSD) que está disperso a lo largo del mismo, en módulos
independientes. Esta separación evita el código enmarañado (tangled) y
permite la reutilización de los aspectos.
En diversos trabajos de investigación, los aspectos se consideran como una
parte importante del proceso de desarrollo de los sistemas complejos y
proponen técnicas para extraerlos de una manera efectiva (como
Composition Filters [BeAk01], AspectJ [Kic+01], Adaptive Programming
[LicOr Ov01], Hyper J [OsTa 00], etc.). Muchas de estas aproximaciones
orientadas a aspectos (OA) se centran en la especificación y extracción de
aspectos durante el diseño detallado o en el nivel de implementación,
prestando menos atención al impacto de los aspectos en las primeras fases
del ciclo de vida. En 2002 se popularizó el nombre de “Desarrollo de
Software Orientado a Aspecto” (DSOA) para referirse a las técnicas y
tecnologías de modularización de los crosscutting concerns a lo largo del
ciclo de vida.
Por otra parte, los nuevos métodos de la ingeniería del software consideran a
la arquitectura del software como una parte importante de la etapa de diseño:
la arquitectura del software es una actividad que ayuda a los desarrolladores
a controlar la complejidad de los sistemas y a definir sus estructuras de modo
que su mantenimiento y evolución sean sencillos. Esto es así porque durante
esta etapa, se define la estructura de un sistema como un conjunto de
componentes que describen la funcionalidad del sistema a alto nivel y se
conectan a través de un conjunto de conectores arquitectónicos.
Durante la arquitectura del software se lleva a cabo la definición estructural
del sistema; la conveniencia de definir un diseño arquitectónico orientado a
aspectos surge cuando se observa que los crosscutting concerns atraviesan
también los componentes arquitectónicos de modo que el diseño final es
complejo. Además, considerar los aspectos en esta fase facilita la gestión de
la evolución del sistema. Esto es así porque durante el diseño arquitectónico
los aspectos se pueden considerar como artefactos software. En este
sentido, diversas propuestas consideran los aspectos arquitectónicos como
artefactos de distinto tipo: componentes, conectores, slices, vistas… Una
consideración a tener en cuenta en el desarrollo de las arquitecturas del
software OA es cómo expresarlas. Han habido varias propuestas para
desarrollar sistemas OA a lo largo del ciclo de vida y en particular durante la
fase del diseño arquitectónico, pero sólo algunas de ellas proporcionan un
soporte lingüístico. Es necesario dotar a los sistemas OA de un soporte
formal, igual que se hace en las propuestas de desarrollo de sistemas
convencionales, particularmente durante su definición estructural. Por tanto,
igual que los sistemas ordinarios se describen en esta etapa mediante
lenguajes de descripción arquitectónica (LDA), los sistemas OA deberían
expresarse también mediante LDA adecuados. Sin embargo, los LDA
convencionales no permiten al diseñador representar adecuadamente los
sistemas orientados a aspectos.

B. Bases Teóricas:
¿Qué es esta arquitectura?
El WorldShip es un software de envíos a escala global compuesta de
funciones completas y basado en windows; es decir, que está disponible en
todos los idiomas alrededor del mundo. Esto puede agilizar los procesos
comerciales conectándolo a sus sistemas empresariales. Mediante las
integraciones ODBC y XML, WorldShip puede importar información de sus
sistemas empresariales y bases de datos críticos, y exportar los detalles del
envío.
La aplicación de WorldShip le puede ofrece diversas opciones como obtener
la información requerida para generar etiquetas de envío. También que
puede importar un directorio y administrar direcciones para simplificar el
ingreso de detalles de direcciones de destinatarios. Si establece conexión
con un archivo de datos, puede extraer información completa de archivos de
cada pedido independiente o de un lote. Incluso puede automatizar la
generación de etiquetas al indicar a WorldShip la frecuencia para buscar
nuevos envíos.
Esto se puede aplicar para aquellos que necesitan envíar más de 10
paquetes al día, necesitan acceso al paquete completo de servicios de UPS ®
o requieren funciones específicas de software, como los perfiles de informes
y envío integrados.

C. Definiciones:
Para llegar a la arquitectura de software ,se tuvieron que basar en otros
conceptos y temas para que se tuviera una perfecta idea del tema y lograr su
desarrollo como son los siguientes:

● Ingeniería de software
La ingeniería de software es el establecimiento y uso de principios
fundamentales de la ingeniería con objeto de desarrollar en forma económica
software que sea confiable y que trabaje con eficiencia en máquinas
reales.La meta de la ingeniería de software moderna es “desarrollar
metodologías que se basen en el concepto de evolución; es decir, el
concepto de que los sistemas de software cambian continuamente, que los
nuevos sistemas de software se desarrollan a partir de los antiguos y que
todo debe operar entre sí y cooperar con cada uno de los demás”.

● Microservicios
Como lo definen James Lewis y Martin Fowler en su artículo: Microservices,
“es una forma particular de diseño de aplicaciones de software como suites
de servicios desplegadas independientemente”.
Patrón básico de arquitectura de Microservicios
La arquitectura de Microservicios es un enfoque de desarrollo de una
aplicación como un conjunto de servicios más pequeños, cada uno se
ejecuta en su propio proceso y se exponen, normalmente, a través de
protocolos HTTP mediante APIs REST. Estos servicios están construidos
alrededor de capacidades o funcionalidades de negocio y con independencia
de despliegue a través de un sistema de automatización. Además, pueden
estar escritos en diferentes lenguajes de programación y utilizar diferentes
tecnologías de almacenamiento de base de datos.

● Software Service Oriented Architecture (SOA)


Estilo de Arquitectura de Software a partir del cual es posible construir
aplicaciones distribuidas que cumplen con determinadas características
establecidas en el mismo. SOA es un paso más en la evolución de los
paradigmas de desarrollo de software para proveer soluciones a las
necesidades de las Organizaciones actuales, en aspectos como
interoperabilidad de aplicaciones desarrolladas con distintas tecnologías,
reutilización de conocimiento, diseño y código existente en la misma
Organización o fuera de ésta, y enfoque de desarrollo basado en el Negocio,
esto es, en los procesos del Negocio que realiza la Organización para
alcanzar sus objetivos estratégicos, ayudando a cerrar la brecha que en
general existe entre las áreas del Negocio y de Tecnología Informática.
Capa de servicios entre los procesos del Negocio y las tecnologías de
información

● Business Process Management (BPM)


Que trata con la gestión de los procesos del Negocio en una Organización,
incluyendo definición, monitoreo de su desempeño y mejora, para cumplir
con los objetivos del negocio definidos. Con los objetivos de lograr
interoperabilidad y portabilidad de aplicaciones desarrolladas con distintas
tecnologías, y reutilización de conocimiento, diseño y código existente.

● Model Driven Architecture (MDA)


El cual se relaciona también con el enfoque SOA en la obtención de
aplicaciones con las características definidas. Uno de los principales
objetivos de MDA es separar el diseño de la arquitectura y de las tecnologías
de construcción, facilitando que el diseño y la arquitectura puedan ser
alterados independientemente. El diseño alberga los requerimientos
funcionales (casos de uso), mientras que la arquitectura proporciona la
infraestructura a través de la cual se hacen efectivos requerimientos no
funcionales como la escalabilidad, fiabilidad o rendimiento. MDA se asegura
de que el modelo independiente de la plataforma (PIM), el cual representa un
diseño conceptual que concreta los requerimientos funcionales, sobrevive a
los cambios que se produzcan en las tecnologías de fabricación y en la
arquitectura software. De particular importancia en MDA es la noción de
transformación de modelos.

● Rational Unified Process (RUP)


Según [RUP] “un proceso es un conjunto de pasos parcialmente ordenados
que intentan alcanzar un objetivo. En la Ingeniería de Software, ese objetivo
es la construcción de un producto de software o la mejora de uno existente.
En la Ingeniería de procesos, el objetivo es desarrollar o mejorar un proceso.”
El Rational Unified Process (RUP) en su versión completa está catalogado
como proceso “pesado”, si bien el proceso general es instanciable a las
necesidades de cada Organización para crear sus propios procesos basados
en RUP que pueden ser menos “pesados” que el original. Es un proceso
adaptable tanto a las distintas Organizaciones como a los diferentes
dominios y tamaños de los proyectos en desarrollo, y desde su primera
versión está en constante evolución. Provee un enfoque disciplinado para la
asignación de tareas y responsabilidades en la Organización de desarrollo,
así como para la ejecución y seguimiento de los proyectos en la
Organización.
II. Arquitectura
a. Diagramas
i. Flujo de compra:

ii. Flujo datos internos:


iii. Flujo de datos de delivery:

iv. Flujo de gestión de equipo delivery:


v. Flujo de datos general:
b. Detalle de artefactos y tecnología:
i. Detalles de software y hardware:

III. Selección de herramienta de software (usa la arquitectura


seleccionada).
La herramienta de software seleccionada para el proyecto de investigación es el sistema
UPS WorldShip ya qué cumple con la estructura fundamentada y buscada por el equipo
para el respectivo trabajo.

¿Qué es UPS WorldShip?


WorldShip es un software de envíos global, con funciones completas, basado en Windows.
WorldShip le da acceso a todo el catálogo de servicios de envío de Paquete Pequeño de
UPS y servicios de carga de UPS.

WorldShip puede agilizar los procesos comerciales conectándolo a sus sistemas


empresariales. Mediante las integraciones ODBC y XML, WorldShip puede importar
información de sus sistemas empresariales y bases de datos críticos, y exportar los detalles
del envío.
¿Qué solución es mejor para mí, ups.com o WorldShip?

El envío en ups.com ofrece una experiencia en línea intuitiva para los clientes que tienen
poco volumen o que solo necesitan hacer envíos ocasionales. Nuestra aplicación web fácil
de usar le permite crear etiquetas de envío, programar una recolección, enviar
notificaciones por correo electrónico y pagar en línea desde cualquier lugar con conexión a
Internet. Sencillo, rápido y fácil.

WorldShip está diseñado para aquellos que envían más de 10 paquetes al día, necesitan
acceso al paquete completo de servicios de UPS® o requieren funciones específicas de
software, como los perfiles de informes y envío integrados. WorldShip también ofrece
funciones de automatización e integración, envíos sin conexión a Internet y acceso a
servicios de agregación como UPS Hundredweight Service® y UPS Trade Direct. Sólido y
poderoso.

¿Cuáles son los requisitos del sistema para instalar WorldShip?

WorldShip debe instalarse en una computadora de escritorio usando sistemas operativos


basados en Windows. La versión más reciente de WorldShip es compatible con Windows
8.1, Windows 10 y Windows® 11. WorldShip no funcionará en sistemas que no sean
Windows, como MAC o Linux, tabletas o dispositivos móviles.

IV. Propuesta de mejoras


A pesar de que el WorldShip es una buena herramienta que ayuda a lo que es el envío de
paquetes de UPS, este tiene algunos problemas como lo que sería la compatibilidad con
otros sistemas operativos y demás. Aqui se mostrara lo que serían las mejoras para el
software
● Mejorar el uso del software en un sistema operativo un poco más antiguo (Win 7 +).
● Tener la opción de sincronización on/off por sí hubiera una desconexión de internet y
así evitar replicar procesos. Esto se debe a que mucha gente pierde sus archivos
por la desconexión de internet y tiene que volver ha hacer

V. Conclusiones y recomendaciones
Se concluye qué el software UPS WorldShip es un aplicativo de uso general, donde clientes
y usuarios interactúan a través de la interfaz dando solvencia a una necesidad de
administración de paquetes. A su vez, da comodidad ya qué se puede ejecutar de forma
web (aplicativo web) esto lo hace bastante más asequible qué algunos otros de sus
competidores.
Pero a la par con ello requiere requisitos en el sistema los cuales pueden aplicarse a una
gama más amplia de usuarios con dispositivos un poco más antiguos, por ello planteamos
las siguientes recomendaciones de portabilidad, comodidad y flexibilidad para usuarios y
clientes:

● Volver compatible con otros sistemas operativos para mayor portabilidad


● Hacer compatible con dispositivos móviles (tabletas profesionales, celulares,
etc.) para mayor comodidad y movilidad.
VI. Bibliografía
● Arquitectura de software. (n.d.). Voigtmann GmbH. Recuperado de
https://www.voigtmann.de/es/desarrollo-de-software/arquitectura-de-software/
● Alexander, D. (2018). ¿Qué es la arquitectura de software? Platzi. Recuperado de
https://platzi.com/blog/que-es-arquitectura-de-software/
● Novoseltseva, E. (2020, Junio 2). 5 principales patrones de Arquitectura de Software.
Apiumhub. Recuperado de
https://apiumhub.com/es/tech-blog-barcelona/principales-patrones-arquitectura-
software/
● Cervantes, H. (n.d.). Arquitectura de Software | SG Buzz. Software Guru.
Recuperado de https://sg.com.mx/revista/27/arquitectura-software
● Fernandez, L. F. (2006, Mayo-Junio). Arquitectura de software. Software Guru, 40 al
42.
● Sarasty, H. F. (2015, Octubre). DOCUMENTACIÓN Y ANÁLISIS DE LOS
PRINCIPALES FRAMEWORKS DE ARQUITECTURA DE SOFTWARE EN
APLICACIONES EMPRESARIALES. La Plata, Argentina. Recuperado de
http://sedici.unlp.edu.ar/bitstream/handle/10915/52183/Documento_completo..pdf?
sequence=3&isAllowed=y
● Navasa, A. (2008). Marco de Trabajo para el desarrollo de arquitecturas software
orientado a aspecto. Universidad de Extremadura Servicio de Publicaciones.
● Software de envíos WorldShip. (n.d.). UPS - Estados Unidos. Recuperado June 9,
2022, from https://es-us.ups.com/us/es/business-solutions/business-shipping-tools/
worldship.page

También podría gustarte