Table of Contents

  1. Introducción
  2. Requisitos
  3. Deseable
  4. Propuestas
    1. Sobre proyectos de ACM-SL
      1. QueryJ
      2. WebExtension
      3. AntVersion
      4. AntLang
      5. AntTest
      6. ContractChecker
    2. Herramientas
      1. Traductor de módelo lógico en físico y viceversa
    3. Verticales
      1. FishEye
      2. JIRA
    4. Módulos/Extensiones
      1. Trac: Javadoc
      2. Trac: Maven2
    5. JSRs
      1. JSR 247 (Data Mining 2.0)
      2. JSR 260 (Javadoc Tag Technology …
      3. JSR 263 (Fault Management API)
      4. JSR 269 (Pluggable Annotation …
      5. JSR 277 (Java Module System)
      6. JSR 284 (Resource Consumption …
      7. JSR 285 (Performance Management …
      8. JSR 289 (SIP Servlet v1.1)
      9. JSR 294 (Improved Modularity …
      10. JSR 305 (Annotations for …
  5. Referencias

PFC

Introducción

Requisitos

  1. Que sea interesante.
  2. Que esté muy claramente definido en cuanto a su envergadura.
  3. Si es software, el copyright es sacrificable, no así que no sea copyleft.
  4. Que sea gestionable: Periodos de investigación definidos, revisiones regulares, hitos pre-establecidos.

Deseable

  1. Que se base en tecnologías afines (ya sea desde un punto de vista práctico o teórico) a alguna de las siguientes:
    1. Java
    2. BD
    3. Diseño de lenguajes de programación
    4. Web Services
    5. J2EE

Propuestas

Sobre proyectos de ACM-SL

QueryJ

WebExtension

AntVersion

AntLang

AntTest

ContractChecker

Estaría relacionado con JSR 305[6].

Herramientas

Traductor de módelo lógico en físico y viceversa

El modelo lógico seguiría la nomenclatura de Silberschatz1, aunque habría que definir la especificación (XML?) de dichos modelos. El modelo físico podría seguir la propuesta de DDLUtils2. El modelo lógico se podría transformar en Dot3. Una aplicación GUI leería ese .dot, ejecutaría Graphviz y presentaría el grafo asociado. Se podría basar en KGraphViewer4, permitiendo actualizar el XML original de acuerdo a los cambios en el modelo.

Por otro lado, la traducción entre modelo lógico y físico no es trivial. El traductor sería un sistema experto cuyas reglas vendrían determinadas por las particularizaciones especificadas por el usuario: Si se mantienen los históricos, cómo se implementan las relaciones de herencia ISA, qué atributos son "esenciales" a una entidad y cuáles se pueden modelar como metadatos, etc.

Verticales

FishEye

JIRA

Módulos/Extensiones

Trac: Javadoc

Trac: Maven2

JSRs

JSR son las siglas de Java Specification Request5. Son propuestas de modificación del lenguaje o de tecnologías vinculadas al mismo, que después de ser evaluadas pueden formar parte del conjunto de especificaciones que formarán parte de futuras revisiones y en su caso exigirían a suministradores actualizar sus productos para soportarlas.

JSR 247 (Data Mining 2.0)

JSR 260 (Javadoc Tag Technology Update)

JSR 263 (Fault Management API)

JSR 269 (Pluggable Annotation Processing API)

JSR 277 (Java Module System)

JSR 284 (Resource Consumption Management API)

JSR 285 (Performance Management API)

JSR 289 (SIP Servlet v1.1)

JSR 294 (Improved Modularity Support in the Java Programming Language)

JSR 305 (Annotations for Software Defect Detection)

Ver [6].

Referencias

  1. 1. Database System Concepts
  2. 2. DDLUtils
  3. 3. Graphviz
  4. 4. KGraphViewer
  5. 5. Lista de todos los JSR
  6. 6. Annotations for Software Defect Detection