diff --git a/README.md b/README.md index f52f4eb..20ebbc4 100644 --- a/README.md +++ b/README.md @@ -219,7 +219,7 @@ Para la integración venta/stock/contabilidad: --- -### Ejemplo 5: Diagrama de Arquitectura Estratificada (D-ARQ-TECH-001) +### Ejemplo 5: Diagrama de Arquitectura Estratificada (D-ARQ-TECH-001) y Estilos Arquitectónicos (D-ARQ-TECH-002) El diagrama de arquitectura muestra las capas del stack tecnológico de Odoo: @@ -228,7 +228,9 @@ El diagrama de arquitectura muestra las capas del stack tecnológico de Odoo: - **Capa 3**: Persistencia (PostgreSQL, Filestore) - **Capa 4**: Integración externa (REST API, SMTP, Payment, Webhooks) -**Lección para el alumno**: el diagrama de arquitectura debe mostrar TODAS las capas relevantes del stack, no solo la capa de aplicación. Esto permite entender dónde corre cada componente y cómo se comunican entre capas. +El **D-ARQ-TECH-002** complementa este diagrama identificando los **8 estilos arquitectónicos** aplicados a Odoo: Cliente-Servidor, 3-Tier, MVC, Capas, Pipe-and-Filter, Microkernel, Repository, Event-Driven. Ver `docs/04_arquitectura/estilos_arquitectonicos.md` para el análisis detallado. + +**Lección para el alumno**: el diagrama de arquitectura debe mostrar TODAS las capas relevantes del stack, no solo la capa de aplicación. Esto permite entender dónde corre cada componente y cómo se comunican entre capas. Además, identificar los **estilos arquitectónicos** aplicados ayuda a entender por qué el sistema se organiza como se organiza. --- @@ -264,6 +266,11 @@ El diagrama del patrón Composite muestra cómo Odoo implementa la Lista de Mate - **`docs/12_patrones_diseno/composite_bom.md`** — patrón Composite aplicado a BoM, con documentación siguiendo estándar UNR. +### Estilos arquitectónicos + +- **`docs/04_arquitectura/estilos_arquitectonicos.md`** — análisis de los 8 estilos arquitectónicos aplicados a Odoo (Cliente-Servidor, 3-Tier, MVC, Capas, Pipe-and-Filter, Microkernel, Repository, Event-Driven). Basado en el apunte de la materia. +- **`diagrams/plantuml/d_arq_tech_002_estilos_arquitectonicos.puml`** — diagrama de arquitectura con los estilos identificados. + ### Evidencias - **`evidence/index.md`** — catálogo de 30 EV-COD y 8 EV-INF verificables contra código real de Odoo 19.0. @@ -285,6 +292,13 @@ Material de lectura recomendado para profundizar en la metodología ICONIX y su - **PPT sobre ICONIX** — material de clase complementario - Útil como soporte visual para entender la metodología. Puede ser de utilidad para el alumno para preparar el TP o exponer conceptos en clase. +### Apunte de estilos arquitectónicos (de la materia) + +- **Apunte de estilos arquitectónicos** — material de la materia + - 📖 Acceso: https://drive.google.com/file/d/0B8MI0532KYVjTzJTWGJMTXcxRUU/view?usp=sharing&resourcekey=0-KFIUox1cee5ulFXDP7MZVg + - Material teórico sobre estilos arquitectónicos (cliente-servidor, 3-tier, MVC, capas, pipe-filter, microkernel, repository, event-driven, etc.). + - **Aplicación al TP**: estos conceptos están aplicados al diseño de Odoo en `docs/04_arquitectura/estilos_arquitectonicos.md` y en el diagrama `D-ARQ-TECH-002`. Lectura recomendada para entender por qué Odoo se organiza como se organiza. + ### Otras referencias citadas en el repositorio - **Gamma, E., Helm, R., Johnson, R., & Vlissides, J.** (2003). *Design Patterns: Elements of Reusable Object-Oriented Software*. Addison-Wesley. — libro canónico de los patrones GoF. diff --git a/diagrams/pdf/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.pdf b/diagrams/pdf/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.pdf new file mode 100644 index 0000000..626e846 Binary files /dev/null and b/diagrams/pdf/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.pdf differ diff --git a/diagrams/plantuml/d_arq_tech_002_estilos_arquitectonicos.puml b/diagrams/plantuml/d_arq_tech_002_estilos_arquitectonicos.puml new file mode 100644 index 0000000..9b0084a --- /dev/null +++ b/diagrams/plantuml/d_arq_tech_002_estilos_arquitectonicos.puml @@ -0,0 +1,113 @@ +@startuml D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados + +title SAP-TFI-2026 — Arquitectura de Odoo 19.0 con Estilos Arquitectonicos + +skinparam shadowing false +skinparam handwritten false +skinparam defaultFontName Arial +skinparam defaultFontSize 11 +skinparam linetype ortho +skinparam backgroundColor white + +' ─────────────────────── ESTILOS APLICADOS ─────────────────────── +note as N1 + Estilos arquitectonicos identificados: + - Cliente-Servidor (browser <-> Odoo server) + - 3-Tier / N-Tier (Cliente, Aplicacion, Datos) + - MVC (Modelo-Vista-Controlador, extendido) + - Capas (Presentation, Web, Logic, Data) + - Pipe-and-Filter (request pipeline HTTP) + - Microkernel (extension via _inherit) + - Repository (ORM Odoo encapsula BD) + - Event-Driven (mail.thread, onchange) +end note + +' ─────────────────────── CLIENTE ─────────────────────── +package "Cliente (Browser)\n[Estilo: Cliente-Servidor]" { + node "Web Browser" as Browser + node "JavaScript Runtime" as JSRuntime +} + +' ─────────────────────── CAPA PRESENTACION ─────────────────────── +package "Capa 2.1: Presentacion (UI)\n[Estilo: MVC - Vista]" { + node "OWL Framework" as OWL + node "Static Assets (JS/CSS)" as Static + database "Views (XML)" as Views +} + +' ─────────────────────── WEB LAYER ─────────────────────── +package "Capa 2.2: Web Layer\n[Estilos: Pipe-and-Filter, MVC-Controlador]" { + node "Router\n(addons/web/http.py)" as Router + node "HTTP Controllers" as Controllers + node "JSON-RPC Endpoint" as JSONRPC + node "XML-RPC Endpoint" as XMLRPC +} + +' ─────────────────────── LOGICA ─────────────────────── +package "Capa 2.3: Business Logic\n[Estilos: MVC-Modelo, Microkernel, Event-Driven]" { + node "Models (Python)\n(addons//models/)" as Models + node "ORM (Object-Relational)\n[Estilo: Repository]" as ORM + node "Compute Fields,\nonchange, constraints\n[Estilo: Event-Driven]" as Computed +} + +' ─────────────────────── ADDONS ─────────────────────── +package "Capa 2.4: Addons\n[Estilo: Microkernel (plugins via _inherit)]" { + node "sale" as AddonSale + node "account" as AddonAccount + node "stock" as AddonStock + node "product" as AddonProduct +} + +' ─────────────────────── DATOS ─────────────────────── +package "Capa 3: Persistencia\n[Estilo: 3-Tier - Capa de Datos]" { + database "PostgreSQL\n[Estilo: Repository]" as DB + node "Filestore" as Filestore +} + +' ─────────────────────── INTEGRACION ─────────────────────── +package "Capa 4: Integracion Externa\n[Estilos: Cliente-Servidor (inverso), Pipe-and-Filter]" { + node "API REST" as RESTAPI + node "SMTP" as SMTP + node "Payment Gateway" as Payment + node "Webhooks" as Webhooks +} + +' ─────────────────────── CONEXIONES ─────────────────────── + +Browser --> OWL +Browser --> Static +OWL --> Router +Router --> Controllers : dispatch (Pipe-Filter) +Router --> Views : selecciona vista (MVC-Vista) +Controllers --> Models : invoca (MVC-Controlador) +JSONRPC <-- Controllers +XMLRPC <-- Models +Models --> ORM : queries (Repository) +Models --> Computed : logica (Event-Driven) +ORM --> DB : SQL +ORM --> Filestore +Models --> SMTP : envia emails (Event-Driven) +Models --> Payment : cobros +Models --> Webhooks : notifica + +AddonSale --> Models +AddonAccount --> Models +AddonStock --> Models +AddonProduct --> Models + +legend right +Proyecto: SAP-TFI-2026 +Agente: saptfi2026 +Estilos aplicados: 8 estilos GoF/Arquitectura + +Cliente-Servidor: browser <-> server +3-Tier: Cliente | Aplicacion | Datos +MVC: Vista (XML/OWL) | Controlador (HTTP) | Modelo (ORM) +Capas: Presentacion | Web | Logic | Addons +Pipe-and-Filter: HTTP request pipeline +Microkernel: addons via _inherit +Repository: ORM Odoo encapsula BD +Event-Driven: mail.thread, onchange, cron +endlegend + +@enduml \ No newline at end of file diff --git a/diagrams/png/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.png b/diagrams/png/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.png new file mode 100644 index 0000000..21bc938 Binary files /dev/null and b/diagrams/png/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.png differ diff --git a/diagrams/svg/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.svg b/diagrams/svg/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.svg new file mode 100644 index 0000000..9aeda96 --- /dev/null +++ b/diagrams/svg/D-ARQ-TECH-002 — Arquitectura con Estilos Arquitectonicos Identificados.svg @@ -0,0 +1,276 @@ +SAP-TFI-2026 — Arquitectura de Odoo 19.0 con Estilos ArquitectonicosCliente (Browser)[Estilo: Cliente-Servidor]Capa 2.1: Presentacion (UI)[Estilo: MVC - Vista]Capa 2.2: Web Layer[Estilos: Pipe-and-Filter, MVC-Controlador]Capa 2.3: Business Logic[Estilos: MVC-Modelo, Microkernel, Event-Driven]Capa 2.4: Addons[Estilo: Microkernel (plugins via _inherit)]Capa 3: Persistencia[Estilo: 3-Tier - Capa de Datos]Capa 4: Integracion Externa[Estilos: Cliente-Servidor (inverso), Pipe-and-Filter]Web BrowserJavaScript RuntimeOWL FrameworkStatic Assets (JS/CSS)Views (XML)Router(addons/web/http.py)HTTP ControllersJSON-RPC EndpointXML-RPC EndpointModels (Python)(addons/<modulo>/models/)ORM (Object-Relational)[Estilo: Repository]Compute Fields,onchange, constraints[Estilo: Event-Driven]saleaccountstockproductPostgreSQL[Estilo: Repository]FilestoreAPI RESTSMTPPayment GatewayWebhooksEstilos arquitectonicos identificados:- Cliente-Servidor (browser <-> Odoo server)- 3-Tier / N-Tier (Cliente, Aplicacion, Datos)- MVC (Modelo-Vista-Controlador, extendido)- Capas (Presentation, Web, Logic, Data)- Pipe-and-Filter (request pipeline HTTP)- Microkernel (extension via _inherit)- Repository (ORM Odoo encapsula BD)- Event-Driven (mail.thread, onchange)dispatch (Pipe-Filter)selecciona vista (MVC-Vista)invoca (MVC-Controlador)queries (Repository)logica (Event-Driven)SQLenvia emails (Event-Driven)cobrosnotificaProyecto: SAP-TFI-2026Agente: saptfi2026Estilos aplicados: 8 estilos GoF/ArquitecturaCliente-Servidor: browser <-> server3-Tier: Cliente | Aplicacion | DatosMVC: Vista (XML/OWL) | Controlador (HTTP) | Modelo (ORM)Capas: Presentacion | Web | Logic | AddonsPipe-and-Filter: HTTP request pipelineMicrokernel: addons via _inheritRepository: ORM Odoo encapsula BDEvent-Driven: mail.thread, onchange, cron \ No newline at end of file diff --git a/docs/04_arquitectura/estilos_arquitectonicos.md b/docs/04_arquitectura/estilos_arquitectonicos.md new file mode 100644 index 0000000..7dde4a4 --- /dev/null +++ b/docs/04_arquitectura/estilos_arquitectonicos.md @@ -0,0 +1,185 @@ +# Estilos Arquitectónicos aplicados a Odoo 19.0 + +> Documento vivo. Última actualización: 2026-06-18. +> Basado en el apunte de la materia sobre estilos arquitectónicos. + +## Diagrama + +Ver `diagrams/plantuml/d_arq_tech_002_estilos_arquitectonicos.puml`. + +## ¿Qué son los estilos arquitectónicos? + +Un **estilo arquitectónico** es un conjunto de principios y patrones que define cómo se organizan los componentes de un sistema, cómo interactúan entre sí y qué restricciones se imponen. Diferentes estilos son apropiados para diferentes tipos de sistemas. + +En la práctica, los sistemas complejos como Odoo **combinan varios estilos arquitectónicos** en distintas partes. A continuación se describen los estilos identificados en la arquitectura de Odoo 19.0. + +--- + +## Estilos identificados en Odoo 19.0 + +### 1. Cliente-Servidor (Client-Server) + +**Descripción**: el sistema se divide en dos partes: un cliente que solicita servicios y un servidor que los provee. La comunicación es típicamente request-response. + +**Aplicación en Odoo**: +- El navegador web (cliente) hace HTTP requests al servidor Odoo. +- El servidor Odoo procesa cada request y devuelve la respuesta (HTML, JSON, PDF, etc.). +- El servidor no inicia la comunicación; siempre es el cliente quien lo hace. + +**Evidencia**: +- **EV-ARQ-001**: Toda la comunicación se realiza vía HTTP/HTTPS (ver `addons/web/http.py`). + +### 2. 3-Tier / N-Tier + +**Descripción**: el sistema se divide en tres o más capas lógicas separadas: presentación, lógica de negocio y datos. Cada capa se comunica solo con la capa adyacente. + +**Aplicación en Odoo** (N-Tier con 4 capas): +- **Capa 1**: Cliente (navegador). +- **Capa 2**: Servidor de aplicación Odoo (con 4 subcapas: Presentación, Web, Logic, Addons). +- **Capa 3**: Persistencia (PostgreSQL, Filestore). +- **Capa 4**: Integración externa (servicios de terceros). + +**Beneficio**: cada capa puede escalarse, modificarse o reemplazarse independientemente. + +### 3. MVC (Modelo-Vista-Controlador) + +**Descripción**: patrón arquitectónico que separa la lógica de negocio (Modelo), la presentación (Vista) y el manejo de requests (Controlador). + +**Aplicación en Odoo** (MVC extendido): + +| Componente MVC | Implementación en Odoo | +|----------------|--------------------------| +| **Modelo** | `models/*.py` (clases Python que heredan de `models.Model`). Encapsula datos y lógica de negocio. | +| **Vista** | `views/*.xml` (form, tree, kanban, search). Define cómo se presentan los datos. | +| **Controlador** | `controllers/*.py` (clases Python que heredan de `http.Controller`). Manejan HTTP requests. | + +**Diferencia con MVC clásico**: en Odoo, los controllers son opcionales. La mayoría de las vistas se generan automáticamente a partir del modelo. Solo se usan controllers cuando se necesita lógica HTTP custom (ej: endpoints REST, webhooks). + +**Evidencia**: +- **EV-ARQ-002**: `addons/web/controllers/main.py` — controllers principales de Odoo. +- **EV-ARQ-003**: `addons/sale/views/sale_order_views.xml` — vistas del modelo `sale.order`. + +### 4. Capas (Layered Architecture) + +**Descripción**: cada capa provee servicios a la capa superior y consume servicios de la capa inferior. Las capas están estrictamente separadas. + +**Aplicación en Odoo** (4 subcapas dentro de Capa 2): +- **Capa 2.1: Presentación**: OWL, Views (XML), Static. +- **Capa 2.2: Web Layer**: Router, Controllers, JSON-RPC, XML-RPC. +- **Capa 2.3: Business Logic**: Models, ORM, Computed. +- **Capa 2.4: Addons**: sale, account, stock, product (extensiones modulares). + +**Beneficio**: cada capa tiene responsabilidades claras y límites bien definidos. + +### 5. Pipe-and-Filter + +**Descripción**: el procesamiento de datos se organiza como una cadena de filtros (procesadores) conectados por pipes (conductos). Cada filtro transforma los datos y los pasa al siguiente. + +**Aplicación en Odoo**: +- El pipeline de HTTP requests pasa por varios filtros antes de llegar al controller: + 1. **Autenticación** (validación de sesión). + 2. **Routing** (resolución de URL a controller). + 3. **CSRF check** (validación de token). + 4. **Controller** (procesamiento del request). + 5. **Response** (renderizado a JSON/HTML). + +**Evidencia**: +- **EV-ARQ-004**: `addons/web/http.py` — pipeline de middlewares de Odoo. + +### 6. Microkernel (Plugin-Based) + +**Descripción**: el sistema tiene un núcleo mínimo que provee funcionalidades básicas, y las funcionalidades adicionales se agregan como plugins (módulos). + +**Aplicación en Odoo**: +- El núcleo de Odoo provee el ORM, el framework HTTP y los modelos base (`res.partner`, `res.company`). +- Los addons extienden el núcleo vía `_inherit`: + - `sale` extiende `mail.thread` y agrega `sale.order`. + - `account` extiende el modelo base y agrega `account.move`. + - `stock` agrega `stock.picking`, `stock.move`, etc. + +**Beneficio**: el sistema puede extenderse sin modificar el código del núcleo. + +**Evidencia**: +- **EV-ARQ-005**: `addons/sale/models/sale_order.py:36` — `_inherit = ['portal.mixin', 'product.catalog.mixin', 'mail.thread', ...]`. + +### 7. Repository + +**Descripción**: encapsula el acceso a datos detrás de una interfaz orientada a objetos. El cliente no interactúa directamente con la base de datos. + +**Aplicación en Odoo**: +- El ORM de Odoo encapsula el acceso a PostgreSQL. +- Los modelos definen sus campos en Python y el ORM se encarga de crear las tablas, hacer queries, gestionar transacciones, etc. +- El cliente (controller o vista) nunca hace SQL directamente; siempre interactúa con el ORM. + +**Beneficio**: cambios en el esquema de BD no afectan la lógica de negocio. + +**Evidencia**: +- **EV-ARQ-006**: `odoo/orm/` — implementación del ORM de Odoo. + +### 8. Event-Driven + +**Descripción**: el sistema reacciona a eventos publicados por otros componentes. Los componentes no se llaman entre sí directamente; se comunican vía eventos. + +**Aplicación en Odoo**: +- **`mail.thread`**: registra todos los cambios al modelo como mensajes (eventos). +- **`onchange`**: dispara lógica cuando un campo cambia en el form. +- **`@api.depends`**: recalcula campos cuando otros campos cambian. +- **Cron jobs**: ejecutan tareas programadas periódicamente. +- **Webhooks**: notifican a sistemas externos cuando ocurren eventos. + +**Beneficio**: bajo acoplamiento entre componentes. + +--- + +## Combinación de estilos + +Odoo **no usa un solo estilo**, sino una combinación de ellos. Esta es la práctica común en sistemas complejos. + +| Estilo | Dónde se aplica | Por qué | +|--------|-----------------|---------| +| Cliente-Servidor | Toda la comunicación | Separación clara entre UI y lógica | +| 3-Tier | Capas 1, 2, 3 | Aislamiento entre cliente, lógica y datos | +| MVC | Capa 2 | Separación entre modelo, vista y controlador | +| Capas | Capa 2 (subcapas 2.1-2.4) | Organización modular interna | +| Pipe-and-Filter | Pipeline HTTP | Procesamiento ordenado de requests | +| Microkernel | Addons | Extensibilidad sin modificar núcleo | +| Repository | Capa 2.3 → Capa 3 | Abstracción de persistencia | +| Event-Driven | mail.thread, onchange, cron | Reactividad y desacoplamiento | + +--- + +## Consecuencias arquitectónicas + +### Beneficios + +- **Extensibilidad**: nuevos addons pueden agregarse sin modificar el núcleo (Microkernel). +- **Mantenibilidad**: separación clara entre capas, MVC, lógica (Repository). +- **Escalabilidad**: cada capa puede escalarse independientemente (3-Tier). +- **Reusabilidad**: los addons pueden reutilizar funcionalidad de otros addons (Microkernel + MVC). +- **Interoperabilidad**: el sistema expone APIs estándar (JSON-RPC, XML-RPC) para integraciones externas (Cliente-Servidor). + +### Trade-offs + +- **Complejidad**: la combinación de 8 estilos puede ser difícil de entender para nuevos desarrolladores. +- **Performance**: el pipeline HTTP (Pipe-and-Filter) agrega latencia. +- **Acoplamiento entre addons**: si dos addons se acoplan fuertemente vía `_inherit`, pueden romperse mutuamente al actualizarse. +- **Curva de aprendizaje**: el ORM de Odoo (Repository) tiene una API específica que requiere tiempo para dominar. + +--- + +## Relación con el apunte de la materia + +Este documento aplica los conceptos del **apunte de la materia sobre estilos arquitectónicos** al caso concreto de Odoo 19.0. Los estudiantes deben: + +1. Leer el apunte de la materia para entender los estilos teóricos. +2. Leer este documento para ver cómo se aplican a un sistema real. +3. Identificar los estilos en otros sistemas que conozcan (ej: otros ERPs, e-commerce, etc.). + +--- + +## Referencias + +- **Apunte de la materia sobre estilos arquitectónicos**: https://drive.google.com/file/d/0B8MI0532KYVjTzJTWGJMTXcxRUU/view?usp=sharing&resourcekey=0-KFIUox1cee5ulFXDP7MZVg +- Gamma et al. (2003). *Design Patterns*. — patrones GoF. +- Odoo S.A. (2024). *Odoo 19.0 Documentation*. https://www.odoo.com/documentation/19.0/ +- Repositorio oficial de Odoo: https://github.com/odoo/odoo (rama `19.0`) \ No newline at end of file