mirror of
https://github.com/cursos-uai/sap_tfi_2026.git
synced 2026-07-31 20:48:30 -03:00
saptfi2026-bot
a55f74144a
Cambios al README.md:
1. Paso 3 actualizado: recomienda abrir los SVG como formato principal
para estudiar diagramas. Explica pros/contras de cada formato
(SVG/PDF/PNG) y como regenerar los 3 con PlantUML.
2. Nueva seccion "Referencia bibliografcia" agregada antes de
"Recomendaciones para el TP":
- Libro de ICONIX (Rosenberg & Scott) con link al Google Drive
provisto por el usuario
- PPT sobre ICONIX (material complementario)
- Otras referencias (Gamma GoF, Cristia UNR, docs Odoo)
321 lines
16 KiB
Markdown
321 lines
16 KiB
Markdown
# SAP-TFI-2026 — Apunte de Clase
|
|
|
|
> Material de apoyo para la resolución del Trabajo Práctico de la sección técnica del curso SAP-TFI-2026.
|
|
> Facultad de Ciencias Exactas, Ingeniería y Agrimensura — Universidad Nacional de Rosario (o la institución que corresponda).
|
|
> Última actualización: 2026-06-18.
|
|
|
|
---
|
|
|
|
## ¿Qué es este repositorio?
|
|
|
|
Este repositorio es **material de apoyo** para que los alumnos del curso SAP-TFI-2026 puedan resolver el Trabajo Práctico (TP) de la sección técnica. Contiene:
|
|
|
|
- **Diagramas ICONIX** (PlantUML) de los casos de uso core del dominio ERP (Ventas, Facturación, Entregas, Inventario).
|
|
- **Documentación explicativa** de cada artefacto siguiendo la metodología ICONIX.
|
|
- **Casos de uso modelo** (CU-VEN-001, CU-VEN-004, CU-ENT-002, CU-ENT-004, CU-FAC-001, CU-FAC-002, CU-FAC-003) que sirven como referencia para el TP.
|
|
- **Material pedagógico** en `docs/10_material_estudio/` con guías paso a paso.
|
|
- **Checklists de calidad** en `docs/11_validacion/` para auto-evaluación de los diagramas.
|
|
|
|
### ¿Qué NO es este repositorio?
|
|
|
|
- **No es la solución del TP**. Cada alumno debe producir su propia versión.
|
|
- **No es código fuente** que el alumno deba ejecutar. Es documentación.
|
|
- **No es opcional**. El alumno debe usar este repositorio como punto de partida para entender la metodología ICONIX aplicada al dominio ERP.
|
|
|
|
---
|
|
|
|
## ¿Cómo está organizado?
|
|
|
|
```
|
|
sap_tfi_2026/
|
|
├── README.md ← este archivo
|
|
├── docs/
|
|
│ ├── 00_plan/ ← plan del proyecto
|
|
│ ├── 01_contexto/ ← contexto de Odoo 19.0
|
|
│ ├── 02_casos_uso/ ← 7 CU modelo (referencia para el TP)
|
|
│ ├── 03_dominio/ ← modelo de dominio
|
|
│ ├── 04_arquitectura/ ← arquitectura general
|
|
│ ├── 05_prototipos/ ← prototipos de UI
|
|
│ ├── 09_trazabilidad/ ← matriz de trazabilidad
|
|
│ ├── 10_material_estudio/ ← material pedagógico
|
|
│ ├── 11_validacion/ ← checklists ICONIX
|
|
│ └── 12_patrones_diseno/ ← patrones de diseño aplicados
|
|
├── diagrams/
|
|
│ ├── plantuml/ ← código fuente .puml
|
|
│ ├── png/ ← versiones PNG
|
|
│ ├── svg/ ← versiones SVG
|
|
│ └── pdf/ ← versiones PDF
|
|
├── evidence/
|
|
│ └── index.md ← catálogo de evidencias
|
|
└── .gitignore
|
|
```
|
|
|
|
---
|
|
|
|
## Cómo usar este repositorio para el TP
|
|
|
|
### Paso 1: Entender la metodología ICONIX
|
|
|
|
Antes de hacer cualquier diagrama, leé:
|
|
|
|
- **`docs/10_material_estudio/01_que_es_iconix.md`** — qué es ICONIX.
|
|
- **`docs/10_material_estudio/02_aplicacion_a_odoo.md`** — cómo se adaptó a Odoo.
|
|
|
|
### Paso 2: Estudiar los casos de uso modelo
|
|
|
|
Los 7 CU modelo están en **`docs/02_casos_uso/`**. Cada uno tiene la estructura completa:
|
|
|
|
- Nombre, objetivo, pre/post-condición
|
|
- Pasos trascendentes (en voz activa)
|
|
- Caminos alternativos
|
|
- Excepciones, reglas de negocio
|
|
- Diagramas asociados (robustez, secuencia, clases)
|
|
|
|
**Sugerencia**: empezá por `cu_ven_001_crear_presupuesto.md` (es el más simple) y avanzá progresivamente.
|
|
|
|
### Paso 3: Estudiar los diagramas
|
|
|
|
Los diagramas están en **`diagrams/plantuml/`** (código fuente) y en los formatos renderizados **`diagrams/pdf/`** (PDF), **`diagrams/png/`** (PNG) y **`diagrams/svg/`** (SVG).
|
|
|
|
**Formatos recomendados para abrir los diagramas**:
|
|
|
|
- **SVG** — formato vectorial recomendado para visualizar diagramas en el navegador o en visores SVG. Permite zoom sin pérdida de calidad, ideal para revisar diagramas grandes con muchos elementos. Se puede abrir directamente en cualquier navegador moderno (Chrome, Firefox, Edge, Safari) o en visores como Inkscape.
|
|
- **PDF** — formato portable para imprimir o compartir. Mantiene la calidad vectorial pero es de solo lectura.
|
|
- **PNG** — formato rasterizado para incrustar en documentos o presentaciones.
|
|
|
|
**Para visualizar**:
|
|
|
|
1. **Abrir el SVG**: hacé doble click en cualquier archivo de `diagrams/svg/` o arrastralo a tu navegador. Es la opción recomendada para estudiar los diagramas porque mantiene la calidad al hacer zoom y permite copiar elementos como texto.
|
|
2. **Abrir el PDF**: doble click en cualquier archivo de `diagrams/pdf/` (se abre en cualquier lector de PDF).
|
|
3. **Abrir el PNG**: doble click en cualquier archivo de `diagrams/png/` (se abre en cualquier visor de imágenes).
|
|
|
|
**Para regenerar** (si querés modificar los `.puml`):
|
|
|
|
- Instalá PlantUML (`apt-get install plantuml` o descargá el jar de https://plantuml.com/download).
|
|
- Ejecutá `plantuml -tsvg -tpng -tpdf diagrams/plantuml/*.puml` para regenerar los 3 formatos.
|
|
- **Recomendación**: regenerá siempre los 3 formatos después de modificar cualquier `.puml` para mantener la consistencia.
|
|
|
|
### Paso 4: Aplicar ICONIX a tu TP
|
|
|
|
Para cada CU que debas documentar:
|
|
|
|
1. Identificá los actores.
|
|
2. Escribí la especificación del CU (usá `docs/02_casos_uso/cu_ven_001_crear_presupuesto.md` como plantilla).
|
|
3. Generá el diagrama de robustez (`diagrams/plantuml/d_rob_*.puml` como plantilla).
|
|
4. Generá el diagrama de secuencia (`diagrams/plantuml/d_sec_*.puml` como plantilla).
|
|
5. Generá el diagrama de clases técnico (`diagrams/plantuml/d_cla_int_*.puml` como plantilla).
|
|
6. Aplicá el checklist (`docs/11_validacion/checklists_iconix.md`).
|
|
|
|
### Paso 5: Validar
|
|
|
|
Antes de entregar tu TP:
|
|
|
|
- Aplicá los checklists de `docs/11_validacion/checklists_iconix.md`.
|
|
- Verificá que cada CU tenga su diagrama de robustez, secuencia y clases.
|
|
- Verificá que la matriz de trazabilidad esté completa.
|
|
|
|
---
|
|
|
|
## Ejemplos de diagramas ICONIX para casos de uso core de ERP
|
|
|
|
A continuación se muestran los diagramas principales del repositorio. Cada uno corresponde a un caso de uso core del dominio ERP.
|
|
|
|
### Ejemplo 1: Diagrama de Casos de Uso (D-CU-GEN-002)
|
|
|
|
El diagrama de CU muestra los casos de uso principales del flujo comercial, con relaciones `<<include>>` (sub-flujos obligatorios) y `<<extend>>` (sub-flujos opcionales).
|
|
|
|
**Actores**:
|
|
- Vendedor (crea presupuestos, confirma pedidos)
|
|
- Operario de Almacén (reserva productos, valida entregas)
|
|
- Facturador (crea, publica y registra pagos de facturas)
|
|
- Sistema (autentica)
|
|
|
|
**Casos de uso principales**:
|
|
- `CU-VEN-001` Crear presupuesto
|
|
- `CU-VEN-004` Confirmar pedido de venta
|
|
- `CU-ENT-002` Reservar productos en almacén
|
|
- `CU-ENT-004` Validar entrega de productos
|
|
- `CU-FAC-001` Crear factura desde pedido
|
|
- `CU-FAC-002` Publicar factura
|
|
- `CU-FAC-003` Registrar pago
|
|
|
|
**5 relaciones <<include>>** (sub-flujos obligatorios):
|
|
- `CU-AUTH-001` Validar sesión de usuario (incluido por CU-VEN-001 y CU-VEN-004)
|
|
- `CU-CALC-001` Calcular totales con impuestos (incluido por CU-VEN-001)
|
|
- `CU-GENPICK-001` Generar picking de entrega (incluido por CU-VEN-004)
|
|
- `CU-VALLIN-001` Validar líneas pendientes (incluido por CU-FAC-001)
|
|
- `CU-GENJOUR-001` Crear asiento contable (incluido por CU-FAC-002)
|
|
|
|
**5 relaciones <<extend>>** (sub-flujos opcionales/condicionales):
|
|
- `CU-VEN-001-EMAIL` Enviar presupuesto por email (opcional)
|
|
- `CU-VEN-001-DISC` Aplicar descuento (opcional)
|
|
- `CU-ENT-002-MTO` Generar orden de compra (MTO) (opcional)
|
|
- `CU-ENT-004-BACK` Crear backorder de entrega parcial (opcional)
|
|
- `CU-FAC-002-VAL` Validar asiento anormal (opcional)
|
|
|
|
**Diagrama**: `diagrams/plantuml/d_cu_gen_002_casos_uso_extend_include.puml`
|
|
|
|
**Lección para el alumno**: en ICONIX, las relaciones `<<include>>` se usan para sub-flujos obligatorios (siempre se ejecutan), mientras que `<<extend>>` se usa para sub-flujos opcionales (solo se ejecutan bajo ciertas condiciones). El diagrama de CU debe mostrar ambos tipos cuando apliquen.
|
|
|
|
---
|
|
|
|
### Ejemplo 2: Diagrama de Robustez (D-ROB-VEN-001)
|
|
|
|
El diagrama de robustez muestra qué objetos intervienen en un CU, clasificándolos en boundary (vista), control (coordinador) y entity (objeto persistente).
|
|
|
|
Para el CU-VEN-001 (Crear Presupuesto):
|
|
|
|
- **Actor**: Vendedor
|
|
- **Boundary**: `Boton Nuevo`, `Form (view_sale_order_form)`
|
|
- **Control**: `SaleOrder (action_quotation_send)`, `Mail Compose (mail.compose.message)`
|
|
- **Entity**: `sale.order (draft)`, `mail.mail`
|
|
|
|
**Flujo principal** (pasos en voz activa):
|
|
|
|
1. Vendedor **presiona** "Nuevo" → Botón Nuevo **crea** sale.order en draft → abre form.
|
|
2. Vendedor **completa** cliente y líneas → form **actualiza** sale.order → recalcula totales.
|
|
3. (Opcional) Vendedor **presiona** "Enviar" → action_quotation_send **invoca** → marca enviado → Mail Compose **crea** mail.mail → **envía** email.
|
|
|
|
**Lección para el alumno**: el diagrama de robustez usa exactamente 3 tipos de elementos (boundary/control/entity). Los mensajes entre elementos son verbos en voz activa que después se traducen 1:1 a los pasos del CU. Si un verbo no aparece en el diagrama de robustez, no puede aparecer en la especificación del CU.
|
|
|
|
---
|
|
|
|
### Ejemplo 3: Diagrama de Secuencia (D-SEC-VEN-004)
|
|
|
|
El diagrama de secuencia muestra las interacciones en el tiempo entre los lifelines (actor, vistas, controles, entidades, base de datos).
|
|
|
|
Para el CU-VEN-004 (Confirmar Pedido):
|
|
|
|
- **Lifelines**: Vendedor, Form, SaleOrder, Validator, Conf. Values, Stock Layer, Invoice Layer, PostgreSQL
|
|
- **Mensajes numerados** (orden temporal estricto)
|
|
- **Activate/deactivate** para cada llamada
|
|
- **Alt/else/opt** para flujos alternativos
|
|
- **SQL queries explícitos** (SELECT, INSERT, UPDATE)
|
|
|
|
**Lección para el alumno**: el diagrama de secuencia debe mostrar la base de datos explícitamente y los SQL queries como mensajes. Esto permite que un DBA o un desarrollador verifiquen la implementación sin tener que leer código.
|
|
|
|
---
|
|
|
|
### Ejemplo 4: Diagrama de Clases Técnico (D-CLA-INT-001)
|
|
|
|
El diagrama de clases técnico muestra las clases reales de Odoo con sus `_name`, `_inherit`, campos y métodos.
|
|
|
|
Para la integración venta/stock/contabilidad:
|
|
|
|
- `<sale.order>` (modelo `_name = 'sale.order'`, `_inherit = ['mail.thread', ...]`)
|
|
- `<sale.order.line>` (líneas de pedido)
|
|
- `<stock.picking>` (entregas)
|
|
- `<stock.move>` (movimientos)
|
|
- `<account.move>` (facturas)
|
|
- `<account.move.line>` (líneas de factura)
|
|
|
|
**Relaciones**:
|
|
- SO "1" *-- "*" SOL : order_line (One2many)
|
|
- SO "1" *-- "*" AM : invoice_ids
|
|
- SP "*" --> "1" SO : sale_id
|
|
- AM "*" --> "1" SOL : invoice_line_ids
|
|
|
|
**Lección para el alumno**: el diagrama de clases técnico refleja el código real de Odoo, no el modelo conceptual. Cada clase tiene `_name` (nombre técnico) y los campos tienen tipo (Many2one, One2many, Float, etc.). Las relaciones muestran cómo se conectan los modelos vía foreign keys.
|
|
|
|
---
|
|
|
|
### Ejemplo 5: Diagrama de Arquitectura Estratificada (D-ARQ-TECH-001)
|
|
|
|
El diagrama de arquitectura muestra las capas del stack tecnológico de Odoo:
|
|
|
|
- **Capa 1**: Cliente (navegador, JS runtime)
|
|
- **Capa 2**: Servidor de aplicación (4 subcapas: Presentación, Web, Logic, Addons)
|
|
- **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.
|
|
|
|
---
|
|
|
|
### Ejemplo 6: Patrón Composite aplicado a BoM (D-PAT-COMPOSITE-001)
|
|
|
|
El diagrama del patrón Composite muestra cómo Odoo implementa la Lista de Materiales (Bill of Materials) usando el patrón Composite de GoF:
|
|
|
|
- **Component** (interfaz abstracta) → `BomComponent`
|
|
- **Leaf** (producto simple) → `product.product`
|
|
- **Composite** (producto con BoM) → `mrp.bom`
|
|
- **children** (lista de hijos) → campo `bom_line_ids` (One2many)
|
|
- **Operation** → método `explode(product, quantity)`
|
|
|
|
**Lección para el alumno**: Odoo usa patrones de diseño estándar (GoF). Identificar el patrón aplicado a cada subsistema es clave para entender cómo está estructurado el código. La documentación del patrón debe seguir el estándar de la FCEIA-UNR (Cristia, 2015).
|
|
|
|
---
|
|
|
|
## Recursos adicionales
|
|
|
|
### Material pedagógico
|
|
|
|
- **`docs/10_material_estudio/README.md`** — índice del material de estudio.
|
|
- **`docs/10_material_estudio/01_que_es_iconix.md`** — qué es ICONIX.
|
|
- **`docs/10_material_estudio/02_aplicacion_a_odoo.md`** — cómo se aplicó a Odoo.
|
|
- **`docs/10_material_estudio/03_como_leer_los_cu.md`** — cómo leer las CU.
|
|
- **`docs/10_material_estudio/04_ejercicios_practicos.md`** — ejercicios prácticos.
|
|
|
|
### Validación
|
|
|
|
- **`docs/11_validacion/checklists_iconix.md`** — checklists por tipo de diagrama, con aplicación a los 12 diagramas existentes.
|
|
|
|
### Patrones de diseño
|
|
|
|
- **`docs/12_patrones_diseno/composite_bom.md`** — patrón Composite aplicado a BoM, con documentación siguiendo estándar UNR.
|
|
|
|
### Evidencias
|
|
|
|
- **`evidence/index.md`** — catálogo de 30 EV-COD y 8 EV-INF verificables contra código real de Odoo 19.0.
|
|
|
|
---
|
|
|
|
## Referencia bibliográfica
|
|
|
|
Material de lectura recomendado para profundizar en la metodología ICONIX y su aplicación en este curso.
|
|
|
|
### Libro de ICONIX (recomendado para la materia)
|
|
|
|
- **Use Case Driven Object Modeling with UML** — Doug Rosenberg y Kendall Scott
|
|
- 📖 Acceso: https://drive.google.com/file/d/1brsFcTJIR-EBr7y7NCZHUdjSAJnQQu1U/view?usp=sharing
|
|
- Libro de referencia principal de la metodología ICONIX. Cubre en detalle cada fase: casos de uso, modelo de dominio, robustez, secuencia y clases. Lectura obligatoria para el TP.
|
|
|
|
### Presentación sobre ICONIX (PPT)
|
|
|
|
- **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.
|
|
|
|
### 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.
|
|
- **Cristia, M.** (2015). *Standard for Documenting Design Patterns in Software Design*. FCEIA, Universidad Nacional de Rosario. https://www.fceia.unr.edu.ar/ingsoft/patrones-doc.pdf — estándar usado en `docs/12_patrones_diseno/composite_bom.md`.
|
|
- **Odoo S.A.** (2024). *Odoo 19.0 Documentation*. https://www.odoo.com/documentation/19.0/ — documentación oficial de Odoo.
|
|
- **Repositorio oficial de Odoo**: https://github.com/odoo/odoo (rama `19.0`) — código fuente utilizado como base para la ingeniería inversa.
|
|
|
|
---
|
|
|
|
## Recomendaciones para el TP
|
|
|
|
1. **No copies directamente**. Los CU modelo son para entender la metodología, no para copiar. Cada alumno debe producir su propia versión adaptada a su contexto.
|
|
|
|
2. **Verificá contra código real**. Cada afirmación sobre Odoo debe tener una evidencia EV-COD con ruta exacta del archivo y línea. Esto distingue la ingeniería inversa seria de la invención.
|
|
|
|
3. **Usá los checklists antes de entregar**. Aplicá los checklists de `docs/11_validacion/checklists_iconix.md` antes de entregar el TP. Un diagrama que no pasa el checklist no debe ser entregado.
|
|
|
|
4. **Compilá los .puml**. Un .puml que no compila no sirve. Antes de entregar, regenerá todos los PDFs y verificá que se ven bien.
|
|
|
|
5. **Mantené la trazabilidad**. Cada CU debe tener su diagrama de robustez, secuencia y clases. La matriz de trazabilidad debe estar completa.
|
|
|
|
---
|
|
|
|
## Contacto y soporte
|
|
|
|
- **Operador del repositorio**: Ale Sartorio
|
|
- **Issues**: usar el sistema de issues del repositorio en GitHub
|
|
- **Email**: (según corresponda al curso)
|
|
|
|
---
|
|
|
|
## Licencia
|
|
|
|
Este material se distribuye bajo la licencia Creative Commons BY-SA 4.0. Podés usarlo, modificarlo y redistribuirlo libremente, citando la fuente. |