Pcn01 Cursoddd s01 v2

Domain Driven Design Diseo Guiado por Dominio
Instructor: Ramiro Gonzlez Snchez rgonzalez@ids.com.mx Rafael Martnez Montiel rmmontiel@ids.com.mx
Av. Insurgentes Sur 1388 PH 03230, Mxico D.F. (5255) T. 2789 8400 www.ids.com.mx
Ms de 25 aos comprometidos con nuestros clientes, siendo sus socios tecnolgicos. informacin confidencial Direccin de Tecnologa y Calidad
1 1
Temario
Sesin 1
Objetivos del curso Introduccin Lenguaje comn (Ubiquitous language) Introduccin a DDD Ejercicio
Sesin 2
Temario
Introduccin a UML para Diseo Expresando el Modelo en software Aislando el dominio
Sesin 3
Expresando el Modelo en software Expresar el Modelo en software Ciclo de vida de un objeto de dominio Implementacin de DDD
\\smprodtq2\info \cursos\general\tecnicas\ddd
informacin confidencial Direccin de Tecnologa y Calidad
Pre-requisitos para el curso

Conceptos slidos de Orientacin a objetos Conocimiento bsico de UML Patrones de diseo Desarrollo de Sistemas en alguna Tecnologa Orientada a Objetos
Java .NET
Objetivos del curso
Objetivos del curso

Diseo guiado por Dominio Comprender el paradigma de diseo guiado por dominio Identificar los patrones bsicos empleados Identificar las diferencias entre DDD y las prcticas actuales Conocer los principios para aplicar DDD Conocer los beneficios de aplicar DDD a proyectos en curso
Introduccin
Por qu es tan difcil hacer SW?
Ejercicio
Desarrolla una aplicacin que permita
Jugar Ajedrez desde un Smartphone contra una Computadora Central La Computadora Central debe ser capaz de jugar mltiples partidas simultneamente Se debe guardar historia de cada jugador, tanto localmente como centralmente Se debe rankear a los jugadores segn su historial de juego
El Elemento de Mayor Complejidad
Desconocimiento del Negocio por parte de Usuarios
Algunos son muy complejos (de hecho, son carreras universitarias): Logstica, Contabilidad, Impuestos, Crditos.
Algunos no pueden ser capturados en un Algoritmo. Ejemplo: Jugar Ajedrez, Trazo de rutas. En otros no hay consenso: Calificacin de Elegilibilidad para Otorgamiento de Crdito, Diseo de Espacios, Ensamble de Piezas, Manejo de Inventarios.
DDD
Si renes las mejores prcticas de
Arquitectura Modelado de Negocio Orientacin a Objetos
Lo que obtienes es: Domain Driven Design No es nada nuevo bajo el sol. Pero la integracin de Best Practices alineadas a un concepto eje es novedosa. El concepto eje es el
10
Qu es el Dominio?
Abstraccin Representacin OO depurada de lo que nos interesa del Negocio

11
Lo bien Hecho
Mantenibility
Fcil de Modificar Fcil de Extender
Testability
Fcil de Probar Fcil de Diagnosticar
12
Se aplica desde los Requerimeintos

Macro Process Milestones, Phases and Iterations
Incepcin: Proyecto aade valor? Es realizable? Elaboracin: Identificar fallas arquitectnicas, establecer polticas comunes, realizar pruebas de concepto Construccin: Desarrollo de un producto Desplegable (deployable) a produccin Transicin: Asegurar que el producto es aceptado por el usuario final
Scope is understood Architecture is stable System is Ready for end User testing System is Ready to be deployed
Inception
Iter I1
Elaboration
Iter E1 Iter E2 Iter C1
Construction
Iter C2 Iter C2 + n Iter T1
Transition
Iter T1 + m
Dominio Aislamiento Reutilizacin/ Testing
Requirements
Analisys & Design
|
Implementation Test Deployment Requirements
Analisys & Design
|
Implementation Test Deployment
Project Management Configuration and Change management Environment
Project Management
...
Configuration and Change management Environment
Time
13
Ubiquitous Language
Lenguaje comn
Conocimiento Depurado
El modelo es la base de comunicacin entre los involucrados
Los desarrolladores pueden comunicarse con los expertos sin necesidad de traduccin.
El modelo es conocimiento depurado (Distilled Knowledge)

El modelo es la forma como el equipo de trabajo estructura el conocimiento de dominio y como resalta los elementos de mayor inters La experiencia de primeras versiones del modelo funciona como retroalimentacin al proceso de modelado
15
Mundo Real Mundo Virtual

Varios equipos Un solo lenguaje Correspondencia entre:
Conceptos de negocio Representacin en Objetos Procesos de Negocio Algoritmos
Esta Transformacin, requiere un Esfuerzo. El cual normalmente no es considerado.
Un elemento crtico, es Aislar los Conceptos de Dominio de los Mecanismos de Implementacin.

Eliminar detalles de Implementacin, se le llama: Eliminar Obstculos.
16
Ejercicio 1
Ejercicio de modelado:
Control de Cursos
Un equipo - Un lenguaje
Qu entendemos por cada uno de los elementos anteriores? No hay algn concepto que se preste a confusin?
Modelando en voz alta

Curso Alumno Instructor Horario Aula Asistencia
Documentos y Diagramas
Qu diagramas o documentos nos ayudan a entender el modelo?
Documentos de diseo escritos

En que nivel de modelado queremos ubicarnos?
El punto Clave es Verificar que la Representacin de los conceptos es la misma para todos.
UML o no UML? Modelos de ejemplo
17
3 Niveles de Modelado
Conceptual (AR, Anlisis)
Solo Nombre de Clase, Relaciones y Atributos
Interfaz (Diseo)
Modelo Conceptual ms Mtodos Pblicos
Implementacin (CO y PR, TDD por ejemplo)

Modelo de Interfaz mas Mtodos Privados y Algoritmos
18
Desde aqu nace el Modelo de Clases de Anlisis (conocido tambin como Modelo de Dominio)
19
Ejemplo de Un Solo Lenguaje

En Espaol:
Un Alumno busca un Curso para inscribirse de acuerdo al tema, costo y horario. Los cursos que son Reservados, generan un Registro el cual pueden ser Confirmado o Cancelado posteriormente.
class Ej emplo Un Solo Lenguaj e
Curso
instantiate RegistroFactory CursoRepositorio + + findCursos() : void use reservaCurso(Curso) : void instantiate + + Cancelar() : void Confirmar() : void Registro
use
use Registro Confirmado Alumno Registro Cancelado
20
Eliminacin de Obstculos: Revela la Intencin, no la Implementacin

Cuando un Alumno reserva un curso y el cupo est completo, entonces el Alumno queda en lista de espera. Si hay espacio disponible, los datos del alumno se deben enviar va Web Service para su procesamiento en el sistema de pagos.
Obstculos en esta declaracin:

Fragmento Obstculo
Alumno queda en lista de espera Va Web Service

Procesamiento Sistema de Pagos
Sugiere una implementacin. Posiblemente asociado a cmo se administra actualmente. El hecho de que sea enviado por WS, no es resultado de una definicin de Dominio.
Ambiguo e indeterminado. En qu consiste dicho proceso? Obstculo de implementacin. Para este Dominio es irrelevante cmo se procesa el pago. Solo que existe un Pago es importante.
21
Elimina los obstculos, identificando los Conceptos detrs Alumno queda en lista de espera:
El alumno NO tiene un estatus. El verdadero resultado de la operacin, es que se genera un Registro de Inscripcin. Y es este registro el que tiene un estatus de En Espera.
Refactoriza el lenguaje:
Cuando un Alumno reserva un curso, se genera un Registro. Si hay cupo y el pago se ha recibido, entonces se confirma el Registro. Si el cupo est completo, entonces el Registro queda con estatus de En Espera y se administra como una lista de espera. En esta lista de espera, se procesan los Registros con una poltica de primero en llegar, primero en ser atendido.
22
Lecturas Recomendadas
Behavior-Driven Development (BDD)
http://dannorth.net/whats-in-a-story
http://bit.ly/aYsM1q (liga equivalente)
The Truth about BDD

http://blog.objectmentor.com/articles/2008/11/27/thetruth-about-bdd http://bit.ly/bTQqK2 (liga equivalente)
23
Introduccin a UML para Diseo
24
Lo que debes saber de UML

Se utilizan principalmente 3 diagramas:
Diagrama de Despliegue (deployment) Para mostrar la distribucin del software fsicamente
Diagramas Organizacionales (package o subsystem) Para mostrar la organizacin de alto nivel Diagramas de Clase Muestra las Clases y sus Interrelaciones
Opcionalmente se utilizan otros 2 diagramas:

Diagramas de Secuencia (sequence) o Diagramas de Comunicacin Muestran la interrelacin de objetos en un escenario particular
Diagramas de Estado Para mostrar la historia de Clases complejas
25
Generales
26
Deployment
27
Diagrama Conciso
28
Diagrama de Paquetes
Los Paquetes organizan Clases. Son un diagrama esttico.
29
Diagrama de Subsistemas
Los Subsistemas organizan Objetos. Son un diagrama dinmico.
30
Diagramas de Clase
Visibility (access privileges) indicated as follows:1 + public # protected ~ package private -- implementation visibility (inaccessible to other objects) (+) forced public. Override of an interface method that should be treated as private, even if it's declared public.
/ Derived attribute. Synthesized at runtime. Combine with access. (e.g. -height, -width, /+area) {property} Standard properties are: {readOnly}, {union}, {subsets property-name}, {redefines property-name}, {ordered}, {bag}, {seq} (or {sequence}), {composite}. example: /+area: integer {readOnly} abstract operations indicated by italics (or underline).
31
Diagramas de Clase
32
Diagramas de Clase
33
Agregacin y Composicin
Lo mismo.
34
Constraints
35
Asociacin Calificada
Llave
36
Clase Asociacin
37
Ejemplo
38
Expresando el Modelo en Software
Expresando el modelo en software Aislar el dominio Expresar la Estructura Expresar Comportamiento Complejo Controlar el Ciclo de Vida
40
Aislando el modelo Arquitectura de capas

Interfaz de Usuario
User Interface
Interaccin con usuario u otro sistema externo
Aplicacin
Define los trabajos que el SW debe realizar Dirige los objetos de Dominio Interaccin con capa de aplicacin de otros sistemas NO contiene reglas de negocio NO contiene estado de procesos de negocio Puede contener el progreso de una tarea de usuario
Application
Domain
Infrastructure
41
Aislando el modelo (cont.)

Dominio
User Interface
Application
Responsable de representar conceptos de Negocio Representa Informacin de la situacin de Negocio Representa reglas de negocio Representa el estado aunque delega a Infraestructura el almacenamiento del mismo
Infraestructura
Domain
Infrastructure
Capacidades tcnicas bsicas para las dems capas Envo de mensajes para Aplicacin Persistencia para Dominio Pintado de componentes para UI Puede soportar interacciones entre capas*
42
Ejemplo
User interface Application Domain Infrastructure
transferController
: FundsTransferService
a123 : Account
a234 : Account
Unit of Work Manager
O-R Mapper
transfer(a123, a234, $100) beginTransaction transferTo(a234, $100) credit(100) addToUnitOfWork ( a234 ) confirm
debit(100) collection contents: a123, a234 addToUnitOfWork ( a123 ) confirm commit update(collection)
Toda la transaccin falla si falla cualquiera de las operaciones credit o debit
43
Expresando el modelo en Software

Patrones bsicos
Asociations Entities Value objects Services Modules
Aggregates Factories Repositories
Ciclo de vida de un Objeto de Dominio
Access with Services
Repositories Access with Maintan integrity with
Express model with Express model with Model-Driven Design Encapsulate with Entities
Act as root of Aggregates
Express model with Value Objects Isolate domain with Layered Architecture
Encapsulate with Encapsulate with
Encapsulate with Factories
44
Expresando la Estructura
45
Modules
Consideraciones
Los mdulos en la capa de dominio deben nacer como una parte significativa del modelo Mdulos giles. Deben permitir la evolucin Paquetes por funcionalidad o por infraestructura? Qu tanto se tiene que dividir el modelo?
Routing
Schedulling
Accounting
Customer
46
Entities
Caractersticas
Tienen identidad, no son intercambiables No estn definidos por sus atributos Aadir solo comportamiento que sea esencial al concepto y atributos que soporten dicho comportamiento Puede estar asociada a otros Entities o Value Objects Coordinan las operaciones entre los objetos que le pertenecen
Person
Account
Shipment
Issue
Consideraciones Operacin identidad

Debe ser asignada? Puede ser una representacin interna? Agrupa varios conceptos de negocio? Se debe compartir por fuera del sistema en cuestin?
47
Value objects
Caractersticas
Son objetos que describen cosas Son intercambiables Se recomienda que sean inmutables Se recomienda no proporcionarles una operacin identidad Tienden a ser muy numerosos
TimeZone
Color
MovementType
Consideraciones
Debido a sus caractersticas son candidatos a simplificar el diseo u optimizar el performance Pueden ser candidatos a optimizaciones en base de datos (denormalization) Puede ser que se utilicen copias del mismo VO o instancias compartidas (shared instances) En un VO una relacin bidireccional generalmente no hace sentido.
48
Ejemplo
Entidad o Value Object?
Direccin Postal
Si sirve para Describir en donde vive una Entidad, es un Value Object. Es reemplazable. La Entidad puede cambiar de Direccin, y en ese caso simplemente se le asigna un nuevo Objeto. Si es un Elemento Principal de una Aplicacin (por ejemplo, un SW para calcular rutas), es una Entidad en s mismo. No es reemplazable. En s mismo representa un punto y es inalterable.
49
Asociations
Por cada asociacin navegable corresponde un mecanismo en el SW con las mismas caractersticas
Country president * Person
Country
president *
Person
Country period
president
Person
Opciones para simplificar asociaciones

Imponer direccin de navegabilidad Aadir calificador (reducir multiplicidad) Eliminar asociaciones que no sean esenciales
50
Patrones, patrones y patrones

Los Patrones no son Recetas de Cocina. Son herramientas.
Los Patrones amplan nuestro vocabulario de Diseo y nuestra capacidad de Expresin.
Design Patterns: Elements of Reusable Object-Oriented Software [Hardcover] The Gang of Four (GoF): Erich Gamma (Author) Richard Helm (Author) Ralph Johnson (Author) John M. Vlissides (Author)
51
Expresando Comportamientos Complejos
52
Services
Caractersticas
La operacin se relaciona con un concepto de dominio que no es parte de un Entity o un Value Object La interfaz se define en trminos de otros elementos del modelo No tienen estado No tienen significado fuera de la operacin que representan Son conceptos que no son simples de mapear a objetos Generalmente tienen nombres como *Manager Las operaciones tienen que provenir del Lenguaje Comn (ubiquitous language) o ser introducidas a este
RoutingService NotificationService
FundsTransferService
Consideraciones
Servicios y el aislamiento de la capa de dominio, servicios en capas Granularidad Acceso a servicios
53
Aggregates
Caractersticas
Demarcan el alcance en el que los invariantes son mantenidos a lo largo del ciclo de vida Root Entity tiene identidad global y es responsable de verificar los invariantes Las Entities dentro del lmite tienen identidad nica solo dentro del Aggregate Nada fuera del Aggregate puede ocupar una referencia directa a los Entities internos Root Entity puede proveer copias de los Value Objects internos Una operacin DELETE debe eliminar todo lo que se encuentre dentro del lmite del Aggregate Cuando se realice un Commit a cualquier objeto dentro del Aggregate todos los invariantes se deben satisfacer
<<Aggregate Root>> Engine
Wheel
<<Aggregate Root>> Car
Customer
4 Position * Tire
54
Aggregates - Invariants
<<Aggregate Root>> Car -vehicle identification number +rotate ( 4 tire/wheel ID pairs)(entrada )
Wheel -local ident {LF, LR, RF, RR}
4 Position -time period -mileage * Tire -local identity {arbitrary}
{time period must not Overlap on same wheel}
{mileage = sum(Position.mileage)}
55
Controlando el Ciclo de Vida
56
Ciclo de vida de un Objeto de Dominio

Tipo de objeto Simple
Sencillo Con tiempo de vida corto
Tipo de objeto Complejo

Tiempo de vida largo Dependencia con otros objetos Mantiene un estado interno
/ store / modify Active / reconstitute Database Representation
/ create
Problemticas
Mantener la integridad durante el periodo de vida Evitar que el modelo se complique al administrar el ciclo de vida
/ delete
/ archive
/ delete
Database or File Representation
57
Factories
new ( parameters )
client FACTORY
create
product
product
Caractersticas
Provee una interfaz que encapsula todo el ensamblado complejo Evita que los clientes hagan referencia a las clases concretas Crea un Aggregate completo y asegura que sus invariantes se cumplan Cada creacin es atmica Cada objeto creado es inicializado a un estado correcto Se debe abstraer al tipo deseado, no a las clases creadas La fabrica estar acoplada a sus parmetros
58
Factories
Tipos de Factory
True Factory Factory Method
Consideraciones
Entity Factories VS Value Object Factories Reconstruccin de Objetos almacenados Entity Factory para reconstruccin no asigna identificadores Un Factory para reconstruccin posiblemente maneja las violaciones de invariantes de manera diferente
59
Repositories
Selection criteria
client REPOSITORY
delegate
Matching objects
Database interface METADATA MAPPING FACTORIES Other REPOSITORIES QUERY OBJECTS Etc.
Caractersticas
Presenta a los clientes con un modelo sencillo para obtener los objetos y administrar su ciclo de vida Desacoplan el diseo de modelo y de aplicacin de la tecnologa de persistencia Comunican decisiones de diseo acerca de acceso a objetos Permiten reemplazo sencillo de implementacin para utilizacin en pruebas
60
Repositories
Consideraciones
El cdigo cliente ignora la implementacin del repositorio, los desarrolladores no Abstraer los tipos de retorno Aprovechar el desacoplamiento del cliente Dejar el manejo de transacciones al cliente Trabajar en conjunto con los Frameworks Factories o Repositories?
61
Ejercicio Instrucciones
De acuerdo al modelo definir
Entities Contorno de los aggregates y raiz de aggreggate Mecanismos de control de ciclo de vida de los objetos de dominio
Elementos de Modelo base

Curso Alumno Instructor Aula Horario
62
Bloques bsicos de Model-Driven Design
Access with Services Express model with
Repositories Access with Maintan integrity with
Express model with Model-Driven Design
Entities
Act as root of Aggregates Encapsulate with
Express model with Value Objects Isolate domain with Layered Architecture
Encapsulate with Encapsulate with
Encapsulate with Factories
63
Preguntas tiles
Asociations Entities / Value Objects
Es posible eliminar asociaciones innecesarias?
Todos los objetos requieren identidad? Algun Entity se puede intercambiar por Value object? Existe algn concepto que no se puede representar de manera simple en Objetos? Se estn respetando los lmites de los aggregates? Existe la posibilidad de crear un Aggregate u Objeto en un estado incongruente? Se est contemplando el almacenamiento de los nuevos Objetos? Alguna coleccin de objetos se est manipulando de manera directa? En que puntos se tiene contacto con la capa de infraestructura? Cul es la interfaz expuesta a la capa de aplicacin?
64
Services
Aggregates
Factories
Repositories
Capa de Infraestructura Capa de Aplicacin
65
Implementacin de DDD
66
Enfoque Convergente
Delivery Process, Reutilizacin, Recursos Humanos
Plataforma, Implementacin adecuada del Concepto de Negocio, Infraestructura
Perspectiva del Proyecto
Contexto, Mdulos, Entidades, Servicios
Alineacin de las 3 perspectivas
Perspectiva Tecnolgica
Perspectiva de Negocio
67
Arquitectura Hexagonal
68
Visin del Desarrollo de SW
69
Elementos de Desarrollo
Experto de Dominio
Experto en Modelado
Vista
Dominio
Integracin
Producto Desarrollador Tester
70
Oportunidades de Reutilizacin
Contextos Tpicos
Experto de Dominio
Experto en Modelado
Patrones
Vista
Dominio
Integracin
Componentes Generadores
Casos de Prueba Prueba Automtica
Producto Desarrollador Tester
71
Proceso de Desarrollo
Dominio Original
Contexto Personas
Contexto Proyectos
Contexto Costeo
reutilizar
implementar
modelar e implementar
integrar
Contexto ya implementado
Contexto conocido
Contexto desconocido
72
Fbricas Verticales
Contexto Personas Contexto Proyectos Contexto Costeo
modelar
Especialista de Dominio y Modelador (Seguros, Banca, Telco, Core)
implementar
Especialista de Plataforma (Java/.Net/Cobol/RPG)
Generar vista
Especialista de Interfaz de Usuario (Web, Mvil, RIA, Desktop)
Generar persistencia
Generador de Cdigo
Acoplar
Desarrollador de Plataforma
73
Referencias
Ligas
http://domaindrivendesign.org/ http://bit.ly/bbGqg0 http://www.holub.com/goodies/uml/ http://bit.ly/aH7gLk
Libros
Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans
UML Distilled: A Brief Guide to the Standard Object Modeling Language Martin Fowler
74
PREGUNTAS
75

Pcn01 Cursoddd s01 v2

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Pcn01 Cursoddd s01 v2

Diunggah oleh

Hak Cipta:

Format Tersedia

Domain Driven Design Diseo Guiado por Dominio

Instructor: Ramiro Gonzlez Snchez rgonzalez@ids.com.mx Rafael Martnez Montiel rmmontiel@ids.com.mx

Introduccin a UML para Diseo Expresando el Modelo en software Aislando el dominio

informacin confidencial Direccin de Tecnologa y Calidad

Pre-requisitos para el curso

informacin confidencial Direccin de Tecnologa y Calidad

Objetivos del curso

Objetivos del curso

informacin confidencial Direccin de Tecnologa y Calidad

Por qu es tan difcil hacer SW?

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

El Elemento de Mayor Complejidad

Desconocimiento del Negocio por parte de Usuarios

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

Abstraccin Representacin OO depurada de lo que nos interesa del Negocio

informacin confidencial Direccin de Tecnologa y Calidad

Se aplica desde los Requerimeintos

Dominio Aislamiento Reutilizacin/ Testing

Analisys & Design

Analisys & Design

Project Management Configuration and Change management Environment

Configuration and Change management Environment

informacin confidencial Direccin de Tecnologa y Calidad

El modelo es conocimiento depurado (Distilled Knowledge)

informacin confidencial Direccin de Tecnologa y Calidad

Mundo Real Mundo Virtual

Un elemento crtico, es Aislar los Conceptos de Dominio de los Mecanismos de Implementacin.

informacin confidencial Direccin de Tecnologa y Calidad

Modelando en voz alta

Documentos de diseo escritos

UML o no UML? Modelos de ejemplo

informacin confidencial Direccin de Tecnologa y Calidad

Implementacin (CO y PR, TDD por ejemplo)

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

Ejemplo de Un Solo Lenguaje

use Registro Confirmado Alumno Registro Cancelado

informacin confidencial Direccin de Tecnologa y Calidad

Eliminacin de Obstculos: Revela la Intencin, no la Implementacin

Obstculos en esta declaracin:

Alumno queda en lista de espera Va Web Service

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

http://bit.ly/aYsM1q (liga equivalente)

The Truth about BDD

informacin confidencial Direccin de Tecnologa y Calidad

Introduccin a UML para Diseo

informacin confidencial Direccin de Tecnologa y Calidad

Lo que debes saber de UML

Opcionalmente se utilizan otros 2 diagramas:

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad

informacin confidencial Direccin de Tecnologa y Calidad