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
  <p/>
  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

• TuCSoN communication language: abstract tuples, tuProlog tuples and Java tuples design for agents and tuple spaces (two distincts projects)
  • Generative Communication in Linda
  • On the Semantics of Tuple-based Coordination Models
  • Coordination Models and Languages
• TuCSoN coordination language: coordination primitives design towards ACCs run-time negotiation
  • Generative Communication in Linda
  • On the Semantics of Tuple-based Coordination Models
  • Coordination Models and Languages
  • Bulk Primitives in Linda Run-time Systems
  • Tuple-based Coordination of Stochastic Systems with Uniform Primitives
• TuCSoN coordination artefacts: tuple spaces type hierarchy (assigned to Ridolfi, Smiraglio), identification and reference (possibly, two distinct projects)
  • On the Semantics of Tuple-based Coordination Models
  • Comparing Coordination Models based on Shared Distributed Replicated Data
  • The A&A Programming Model and Technology for Developing Agent Environments in MAS
• ReSpecT: language, virtual machine, data structures (possibly, multiple projects)
  • From Tuple Spaces to Tuple Centres
  • Formal ReSpecT in the A&A Perspective
  • Time-Aware Coordination in ReSpecT
  • Situated Tuple Centres in ReSpecT
  • Space-aware Coordination in ReSpecT
  • Tuple-based Coordination of Stochastic Systems with Uniform Primitives
• TuCSoN boundary artefacts: agents and probes identification and reference through ACCs and Transducers, respectively (two distinct projects)
  • Agent Coordination Context: From Theory to Practice
  • Agent Coordination Contexts: Experiments in TuCSoN
  • Agent Coordination Contexts in a MAS Coordination Infrastructure
  • TuCSoN Coordination for MAS Situatedness: Towards a Methodology (not yet published)
• TuCSoN event model: events representation along with associate APIs (strong relationship with ReSpecT)
  • Formal ReSpecT in the A&A Perspective
  • Coordinating Activities and Change: An Event-Driven Architecture for Situated MAS (not yet published)
• TuCSoN nodes: distribution-related aspects, identity and reference, naming and location services (assigned to Foschini, Benini, Farneti), architectural components including event queues, coordination artefacts (tuple spaces) manager, boundary artefacts (ACCs and Transducers) manager, spatio-temporale fabric related issues (multiple distinct projects)
  • TuCSoN on Cloud: An Event-driven Architecture for Embodied / Disembodied Coordination
  • Agents, Nodes & Resources: Universal Naming System for a Coordination Middleware
  • Situated Tuple Centres in ReSpecT
  • Agent Coordination Context: From Theory to Practice