APICe » Courses » LMC1011 » Progetti

Progetti

Note:

Si ricordano i principali aspetti relativi ai progetti da svolgere per l'esame:

  • Il progetto è comunque facoltativo, e può essere rimpiazzato da una prova orale sul programma del corso (la cui preparazione richiede tuttavia un tempo analogo, e può essere svolta in un qualunque periodo dell'anno, concordato col docente in anticipo)
  • Il progetto è scelto dallo studente in accordo col docente, può essere eseguito da un gruppo di 1, 2 o 3 persone (dipendentemente dall'impegno richiesto), e deve comportare un impegno temporale di circa 80-90 ore a testa (ogni studente è tenuto a tenere traccia delle ore impiegate per svolgere il progetto)
  • Una volta assegnato il progetto, verrà concordata anche la data di consegna. Eventuali proroghe dovranno essere contrattate col docente, e potrebbero comportare un penalizzazione di punteggio.
  • Qui sotto si elencano proposte del docente per i progetti. Si rammenta che altre possibilità possono essere relative a progetti suggeriti da altri docenti, o possono anche venire dagli studenti stessi. Nel caso in cui un progetto sia a carattere pratico piuttosto che scientifico (ossia sia relativo allo sviluppo di un software), si ricorda che sarà necessario portare tale software a completamento, in modo che sia ad esempio pubblicabile su SourceForge.
  • Per qualunque delucidazione o maggiori informazioni non si esiti a chiedere.
  • Questa lista verrà estesa via via nel tempo, anche dopo la fine del corso.

Consegna del Progetto:

  • Il progetto si consegna dopo aver svolto con esito positivo il compito. La consegna è in anticipo (solitamente per e-mail) al docente, che dopo aver fatto alcune verifiche di completezza/adeguatezza (e richiedendo qualche modifica) fissa una data per l'esame di comune accordo (solitamente nel giro di 1-2 settimane)
  • La documentazione del progetto deve essere correlata (ove possibile dipendentemente dalla tipologia di progetto) di: relazione in formato PDF completa di bibliografia, software prodotto (incapsulato in un JAR o JNLP per facilitarne il deployment), documento di installazione/uso README.txt, codice sorgente, manuale d'uso, documentazione javadoc della libreria
  • Per l'esame ci si deve preparare una presentazione di 15 minuti a cui seguirà una discussione (è possibile ma non necessario prepararsi delle slides). Si noti che nel caso di gruppi l'esame è svolto singolarmente, e ogni studente sarà responsabile della parte del progetto da lui stesso dichiarata (anche eventualmente/parzialmente sovrapposta a quella degli altri studenti)

Proposte di Progetto

Questa lista è fortemente dinamica. Progetti vengono tolti quando assegnati, aggiunti quando concepiti. Le indicazioni relative ad ogni proposta sono molto sintetiche: si contatti il docente per descrizioni più dettagliate.

  • 2p-ide: Consolidate current tuprolog IDE, and develop new features related to debugging and checking the correctness of a theory
  • 2p-p@j: Analyse, extend and find some suitable killer application for the P@J framework for Java-Prolog integration.
  • 2p-libs: (this is actually a project template) porting existing libraries of other Prologs (SWI, GNU, SICSTUS) into tuProlog; generally, even libraries for Java could be used
  • 2p-wam: The Warren Abstract Machine is an engine interpreting a bytecode version of Prolog, produced out of a compilation process. This projects aims at implementing engine and/or compiler directly using tuProlog as an implementation language.
  • 2p-meta-interpretation: Design a full Prolog metainterpreter, extending vanilla with the abilities of tracking substitutions, tracking resolution tree, supporting control predicates like cut, call, not, and so on.
  • 2p-imperative-language: The various step of a full interpreter (tokenization, parsing, checking and interpretation) can be specified declaratively, using BNF grammars and deductions. This projects will implement in tuProlog suitable meta-interpreters for those specifications, by adding proper (infix/prefix) operators and syntactic sugar.
  • 2p-advanced-dcg: creating a new DCG library, with advanced features such as AST flexible generation, LOOKAHEAD, tokenization
  • 2p-tokenizing: extend the DCG library with a full and efficient support to tokenization, reaching the same expressiveness of analogous frameworks like JavaCC or Jlex
  • 2p-fj-operational-semantics: using the operational semantics meta-interpreter, develop and implement an interpreter for Featherweight java
  • maude-2p: Prolog and Maude can interact with each other, e.g. by sockets; this project should develop flexible libraries for both sides of the integration
  • maude-metalevel: Maude is a reflective language, in that it can be used to parse and meta-execute other Maude specifications: this can be used to define slight extensions of Maude language for various purposes. This project analyse this feature and creates toy examples.
  • models-coloredpetri: Build an engine for colored Petri Nets, in which coloring is realised in a logic fashion by means of tuProlog integration.
  • models-mc-prolog: Implement a model-checker for LTL or CTL in Prolog.
  • models-msr-nets: MSR(C) is a tool to model-check infinite state systems, extending Petri Nets ideas. The goal of this project is to verify properties of given algorithms for self-organising networks.
  • models-respect++: ReSpecT is a declarative language (on top of tuProlog) for programming tuple centres in the TuCSoN coordination infarstructure. This projects aims at analysing how ReSpecT interacts with tuProlog, and designing some extensions/modifications that improve the ReSpecT language.
  • semantics-pellet: Develop a tuProlog library to access the main Pellet API, e.g. to load an OWL ontology, assert prolog terms as Fuzzy TBox axioms and Fuzzy ABox individuals, check ABox consistency, check subsumption between two concepts and perform instance checking and retrieval.
  • semantics-fuzzydl: Develop a tuProlog library to access the main fuzzyDL API, e.g. to load a fuzzy ontology, assert prolog terms as Fuzzy TBox axioms and Fuzzy ABox individuals and query the Fuzzy Knowledge base.
  • semantics-general-lib: Develop a tuProlog library to access a provided semantic module, that is, independently from a particular semantic reasoner (to load an ontology, assert prolog terms as ABox individuals, check ABox consistency, check subsumption between two concepts and perform instance checking and retrieval). Optionally, the project may study application of semantic matching instead of syntactic unification.
  • selforg-spatial: Starting from existing studies about chemical reactions creating spatial structures, simulate their behaviour using tools, and possibly propose new realted mechanisms.