Stefano Mariani's Student Project Proposals


Detailed info about ongoing and completed projects can be found here.

Here follows a list of proposals for student projects to be done either for the course of Distributed Systems held by Prof. Omicini (any year) or even as a starting point for a thesis (mostly, for 3-years degree).
If any of you are interested, or even just to get some info, feel free to contact me (mailto: Stefano Mariani) =)

The following projects have been divided into two different "categories", although they share a common goal (for you): learn what it means to model/design/implement/test a middleware.
Why middlewares? Basically 3 reasons:

  • being mostly projects proposed in the context of the Distributed System course, it seems reasonable (and profitable, for your career) to start "play" with something distributed: middlewares are perfect for the purpose
  • middlewares pose some non-trivial challenge both at the model, architectural and implementation level, mostly due to their typical distributed nature forcing programmers to drop many implicit assumptions made when programming a non-distributed setting (network is reliable, latency is zero, bandwidth is infinite, etc.)
  • a distributed middleware is already available, which is TuCSoN, so it seems reasonable not to start "from scratch". Furthermore, TuCSoN is a tuple-based coordination model and infrastructure, that is, a coordination artefact gaining increasing attention both from the academic world and from the industry.

The two categories can be named "TuCSoN as it is" and "TuCSoN as it will be", which basically means the following:

  • in "TuCSoN as it is" you will work on the ready-to-use TuCSoN distribution, improving/adding/fixing some details left behind during time
  • in "TuCSoN as it will be" you will start redesigning (from scratch) specific, well-delimited TuCSoN pieces based on its formal modal as it is described in TuCSoN papers
    What is the difference?
    The crucial point is that in the first case you deal with already existing code, thus will eventually deal with refactorings, dependency analysis, conflicts resolution; whereas in the latter case, you should face the issues of translating a model or, at best, an abstract architecture and an operational semantics, into code, carefully choosing which assumptions to make.
    Trust me: neither of the two is easier than the other.

TuCSoN "as it is"

NB: For the projects below, usage of Eclipse, Checkstyle and FindBugs is strongly suggested

  • Fault-tolerant TuCSoN (single or separate projects):
    • handling network failures and enabling supervisioning.
  • TuCSoN Debug & Inspection:
    • ReSpecT Language Check using tuProlog: ACC operations and tuple centre reactions.
    • Efficiently implement the observation mechanism provided by tuple centre '$OBS'.

TuCSoN "as it will be"

For any of the following project proposals, a list of reference papers is given (if any).

NB: For the projects below, usage of Eclipse, Maven, Checkstyle, FindBugs and PMD is mandatory




— mail

UniMoRe  |  AMS-UniBo

— personal page


— addresses

via Amendola 2 13
42122 Reggio Emilia, Italy

via dell'Università 50
47522 Cesena, Italy


— projects


— research

MoK  |  ReSpecT  |  TuCSoN  |  TU Wien Stuff

— teaching

IFTS 2019/2020  |  IFTS 2018/2019  |  IFTS 2015/2016  |  Distributed Systems   |  Concurrent and Distributed Programming

— software

ReSpecT  |  TuCSoN  |  T4J  |  T4Jn

— suggested readings

Academic Readings  |  Personal Readings

Partita IVA: 01131710376 - Copyright © 2008-2022 APICe@DISI Research Group - PRIVACY