Docente: Ing. Mg.

Diana Díaz Estrada

Email: diana_diaz@unu.edu.pe
DISEÑO DE DISEÑO DE DISEÑO DE DISEÑO DE
PROCESOS ARQUITECTURA DATOS INTERFACES
• ¿Usted intentaría construir una casa sin planos?
 La arquitectura de
software es como un plano
de construcción: si no se
realiza una planificación
adecuada, el edificio
puede derrumbarse.

 Antes de preocuparse por

lo detalles necesita
conocer el panorama
general.
• Lo mismo ocurre con el desarrollo de aplicaciones, sin una
arquitectura de software de calidad, el programa puede presentar
errores a largo plazo y generar retrasos en la operatividad de tu
empresa.
La arquitectura de software se refiere
a la estructura fundamental de un
sistema de software, que comprende
sus componentes, sus relaciones,
principios y pautas para su diseño y
desarrollo. Esta arquitectura define la
manera en que el software está
organizado y cómo interactúan sus
diferentes partes para lograr los
objetivos del sistema.

QUIEN LO HACE
 Identificar requisitos: Comprender y analizar los requisitos del sistema, tanto funcionales como no funcionales, es
fundamental para diseñar la arquitectura adecuada.

Seleccionar patrones y estilos arquitectónicos: Basado en los requisitos identificados, se eligen los patrones y estilos
arquitectónicos que mejor se adapten al sistema. Por ejemplo, la arquitectura en capas, cliente-servidor, orientada a
servicios, microservicios, entre otros.

Definir componentes y relaciones: Identificar los componentes principales del sistema y cómo se relacionarán entre sí.

Garantizar la calidad: Considerar aspectos de calidad como la escalabilidad, la seguridad, la fiabilidad, el rendimiento y
la mantenibilidad durante el diseño de la arquitectura. Esto implica seleccionar tecnologías adecuadas, establecer
estándares y prácticas, y prever posibles puntos de fallo.

Documentación: Es crucial documentar el diseño de la arquitectura para que los miembros del equipo y otras
partes interesadas puedan comprender fácilmente la estructura del sistema y las decisiones detrás de ella.
 Modelo vista
Cliente -
controlador
servidor
(MVC)

Basada en Arquitectura
microservicios en capas

Orientado a
servicios
• Cliente-servidor. Divide las funciones del sistema entre clientes que solicitan servicios
y servidores que proporcionan esos servicios.

• Arquitectura en capas. Organiza el sistema en capas horizontales donde cada capa

tiene una responsabilidad específica. Por ejemplo: Capa de presentación (interfaz de
usuario), Lógica del negocio y otra para el almacenamiento (Datos).

• Modelo Vista Controlador. es un patrón de arquitectura de software, que separa

los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo
encargado de gestionar los eventos y las comunicaciones

• Orientada a servicios (SOA). Basada en el concepto de servicios independientes y

reutilizables que se comunican a través de interfaces bien definidas.

• Basada en Microservicios. Consiste en descomponer una aplicación en servicios

pequeños e independientes, lo que facilita la escalabilidad y el despliegue
independiente de cada servicio.
1
 Modelo de 2 capas: Es una arquitectura constituida por 2 capas:
Front-End y Back-End.
◦ Front-End: consiste en la capa donde el usuario interactúa con su
PC.
◦ Back-End: es el servidor de bases de datos como Oracle o SQL-
Server.

Dificultades de la arquitectura de 2 capas

◦ Dificultad al realizar cambios en el Front-End
◦ Dificultad al compartir procesos comunes.
◦ Problemas de seguridad, etc.
• Aquí, la funcionalidad del sistema está organizada en capas separadas, y
cada una se apoya sólo en las facilidades y los servicios ofrecidos por la
capa inmediatamente debajo de ella.

• Este enfoque en capas soporta el desarrollo incremental de sistemas.

• Conforme se desarrolla una capa, algunos de los servicios proporcionados

por esta capa deben quedar a disposición de los usuarios.

• La arquitectura también es cambiable y portátil. En tanto su interfaz no

varíe, una capa puede sustituirse por otra equivalente
 Capa de Usuario: Los componentes del nivel de usuario, proporcionan la
interfaz visual que los clientes utilizarán para ver la información y los datos. En
este nivel, los componentes son responsables de solicitar y recibir servicios de
otros componentes del mismo nivel o del nivel de servicios de negocio. Es
muy importante destacar que, a pesar de que las funciones del negocio
residen en otro nivel, para el usuario es transparente la forma de operar.

 Capa de Negocios: Como los servicios de usuario no pueden contactar

directamente con el nivel de servicios de datos, es responsabilidad de los
servicios de negocio hacer de puente entre estos. Los objetos de negocio
proporcionan servicios que completan las tareas de negocio tales como
verificar los datos enviados por el cliente. Antes de llevar a cabo una
transacción en la D.B.
Los componentes de los servicios de negocio también nos sirven para evitar
que el usuario tenga acceso directo a la base de datos, lo cual proporciona
mayor seguridad en la integridad de ésta.
 ARQUITECTURA EN 3 CAPAS
• Capa de Datos: El nivel de datos se encarga de las típicas tareas que
realizamos con los datos: Inserción, modificación, consulta y borrado. La clave
del nivel de datos es que los papeles de negocio no son implementados
aquí. Aunque un componente de servicio de datos es responsable de la
gestión de las peticiones realizadas por un objeto de negocio.
Un nivel de servicios de datos apropiadamente implementado, debería
permitir cambiar su localización sin afectar a los servicios proporcionados
por los componentes de negocio.
 La arquitectura orientada a servicios (SOA, por sus siglas en inglés,
Service-Oriented Architecture) es un enfoque para diseñar sistemas de
software donde los servicios son los componentes fundamentales y las
unidades de implementación.

 Estos servicios están diseñados para ser independientes, reutilizables y

están interconectados a través de interfaces bien definidas y estándares,
lo que permite la creación de aplicaciones empresariales flexibles y
escalables.

 La arquitectura orientada a servicios (SOA) es utilizada principalmente

en entornos empresariales donde la integración de sistemas y la
adaptabilidad a cambios constantes son cruciales.
 Un servicio es una pieza de software que provee una funcionalidad
específica. Por ejemplo, en un sistema operativo tenemos servicios de
red que gestionan las conexiones, servicios de notificaciones, de
bluetooth, etc. Estos corren en segundo plano y no solemos interactuar
con ellos.

 Los servicios van mucho más allá de los sistemas operativos porque
tenemos servicios de nube (como lo dice el nombre de Amazon Web
Services), servicios de procesamiento de pagos por internet, entre otros.

 Dentro de toda esta gama de servicios, uno de los más usados son los
servicios web que se encargan de exponer lógica y datos a través del
protocolo HTTP, el mismo que se usa para navegar por internet. Eso
significa que prácticamente todo lo que ocurre en internet está basado
en servicios web, incluida la inteligencia artificial y las aplicaciones
móviles.
Los microservicios, pues son servicios pequeños y específicos (de ahí su
nombre) para cada funcionalidad de la aplicación. Al igual que los servicios, los
microservicios pueden conectarse entre ellos para construir una aplicación y
también pueden exponer sus endpoints a aplicaciones de terceros.
 Las convenciones de codificación son un conjunto de normas para un
lenguaje de programación específico que recomiendan estilos de
programación, buenas prácticas y métodos para mantener el aspecto
del código fuente. Estas convenciones incluyen la organización de
archivos, la indentación, los comentarios, las declaraciones los
espacio en blanco, las llaves de apertura y cerrado…
• Snake case es la convención que compone las palabras separadas por
barra baja (underscore) en vez de espacios y con la primera letra de
cada palabra en minúscula. Por ejemplo mi_blog_de_desarrollo.

• Train-Case: Es una variedad del kebab-case, pero cada palabra con la

primera letra en mayúsculas. Por ejemplo, Mi-Blog-De-Desarrollo.

• kebab-case: Al igual que el snake_case pero unido con guiones en vez

de barra baja. Por ejemplo mi-blog-de-desarrollo.

https://adrianalonsodev.medium.com/convenci%C3%B3n-de-nombres-
desde-el-camelcase-hasta-el-kebab-case-787e56d6d023

 Buenas Prácticas en el desarrollo de software

GRACIAS POR SU ATENCION