title: Common Diagnostic Model
text: # Common Diagnostic Model
  
  El Common Diagnostic Model (CDM), que traducido al español significa "Modelo de Diagnóstico Común", es una arquitectura y metodología que facilita la integración de los módulos de diagnóstico tipo "plug in" en las aplicaciones de gestión por medio de interfaces estándar Common Information Model (CIM). La especificación técnica del CDM se rige por el Distributed Management Task Force (DMTF), y es una parte de CIM v2.5 y superior.
  
  # Common Diagnostic Model
  ## Apartado teórico
  ### Terminología
  
  Comon Information Model: (CIM o Modelo de Información Común) es un esquema orientado a objetos, y que no depende de la implementación, para describir la información de gestión de la red. La DMTF desarrolla y mantiene las especificaciones CIM.
  Distributed Management Task Force: (DMTF o Alianza de Tareas para la Gestión Distribuida) es un consorcio de empresas de hardware y software líder en el desarrollo de estándares de administración y en el fomento de interoperabilidad para ambientes distribuidos de empresa e Internet. Los estándares DMTF proporcionan componentes de infraestructura de gestión común para instrumentación, control y comunicación de un modo tecnológicamente neutral y de plataforma independiente.
  
  # Common Diagnostic Model
  ## Apartado teórico
  ### Modelo de Diagnóstico Común (CDM)
  
  CDM es una arquitectura y metodología para exponer diagnósticos de sistema a través de interfaces estándar CIM. La estandarización de estas interfaces significa que tanto clientes, proveedores y pruebas ganan un cierto grado de portabilidad y, en muchos casos, sólo necesitan ser escritos una vez para satisfacer los múltiples ambientes y plataformas.
  Como extensión del modelo CIM de DMTF, la especificación CDM es ampliamente usada dentro de la industria para evaluar la salud de los sistemas de ordenadores en ambientes de múltiples proveedores. Con ese fin, CDM especifica y crea la instrumentación de diagnóstico. Debido a que CDM se fundamenta en CIM, y a la sinergia con sus dominios gestionables, las pruebas de diagnóstico CDM pueden ser integradas dentro de funciones de gestión críticas. Técnicamente, CDM es un sistema operativo y arquitectura neutral de plataforma para:
  * Descubrir diagnósticos y sus capacidades.
  * Controlar la ejecución de los diagnósticos.
  * Recuperar resultados de los diagnósticos.
  
  # Common Diagnostic Model
  ## Apartado teórico
  ### Foro CDM
  
  El recién anunciado Foro CDM, parte de la Iniciativa de Interoperabilidad de DMTF, está ayudando en la entrega de compatibilidad adicional en los diagnósticos de sistema de plataforma cruzada, mediante la conformación de programas de prueba, además de un Kit de Desarrollador de Software (SDK). De esta forma, se optimiza el desarrollo e integración de módulos de diagnóstico dentro de la infraestructura CIM.
  
  # Common Diagnostic Model
  ## Apartado teórico
  ### Iniciativa CDM
  
  La Iniciativa CDM de Gestión de la Salud del Sistema es dirigida por el Foro CDM de DMTF para conducir a la industria hacia la amplia adopción del estándar, proporcionando la capacidad para desarrollar soluciones de gestión de salud interoperable basadas en CDM.
  La Iniciativa se esfuerza por facilitar a los proveedores de componentes la implementación de pruebas de diagnóstico y, en última instancia, entregar sistemas más robustos, fáciles de gestionar, a los usuarios. Con ese fin, sus elementos clave son un Kit de Desarrollo de Software (SDK), herramientas de prueba de conformidad, casos de uso y perfiles, tanto como un proceso de certificación.
  
  # Common Diagnostic Model
  ## Apartado teórico
  ### Motivación de CDM
  
  A través de la tecnología CDM, los Proveedores de Hardware Independiente (IHVs) no volverán a necesitar desarrollar soluciones de diagnóstico únicas para sus diversos clientes, reduciendo la inversión en desarrollo de diagnósticos. Además, los Proveedores de Software Independiente (ISVs) se beneficiarán de tener una única vía de distribución de sistemas de software adaptativo. Por último, los Fabricantes de Equipo Original (OEMs) se beneficiarán de tener un mejor nivel de apoyo desde los proveedores.
  
  # Common Diagnostic Model
  ## Apartado técnico
  ### Áreas conceptuales tratadas por el modelo
  
  CDM permite a las aplicaciones cliente de diagnóstico:
  * descubrir, configurar y ejecutar pruebas de diagnóstico.
  * ver el progreso y controlar la ejecución de la prueba.
  * ver y gestionar los resultados de ejecución de la prueba.
  La figura de debajo muestra el modelo al completo. La descripción del modelo se dividirá en tres secciones, una por cada actividad del cliente listada arriba.
  
  # Common Diagnostic Model
  ## Apartado técnico
  ### Descubrir, configurar y ejecutar pruebas de diagnóstico
  
  * DiagnosticTest: clase central del modelo. Esta clase representa las pruebas disponibles en un sistema. Contiene el método RunDiagnosticService para iniciar una prueba de diagnóstico, el cual toma como parámetro de entrada un ManagedElement sobre el que se ejecuta. Devuelve una referencia a un ConcreteJob para ver el progreso y controlar la ejecución de la prueba.
  * RegisteredProfile: contiene la información acerca del perfil al cual el diagnóstico es conforme. *ElementConformsToProfile asocia el diagnóstico al perfil adecuado.
  * AvailableDiagnosticService: asocia el diagnóstico al ManagedElement en prueba.
  * HostedService: asocia el diagnóstico al ComputerSystem anfitrión.
  * DiagnosticServiceCapabilities: contiene las capacidades de un diagnóstico.
  * DiagnosticSettingData contiene la configuración del diagnóstico.
  * JobSettingData contiene la configuración usada para la creación de Job.
  * ElementSettingData: asocia la configuración a la prueba de diagnóstico. Cuando ElementSettingData.IsDefault vale TRUE, se usará la configuración por defecto.
  * HelpService: describe la ayuda disponible y los métodos para solicitarla.
  * ServiceAvailableToElement: asocia el diagnóstico a su información de ayuda.
  
  # Common Diagnostic Model
  ## Apartado técnico
  ### Registro de progreso y control de la ejecución de la prueba
  
  * ConcreteJob: representa la ejecución del diagnóstico. Contiene información sobre el progreso de ejecución de la prueba, como JobState and PercentComplete. El método ConcreteJobRequestStateChange cambia el estado de ConcreteJob para suspender, reiniciar y abortar la ejecución de un diagnóstico.
  * AffectedJobElement: asocia el Job al ManagedElement en diagnóstico.
  * OwningJobElement: asocia el Job a la ejecución del diagnóstico.
  
  # Common Diagnostic Model
  ## Apartado técnico
  ### Visualización y gestión de resultados de ejecución de prueba
  
  * DiagnosticLog representa el diario de información registrada por el diagnóstico. El método DiagnosticLog.ClearLog borra todos los registros.
  * UseOfLog: asocia el diario al diagnóstico.
  * DiagnosticSettingDataRecord: contiene todas las configuraciones usadas para iniciar los diagnósticos.
  * DiagnosticCompletionRecord: contiene los resultados finales de todas las ejecuciones de diagnósticos.
  * DiagnosticServiceRecord: contiene el resto de información registrada, progreso, errores, advertencias, etc.
  * LogManagesRecord: agrega cada registro al diario.
  * RecordAppliesToElement: asocia cada registro al ManagedElement y el DiagnosticTest.
  * CorrespondingSettingDataRecord: asocia el resto de registros al de configuración para una misma ejecución del diagnóstico.