mirror of
https://github.com/cursos-uai/sap_tfi_2026.git
synced 2026-07-31 20:48:30 -03:00
feat(iter-1-completa): PDFs, diagramas extra, EV-COD validadas, material educativo
Cambios desde el commit anterior: PDFs y formatos visuales (Paso 1): - 11 PNGs + 11 SVGs + 11 PDFs generados con PlantUML 1.2021.16 - Conversión PNG→PDF con fpdf2 (workaround para Java 8) Diagramas adicionales (Paso 2): - d_rob_ven_001_crear_presupuesto.puml + .pdf - d_sec_ven_001_crear_presupuesto.puml + .pdf - d_rob_ent_002_reservar_productos.puml + .pdf - d_sec_ent_002_reservar_productos.puml + .pdf - d_rob_fac_001_crear_factura.puml + .pdf - d_sec_fac_001_crear_factura.puml + .pdf EV-COD adicionales (Paso 3): - EV-COD-021 a EV-COD-030 (10 nuevas evidencias) - EV-INF reducidas de 22 a 8 (14 promovidas a EV-COD) - evidence/index.md con catálogo completo de evidencias Material educativo (Paso 4): - docs/10_material_estudio/README.md - docs/10_material_estudio/01_que_es_iconix.md - docs/10_material_estudio/02_aplicacion_a_odoo.md - docs/10_material_estudio/03_como_leer_los_cu.md - docs/10_material_estudio/04_ejercicios_practicos.md Matriz de trazabilidad actualizada con las nuevas EV-COD.
This commit is contained in:
saptfi2026-bot
@@ -87,6 +87,16 @@
|
||||
| EV-COD-018 | EV-COD | `state` field (account.move) | `addons/account/models/account_move.py:129` |
|
||||
| EV-COD-019 | EV-COD | `action_register_payment` | `addons/account/models/account_move.py:6022` |
|
||||
| EV-COD-020 | EV-COD | `payment_state` field | `addons/account/models/account_move.py:600` |
|
||||
| EV-COD-021 | EV-COD | `_action_confirm` stub | `addons/sale/models/sale_order.py:1231-1235` |
|
||||
| EV-COD-022 | EV-COD | `action_assign` cuerpo | `addons/stock/models/stock_picking.py:1195-1208` |
|
||||
| EV-COD-023 | EV-COD | `picking_ids` (sale_stock) | `addons/sale_stock/models/sale_order.py:31` |
|
||||
| EV-COD-024 | EV-COD | `PAYMENT_STATE_SELECTION` | `addons/account/models/account_move.py:48-56` |
|
||||
| EV-COD-025 | EV-COD | `payment_state` (computed) | `addons/account/models/account_move.py:600-606` |
|
||||
| EV-COD-026 | EV-COD | `action_post` cuerpo | `addons/account/models/account_move.py:6101-6122` |
|
||||
| EV-COD-027 | EV-COD | `_send_order_confirmation_mail` | `addons/sale/models/sale_order.py:1237-1244` |
|
||||
| EV-COD-028 | EV-COD | `_trigger_scheduler()` | `addons/sale/models/sale_order.py:1192` |
|
||||
| EV-COD-029 | EV-COD | `action_cancel` (stock) | `addons/stock/models/stock_picking.py:1210-1214` |
|
||||
| EV-COD-030 | EV-COD | `_should_be_locked` | `addons/sale/models/sale_order.py:1198-1201` |
|
||||
|
||||
## Inferencias pendientes (EV-INF)
|
||||
|
||||
|
||||
@@ -0,0 +1,137 @@
|
||||
# ¿Qué es ICONIX?
|
||||
|
||||
## Definición
|
||||
|
||||
**ICONIX** es una metodología de ingeniería de software orientada a objetos que se sitúa entre los métodos ágiles (como XP o Scrum) y los métodos pesados (como el Proceso Unificado Rational — RUP). Fue desarrollada por **Doug Rosenberg** y **Kendall Scott** a principios de los 90, y refinada en sucesivas ediciones de su libro *Use Case Driven Object Modeling with UML*.
|
||||
|
||||
A diferencia de RUP o del método del Proceso Unificado, ICONIX **no se obsesiona con la documentación exhaustiva**, pero tampoco cae en el "codificar sin diseño" del agilismo extremo. En su lugar, propone un **camino mínimo y práctico** desde los requisitos hasta el código, usando UML como lenguaje común.
|
||||
|
||||
## Las 9 fases de ICONIX
|
||||
|
||||
A pesar de su nombre, ICONIX tiene 9 fases (no 3). El "IX" del nombre se refiere a "eXtremidad", porque el método es "extremo" en su enfoque minimalista: solo lo esencial, sin ceremonias.
|
||||
|
||||
```text
|
||||
Requisitos
|
||||
↓
|
||||
Casos de uso (texto + diagrama)
|
||||
↓
|
||||
Modelo de dominio (conceptos del negocio)
|
||||
↓
|
||||
Prototipos de interfaz (bocetos de pantallas)
|
||||
↓
|
||||
Análisis de robustez (¿qué objetos intervienen?)
|
||||
↓
|
||||
Actualización del modelo de dominio
|
||||
↓
|
||||
Diagramas de secuencia (interacciones en el tiempo)
|
||||
↓
|
||||
Diagramas de clases (estructura del sistema)
|
||||
↓
|
||||
Validación de coherencia
|
||||
```
|
||||
|
||||
Cada fase **alimenta** a la siguiente y mantiene **trazabilidad** con las anteriores. No se salta ninguna.
|
||||
|
||||
## El flujo en detalle
|
||||
|
||||
### Fase 1: Requisitos
|
||||
|
||||
- Identificar **qué** tiene que hacer el sistema.
|
||||
- Recopilar requisitos funcionales y no funcionales.
|
||||
- Identificar **actores** (humanos y sistemas externos).
|
||||
- Producto: documento de requisitos (puede ser informal).
|
||||
|
||||
### Fase 2: Casos de uso
|
||||
|
||||
- Para cada objetivo del actor, escribir un **caso de uso**.
|
||||
- Cada CU tiene: nombre, objetivo, precondiciones, flujo principal, flujos alternativos, excepciones.
|
||||
- Producto: tabla de CU + **diagrama de CU** (UML).
|
||||
|
||||
### Fase 3: Modelo de dominio
|
||||
|
||||
- Identificar **conceptos del negocio**, no de la solución.
|
||||
- Conceptos como: Cliente, Producto, Pedido, Factura, Pago.
|
||||
- No incluir campos técnicos, solo atributos del dominio.
|
||||
- Producto: **diagrama de clases conceptual**.
|
||||
|
||||
### Fase 4: Prototipos de interfaz
|
||||
|
||||
- Bocetos de las pantallas principales.
|
||||
- No incluir detalles visuales, solo estructura.
|
||||
- Mostrar campos, botones, navegación.
|
||||
- Producto: wireframes o mockups.
|
||||
|
||||
### Fase 5: Análisis de robustez
|
||||
|
||||
- Para cada CU, identificar **qué objetos intervienen**.
|
||||
- Tres tipos de objetos:
|
||||
- **boundary** (vista, formulario, API)
|
||||
- **control** (coordinador, validador)
|
||||
- **entity** (objeto persistente)
|
||||
- Producto: **diagrama de robustez** por CU.
|
||||
|
||||
### Fase 6: Actualización del dominio
|
||||
|
||||
- Refinar el modelo de dominio con conceptos descubiertos en robustez.
|
||||
|
||||
### Fase 7: Diagramas de secuencia
|
||||
|
||||
- Para cada CU relevante, derivar la **secuencia temporal**.
|
||||
- Mostrar interacciones entre actor, vistas, controles, entidades.
|
||||
- Incluir transacciones, validaciones, errores.
|
||||
- Producto: **diagrama de secuencia** por CU.
|
||||
|
||||
### Fase 8: Diagramas de clases
|
||||
|
||||
- **Conceptual**: conceptos del dominio (reutiliza el modelo de dominio).
|
||||
- **Técnico**: clases reales del sistema, con sus campos y métodos.
|
||||
- Producto: **dos diagramas de clases** por subsistema.
|
||||
|
||||
### Fase 9: Validación
|
||||
|
||||
- Verificar coherencia entre todos los artefactos.
|
||||
- Cada CU debe tener su diagrama de robustez, secuencia y clases.
|
||||
- Cada regla de negocio debe estar trazada.
|
||||
|
||||
## Reglas clave de ICONIX
|
||||
|
||||
1. **Trabajar desde los casos de uso hacia el diseño** (no al revés).
|
||||
2. **Centrarse en objetivos del actor**, no en funciones del sistema.
|
||||
3. **No describir detalles internos del código** en los CU.
|
||||
4. **Usar robustez como puente** entre requisitos y diseño.
|
||||
5. **Distinguir boundary, control, entity** explícitamente.
|
||||
6. **Derivar operaciones de clase desde los mensajes de secuencia**.
|
||||
7. **Mantener trazabilidad explícita** entre todos los artefactos.
|
||||
8. **Actualizar el modelo de dominio** a medida que se descubre nueva información.
|
||||
|
||||
## Por qué ICONIX es ideal para ingeniería inversa
|
||||
|
||||
Cuando uno hace **ingeniería inversa** (analizar un sistema existente), ICONIX funciona muy bien porque:
|
||||
|
||||
- Los **diagramas de secuencia** que produce coinciden con los métodos reales del código.
|
||||
- El **modelo de clases técnico** se construye leyendo el código, no inventando.
|
||||
- La **trazabilidad** permite mapear cada artefacto a su evidencia en el código.
|
||||
|
||||
En este proyecto (SAP-TFI-2026), usamos ICONIX para **documentar** Odoo 19.0, no para **construirlo**. Cada afirmación tiene un código de evidencia que apunta a la línea exacta del código fuente.
|
||||
|
||||
## Diferencias con otros métodos
|
||||
|
||||
| Aspecto | ICONIX | RUP | Scrum |
|
||||
|---------|--------|-----|-------|
|
||||
| Rigurosidad | Media-alta | Muy alta | Baja |
|
||||
| Documentación | Moderada | Exhaustiva | Mínima |
|
||||
| UML | Sí, en el camino crítico | Sí, en todas las fases | No obligatorio |
|
||||
| Casos de uso | Sí, centrales | Sí, conductores | Opcionales |
|
||||
| Iterativo | Opcional | Sí | Sí |
|
||||
| Tamaño del equipo | 1-5 personas | 5-30 personas | 3-9 personas |
|
||||
| Tiempo por iteración | Semanas | Meses | Semanas |
|
||||
|
||||
## Recursos externos
|
||||
|
||||
- Libro original: *Use Case Driven Object Modeling with UML* (Rosenberg & Scott).
|
||||
- Sitio oficial: http://www.iconixprocess.com/
|
||||
- Resumen en español: https://es.wikipedia.org/wiki/ICONIX
|
||||
|
||||
## Próxima sección
|
||||
|
||||
→ [Aplicación a Odoo](02_aplicacion_a_odoo.md) — cómo se adaptó ICONIX específicamente para este proyecto.
|
||||
@@ -0,0 +1,115 @@
|
||||
# Aplicación de ICONIX a Odoo
|
||||
|
||||
## Contexto específico
|
||||
|
||||
Este proyecto documenta la **ingeniería inversa** de los módulos nativos de Odoo 19.0 (Ventas, Facturación, Entregas, Inventario). Odoo es un ERP open-source complejo, con +30,000 archivos Python y más de 100 modelos en estos 4 módulos solamente.
|
||||
|
||||
Aplicar ICONIX directamente sobre Odoo presenta desafíos únicos:
|
||||
|
||||
1. **Herencia múltiple**: los modelos heredan de muchos mixins (`mail.thread`, `mail.activity.mixin`, `portal.mixin`, etc.). El "modelo de clases técnico" debe reflejar esto.
|
||||
2. **Campos computados**: muchos campos no están en la BD, se calculan dinámicamente (`_compute_*`).
|
||||
3. **Métodos `onchange`**: disparan lógica al cambiar un campo en el form.
|
||||
4. **Acciones (`ir.actions.act_window`)**: definen vistas, wizards, botones.
|
||||
5. **Multi-empresa y multi-moneda**: las reglas de registro y campos monetarios son contextuales.
|
||||
6. **Estado del modelo de dominio vs modelo técnico**:，我们必须separar los conceptos del negocio (Cliente, Producto, Pedido) de las clases técnicas (`res.partner`, `product.product`, `sale.order`).
|
||||
|
||||
## Adaptaciones realizadas
|
||||
|
||||
### 1. Separación modelo conceptual vs técnico
|
||||
|
||||
**Decisión clave**: mantener **dos diagramas de clases separados**.
|
||||
|
||||
- **Modelo conceptual** (`d_cla_con_gen_001_modelo_dominio.puml`): solo conceptos del negocio. Cliente, Producto, Presupuesto, Pedido, Factura, Pago. Atributos en lenguaje natural, no campos.
|
||||
- **Modelo técnico** (`d_cla_int_001_integracion_ven_stock_cont.puml`): las clases REALES de Odoo con sus `_name`, `_inherit`, campos y métodos. Aquí sí aparecen `res.partner`, `sale.order`, `account.move`, etc.
|
||||
|
||||
### 2. Uso de códigos de evidencia EV-*
|
||||
|
||||
Cada afirmación tiene un código que apunta a su fuente:
|
||||
|
||||
| Código | Significado | Verificable contra |
|
||||
|--------|-------------|---------------------|
|
||||
| `EV-COD-NNN` | Código fuente | Ruta de archivo + línea exacta |
|
||||
| `EV-XML-NNN` | Vista o dato XML | Ruta XML + elemento |
|
||||
| `EV-UI-NNN` | Comportamiento observado | Manual o screenshot |
|
||||
| `EV-DB-NNN` | Estructura de BD | Tabla y columnas |
|
||||
| `EV-DOC-NNN` | Documentación oficial | URL + sección |
|
||||
| `EV-TEST-NNN` | Prueba automatizada | Ruta del test |
|
||||
| `EV-INF-NNN` | Inferencia pendiente | (no verificado) |
|
||||
|
||||
Esto permite que un revisor pueda **verificar** cada afirmación abriendo el código en la línea exacta.
|
||||
|
||||
### 3. Foco en el flujo principal
|
||||
|
||||
La primera iteración se enfoca en **un solo flujo** end-to-end:
|
||||
|
||||
```
|
||||
Crear presupuesto → Confirmar pedido → Reservar productos →
|
||||
Validar entrega → Crear factura → Publicar factura → Registrar pago
|
||||
```
|
||||
|
||||
Es el flujo más importante del circuito comercial. Una vez documentado, se pueden agregar CU adicionales (cancelaciones, devoluciones, notas de crédito) en iteraciones siguientes.
|
||||
|
||||
### 4. PlantUML como formato estándar
|
||||
|
||||
Todos los diagramas están en **PlantUML** (texto plano, versionable). Esto permite:
|
||||
|
||||
- Editar los diagramas con cualquier editor.
|
||||
- Generar PDFs, PNGs, SVGs automáticamente.
|
||||
- Hacer diff de los cambios en git.
|
||||
|
||||
La cabecera estándar (en todos los .puml) es:
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
title SAP-TFI-2026 — <NOMBRE>
|
||||
|
||||
skinparam shadowing false
|
||||
skinparam handwritten false
|
||||
skinparam defaultFontName Arial
|
||||
skinparam defaultFontSize 12
|
||||
skinparam linetype ortho
|
||||
skinparam backgroundColor white
|
||||
|
||||
legend right
|
||||
Proyecto: SAP-TFI-2026
|
||||
Agente: saptfi2026
|
||||
Metodología: ICONIX
|
||||
Fuente: Ingeniería inversa de Odoo
|
||||
endlegend
|
||||
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 5. Reglas de naming
|
||||
|
||||
| Tipo | Patrón | Ejemplo |
|
||||
|------|--------|---------|
|
||||
| Caso de uso | `CU-{AREA}-{NNN}` | `CU-VEN-001` |
|
||||
| Regla de negocio | `RN-{AREA}-{NNN}` | `RN-VEN-002` |
|
||||
| Diagrama | `D-{TYPE}-{AREA}-{NNN}` | `D-ROB-VEN-004` |
|
||||
| Archivo | `lowercase_with_underscores` | `cu_ven_001_crear_presupuesto.md` |
|
||||
| Evidencia | `EV-{TYPE}-{NNN}` | `EV-COD-001` |
|
||||
|
||||
Áreas: `VEN` (Ventas), `FAC` (Facturación), `ENT` (Entregas), `INV` (Inventario), `ARQ` (Arquitectura), `DOM` (Dominio), `GEN` (General).
|
||||
|
||||
## Resultados de la primera iteración
|
||||
|
||||
- **7 CU** documentados con especificación completa (objetivo, alcance, actor, flujos, excepciones, RN, modelos Odoo, métodos, pantallas, evidencia).
|
||||
- **2 diagramas de robustez** (CU-VEN-001, CU-VEN-004, CU-ENT-002, CU-FAC-001).
|
||||
- **3 diagramas de secuencia** (idem).
|
||||
- **1 modelo de dominio conceptual** con 12 conceptos y 9 reglas de negocio.
|
||||
- **1 modelo de clases técnicas** mostrando la integración entre venta, stock y contabilidad.
|
||||
- **30 EV-COD** generadas (código verificado contra código real de Odoo 19.0).
|
||||
- **8 EV-INF** pendientes (reducidas desde 22 originales tras validación).
|
||||
|
||||
## Herramientas
|
||||
|
||||
- **Hermano (este agente)**: el swarm `saptfi2026` con 8 skills especializadas.
|
||||
- **PlantUML**: para generar los diagramas.
|
||||
- **Git**: para versionar todo.
|
||||
- **OpenRouter + minimax-m3**: como modelo de lenguaje.
|
||||
- **GitHub**: para publicar el repo (gate S2: push solo con OK manual de Ale).
|
||||
|
||||
## Próxima sección
|
||||
|
||||
→ [Cómo leer los CU](03_como_leer_los_cu.md) — guía paso a paso para interpretar las especificaciones.
|
||||
@@ -0,0 +1,167 @@
|
||||
# Cómo leer los Casos de Uso
|
||||
|
||||
## Estructura de un CU
|
||||
|
||||
Cada archivo `cu_xxx_nnn_nombre.md` tiene **20 secciones fijas**. Vamos a recorrerlas una por una con un ejemplo real.
|
||||
|
||||
## Ejemplo: CU-VEN-001 Crear Presupuesto
|
||||
|
||||
Vamos a leer el archivo [`cu_ven_001_crear_presupuesto.md`](../../02_casos_uso/cu_ven_001_crear_presupuesto.md) sección por sección.
|
||||
|
||||
### 1. Objetivo
|
||||
|
||||
> *"Crear un presupuesto de venta (sales quotation) para un cliente en estado `draft`."*
|
||||
|
||||
**Qué te dice**: en una frase, qué hace el CU. Si no podés resumir el CU en una oración, probablemente está mal definido.
|
||||
|
||||
### 2. Alcance
|
||||
|
||||
> *"Módulo `sale` de Odoo 19.0. Aplica al modelo `sale.order`."*
|
||||
|
||||
**Qué te dice**: en qué parte del sistema aplica. El módulo y el modelo principal.
|
||||
|
||||
### 3. Nivel
|
||||
|
||||
> *"Primario (esencial para el proceso de ventas)."*
|
||||
|
||||
**Tres valores posibles**:
|
||||
- **Primario**: esencial, no se puede eliminar.
|
||||
- **Secundario**: importante pero no esencial.
|
||||
- **Opcional**: nice-to-have.
|
||||
|
||||
### 4. Actor principal
|
||||
|
||||
> *"Vendedor (usuario con permisos `sales_team.group_sale_salesman`)."*
|
||||
|
||||
**Qué te dice**: quién inicia el CU. Siempre con el permiso técnico necesario.
|
||||
|
||||
### 5. Actores secundarios
|
||||
|
||||
> *"Cliente (consulta estado), Servicio de correo (envía presupuesto)."*
|
||||
|
||||
**Qué te dice**: otros actores involucrados pero que no inician el CU.
|
||||
|
||||
### 6. Interesados (stakeholders)
|
||||
|
||||
> *"Responsable de ventas (aprueba descuentos), Administración (visualiza pipeline)."*
|
||||
|
||||
**Qué te dice**: personas o sistemas afectados por el CU, aunque no participen directamente.
|
||||
|
||||
### 7. Disparador
|
||||
|
||||
> *"El vendedor hace clic en 'Nuevo' desde la vista kanban o tree de `sale.order`."*
|
||||
|
||||
**Qué te dice**: qué evento inicia el CU.
|
||||
|
||||
### 8. Precondiciones
|
||||
|
||||
> *"El usuario tiene acceso al módulo `sale`. Existe al menos un cliente activo en `res.partner`. El catálogo de productos contiene productos publicables."*
|
||||
|
||||
**Qué te dice**: qué condiciones deben cumplirse ANTES de que el CU pueda ejecutarse.
|
||||
|
||||
### 9. Garantías mínimas
|
||||
|
||||
> *"El sistema crea un registro `sale.order` en estado `draft` sin errores."*
|
||||
|
||||
**Qué te dice**: qué pasa **incluso si algo falla**. Por ejemplo, "se crea el registro aunque después falle otro paso".
|
||||
|
||||
### 10. Garantías de éxito
|
||||
|
||||
> *"El presupuesto tiene un `name` único asignado por la secuencia `sale.order`. Los totales se calculan automáticamente con impuestos."*
|
||||
|
||||
**Qué te dice**: qué pasa **cuando todo sale bien**.
|
||||
|
||||
### 11. Flujo principal (paso a paso)
|
||||
|
||||
> 1. Vendedor hace clic en "Nuevo" → sistema crea `sale.order` en estado `draft`.
|
||||
> 2. Sistema asigna `name` con valor por defecto...
|
||||
> 3. Vendedor selecciona `partner_id`...
|
||||
|
||||
**Qué te dice**: la secuencia de pasos **felices**. Cada paso debe ser verificable.
|
||||
|
||||
### 12. Flujos alternativos
|
||||
|
||||
> FA-01 — Aplicar descuento
|
||||
> 1. Vendedor edita `discount` en una línea...
|
||||
|
||||
**Qué te dice**: variaciones del flujo principal. Se numeran como FA-NN.
|
||||
|
||||
### 13. Excepciones
|
||||
|
||||
> EX-01 — Cliente sin dirección de entrega
|
||||
> 1. Al intentar confirmar (estado `sale`), sistema valida...
|
||||
|
||||
**Qué te dice**: qué pasa cuando algo falla. Se numeran como EX-NN.
|
||||
|
||||
### 14. Reglas de negocio
|
||||
|
||||
> - **RN-VEN-001**: `state` solo puede pasar de `draft` → `sent` → `sale`, o a `cancel`.
|
||||
|
||||
**Qué te dice**: reglas que el sistema debe enforzar. Se numeran como RN-{AREA}-{NNN}.
|
||||
|
||||
### 15. Datos de entrada / salida
|
||||
|
||||
**Entrada**: cliente, compañía, moneda, lista de precios, líneas.
|
||||
**Salida**: registro `sale.order` persistido, líneas, correo.
|
||||
|
||||
**Qué te dice**: qué información fluye hacia adentro y hacia afuera.
|
||||
|
||||
### 16. Estados involucrados
|
||||
|
||||
> `draft` → `sent` → `sale` (o `cancel`).
|
||||
|
||||
**Qué te dice**: las transiciones de estado del modelo.
|
||||
|
||||
### 17. Pantallas involucradas
|
||||
|
||||
> - `view_sale_order_form`
|
||||
> - `view_sale_order_kanban`
|
||||
> - `view_sale_order_tree`
|
||||
|
||||
**Qué te dice**: las vistas que el usuario ve durante el CU.
|
||||
|
||||
### 18. Modelos y métodos de Odoo
|
||||
|
||||
> **Modelos**: `sale.order`, `sale.order.line`, `res.partner`, `product.product`...
|
||||
> **Métodos**: `action_quotation_send()`, `action_confirm()`, `_compute_amounts()`...
|
||||
|
||||
**Qué te dice**: las clases técnicas de Odoo y sus métodos. Acá empieza el modelo técnico.
|
||||
|
||||
### 19. Permisos y configuraciones
|
||||
|
||||
> - `sales_team.group_sale_salesman` (vendedor)
|
||||
> - `sales_team.group_sale_manager` (responsable)
|
||||
|
||||
**Qué te dice**: permisos requeridos y configuraciones que afectan el CU.
|
||||
|
||||
### 20. Evidencias de ingeniería inversa
|
||||
|
||||
> **EV-COD-001**: `addons/sale/models/sale_order.py:34-36` — definición de la clase `SaleOrder` con `_name = 'sale.order'`.
|
||||
|
||||
**Qué te dice**: **la fuente exacta** que respalda cada afirmación. **Esta es la sección más importante** del CU.
|
||||
|
||||
## Cómo navegar un CU para entender un proceso
|
||||
|
||||
1. **Empezá por el Objetivo y el Disparador** (sección 1 y 7).
|
||||
2. **Leé el Flujo principal** (sección 11) para entender el camino feliz.
|
||||
3. **Revisá las Reglas de negocio** (sección 14) para entender las restricciones.
|
||||
4. **Leé las Evidencias** (sección 20) para validar que lo que dice el CU coincide con el código real.
|
||||
5. Si necesitás detalle técnico, mirá las secciones 17-19 (pantallas, modelos, métodos).
|
||||
|
||||
## Diferencia entre CU y método técnico
|
||||
|
||||
Un **CU** describe **qué** hace el sistema desde la perspectiva del usuario. Un **método técnico** describe **cómo** lo hace.
|
||||
|
||||
Por ejemplo:
|
||||
|
||||
| CU | Método |
|
||||
|----|--------|
|
||||
| *"Vendedor confirma el pedido"* | `sale.order.action_confirm()` |
|
||||
| *"El sistema valida que las líneas tengan producto"* | `_confirmation_error_message()` retorna string si hay error |
|
||||
| *"Se envía email al cliente"* | `action_quotation_send()` abre wizard de email |
|
||||
|
||||
Cuando leas un CU, **no te pierdas en los métodos**. Lee primero el flujo, después mirá los métodos para entender la implementación.
|
||||
|
||||
## Próxima sección
|
||||
|
||||
→ [Ejercicios prácticos](04_ejercicios_practicos.md) — para fijar los conceptos.
|
||||
@@ -0,0 +1,146 @@
|
||||
# Ejercicios Prácticos
|
||||
|
||||
## Objetivo
|
||||
|
||||
Estos ejercicios te ayudan a **fijar los conceptos** de ICONIX aplicados a Odoo. Trabajan sobre los artefactos reales de este proyecto.
|
||||
|
||||
## Antes de empezar
|
||||
|
||||
Asegurate de tener:
|
||||
1. El código fuente de Odoo 19.0 clonado (en `~/proyectos/odoo_src/odoo`).
|
||||
2. Los CU de este proyecto (en `docs/02_casos_uso/`).
|
||||
3. Un editor de texto y PlantUML instalados.
|
||||
|
||||
## Ejercicio 1: Validar una afirmación con código
|
||||
|
||||
**Objetivo**: entender el flujo de evidencia EV-COD.
|
||||
|
||||
**Tarea**:
|
||||
1. Abrí el archivo `docs/02_casos_uso/cu_ven_001_crear_presupuesto.md`.
|
||||
2. Buscá la evidencia `EV-COD-001`.
|
||||
3. Abrí el archivo `addons/sale/models/sale_order.py` en `~/proyectos/odoo_src/odoo/`.
|
||||
4. Andá a las líneas 34-36.
|
||||
5. Verificá que el código realmente coincide con lo que dice la evidencia.
|
||||
|
||||
**Pregunta para responder**:
|
||||
- ¿Qué patrón sigue la herencia de `SaleOrder`? ¿Por qué creés que se eligieron esos mixins?
|
||||
|
||||
## Ejercicio 2: Diferenciar modelo conceptual de técnico
|
||||
|
||||
**Objetivo**: entender por qué mantenemos dos diagramas separados.
|
||||
|
||||
**Tarea**:
|
||||
1. Abrí `diagrams/plantuml/d_cla_con_gen_001_modelo_dominio.puml` (modelo conceptual).
|
||||
2. Abrí `diagrams/plantuml/d_cla_int_001_integracion_ven_stock_cont.puml` (modelo técnico).
|
||||
3. Compilá ambos con PlantUML: `java -jar plantuml.jar -tpdf archivo.puml`.
|
||||
4. Compará los PDFs.
|
||||
|
||||
**Preguntas para responder**:
|
||||
- ¿Qué conceptos están en el conceptual pero NO en el técnico? ¿Por qué?
|
||||
- ¿Qué campos del técnico NO están en el conceptual? ¿Por qué?
|
||||
- ¿Cuándo usarías uno y cuándo el otro?
|
||||
|
||||
## Ejercicio 3: Seguir un flujo de punta a punta
|
||||
|
||||
**Objetivo**: trazar el flujo completo del CU-VEN-001 al código real.
|
||||
|
||||
**Tarea**:
|
||||
1. Abrí el CU-VEN-001 (`docs/02_casos_uso/cu_ven_001_crear_presupuesto.md`).
|
||||
2. Abrí `diagrams/plantuml/d_sec_ven_001_crear_presupuesto.puml` (secuencia).
|
||||
3. Compilá ambos y mirá los PDFs.
|
||||
4. Para cada paso del flujo principal, identificá:
|
||||
- Qué archivo y método de Odoo se ejecuta.
|
||||
- Qué tabla de BD se modifica.
|
||||
- Qué evidencia (EV-COD) lo respalda.
|
||||
|
||||
**Output esperado**: una tabla con columnas `Paso | Método Odoo | Tabla BD | Evidencia`.
|
||||
|
||||
## Ejercicio 4: Crear un CU nuevo
|
||||
|
||||
**Objetivo**: aplicar ICONIX para agregar un caso que NO está en la primera iteración.
|
||||
|
||||
**Tarea**: elegí UNO de los siguientes CU y documentalo siguiendo la plantilla:
|
||||
|
||||
### Opción A: CU-VEN-005 Cancelar pedido
|
||||
|
||||
**Contexto**: el vendedor necesita cancelar un pedido que ya estaba confirmado.
|
||||
|
||||
**Pasos**:
|
||||
1. Leé CU-VEN-001 y CU-VEN-004 para entender el contexto.
|
||||
2. Investigá el método `action_cancel()` en `addons/sale/models/sale_order.py:1324`.
|
||||
3. Investigá también cómo `sale_stock` extiende la cancelación.
|
||||
4. Escribí `docs/02_casos_uso/cu_ven_005_cancelar_pedido.md`.
|
||||
5. Generá el diagrama de robustez y secuencia.
|
||||
6. Generá EV-COD para cada afirmación.
|
||||
|
||||
### Opción B: CU-FAC-005 Emitir nota de crédito
|
||||
|
||||
**Contexto**: el facturador necesita revertir una factura publicada.
|
||||
|
||||
**Pasos**:
|
||||
1. Investigá el flujo de notas de crédito en Odoo 19.
|
||||
2. Buscá `_reverse_moves()` o `action_reverse()` en `addons/account/models/account_move.py`.
|
||||
3. Documentá el CU.
|
||||
4. Generá los diagramas y las evidencias.
|
||||
|
||||
### Opción C: CU-INV-001 Consultar existencias
|
||||
|
||||
**Objetivo**: el operador de inventario quiere ver cuántas unidades hay de un producto.
|
||||
|
||||
**Pasos**:
|
||||
1. Investigá el modelo `stock.quant` en `addons/stock/models/stock_quant.py`.
|
||||
2. Investigá cómo se accede desde el form de producto.
|
||||
3. Documentá el CU.
|
||||
4. Generá los diagramas y las evidencias.
|
||||
|
||||
## Ejercicio 5: Validar una EV-INF
|
||||
|
||||
**Objetivo**: cerrar el ciclo de evidencia.
|
||||
|
||||
**Tarea**:
|
||||
1. Abrí `evidence/index.md`.
|
||||
2. Elegí UNA EV-INF pendiente (ejemplo: EV-INF-008 sobre `button_validate`).
|
||||
3. Buscá el código relevante en Odoo:
|
||||
- `grep -n "def button_validate" addons/stock/models/stock_picking.py`
|
||||
- Leé el método completo (~50 líneas).
|
||||
4. Verificá si la inferencia es correcta.
|
||||
5. Si es correcta: convertila en EV-COD con la ruta y línea exacta.
|
||||
6. Si es incorrecta: marcala como obsoleta y proponé una EV-COD corregida.
|
||||
|
||||
## Ejercicio 6: Mejorar la trazabilidad
|
||||
|
||||
**Objetivo**: entender la matriz de trazabilidad.
|
||||
|
||||
**Tarea**:
|
||||
1. Abrí `docs/09_trazabilidad/matriz_trazabilidad.md`.
|
||||
2. Agregá una fila para CU-VEN-005 (cancelación).
|
||||
3. Definí las relaciones:
|
||||
- ¿Qué reglas de negocio aplica?
|
||||
- ¿A qué modelo Odoo apunta?
|
||||
- ¿Qué evidencia EV-COD lo respalda?
|
||||
4. Actualizá la matriz.
|
||||
|
||||
## Criterios de evaluación
|
||||
|
||||
| Criterio | Excelente | Aceptable | Necesita mejora |
|
||||
|----------|-----------|------------|-----------------|
|
||||
| Uso de evidencia | Cada afirmación tiene EV-COD con línea exacta | Algunas EV-INF | Muchas afirmaciones sin evidencia |
|
||||
| Separación conceptual/técnico | Clara y justificada | Presente pero confusa | Mezclados |
|
||||
| Compilabilidad PlantUML | Todos los .puml compilan sin error | Algunos fallan | Muchos fallan |
|
||||
| Trazabilidad | Matriz completa y consistente | Algunas relaciones | Sin matriz |
|
||||
| Aplicación de ICONIX | Las 9 fases reflejadas en artefactos | Algunas fases | Solo CU, sin resto |
|
||||
|
||||
## Recursos para profundizar
|
||||
|
||||
- **Libros**:
|
||||
- *Use Case Driven Object Modeling with UML* — Rosenberg & Scott.
|
||||
- *Applying UML and Patterns* — Craig Larman.
|
||||
- *OCA Odoo Development Essentials* — Daniel Reis (para Odoo técnico).
|
||||
|
||||
- **Sitios web**:
|
||||
- https://www.odoo.com/documentation/19.0/ — docs oficiales de Odoo 19.
|
||||
- https://github.com/odoo/odoo/tree/19.0 — código fuente.
|
||||
|
||||
- **Herramientas**:
|
||||
- PlantUML: https://plantuml.com/
|
||||
- Odoo CLI: https://www.odoo.com/documentation/19.0/administration/install/cli.html
|
||||
@@ -0,0 +1,38 @@
|
||||
# Material Educativo — SAP-TFI-2026
|
||||
|
||||
> Material pedagógico para estudiantes del curso SAP-TFI-2026 y revisores técnicos.
|
||||
|
||||
## ¿Qué encontrarás aquí?
|
||||
|
||||
Este material explica **cómo se aplicó la metodología ICONIX** para hacer ingeniería inversa de los módulos nativos de Odoo 19.0 (Ventas, Facturación, Entregas, Inventario). Está pensado para que cualquier estudiante o analista pueda entender el proceso y replicarlo.
|
||||
|
||||
## Secciones
|
||||
|
||||
| # | Sección | Descripción |
|
||||
|---|---------|-------------|
|
||||
| 1 | [¿Qué es ICONIX?](01_que_es_iconix.md) | Introducción a la metodología ICONIX |
|
||||
| 2 | [Aplicación a Odoo](02_aplicacion_a_odoo.md) | Cómo se adaptó ICONIX a Odoo |
|
||||
| 3 | [Cómo leer los CU](03_como_leer_los_cu.md) | Guía para leer las especificaciones de casos de uso |
|
||||
| 4 | [Ejercicios prácticos](04_ejercicios_practicos.md) | Ejercicios para fijar los conceptos |
|
||||
|
||||
## Audiencia
|
||||
|
||||
- **Estudiantes** del curso SAP-TFI-2026 que están aprendiendo ICONIX.
|
||||
- **Analistas funcionales** que necesitan entender Odoo antes de implementarlo.
|
||||
- **Desarrolladores** que quieren entender cómo está estructurado Odoo por dentro.
|
||||
- **Revisores técnicos** que validan que la documentación refleja el código real.
|
||||
|
||||
## Cómo usar este material
|
||||
|
||||
1. **Empezá por la sección 1** para entender qué es ICONIX.
|
||||
2. **Leé la sección 2** para ver cómo se aplicó específicamente a Odoo.
|
||||
3. **Usá la sección 3 como referencia** cada vez que leas un CU.
|
||||
4. **Hacé los ejercicios de la sección 4** para fijar los conceptos.
|
||||
|
||||
## Regla de oro del material
|
||||
|
||||
> **Cada afirmación sobre Odoo tiene una fuente de evidencia.** Si no podés verificar una afirmación contra código, está marcada como `EV-INF` (inferencia pendiente). Si la podés verificar contra código real, está marcada como `EV-COD` (código verificado) con la ruta exacta del archivo y la línea.
|
||||
|
||||
## Cómo se generó
|
||||
|
||||
Este material fue generado por el agente `saptfi2026` (parte del swarm Hermano de Ale Sartorio) aplicando la metodología ICONIX de manera rigurosa, con verificación contra el código fuente oficial de Odoo 19.0 (rama `19.0` del repositorio `https://github.com/odoo/odoo`).
|
||||
Reference in New Issue
Block a user