Architecture for SEMF

SEMF ( Sport Event Management Framework) My final year project is hoped to back to active after the exam. Anyway it is in a state which should be start right from the beginning. We spend the last semester waisting time on finding projects, and ultimately selected this one - SEMF which I think is a failure in my point of view. Anyway now we select the stuff, we have to do it.

The problem of the SEMF is its simplicity. It seems kind of too simple for a final year project. What can we do is, do it in the hardest way which may sometime not work at all.

So we are searching for a harder architecture to implement which is highly flexible, highly integrable, and with many great things.. So I suggested one.

We are providing interfaces to define tables and views.

In defining tables it is allowed to do all the operations from creating tables to inherit tables from a graphical interfaces. It may not ultimately be the normalized database. But the final system should work with that funny database.

Then the hardest part defining views. (We would do this only we could finish defining tables part:(. ) We have to give the views with all the links, menus, tabs. And most importantly these all should be able to define using a graphical interface.

One way of doing this is following what portlet does. But the thing I was unable to find how they work with database. So our system should provide little windows like portlets to provide different views. But with some greater interaction with databases.

The features set I am thinking of providing is like this.

1. Different User level would have different interfaces. At the runtime some users may need to change their privileges. So system should be able to extend their accesses with the admission of a higher privilege one.
e.g.
Players - At the front interfaces players see the events information they are playing.for. The event information may include the competitors status, playground information.
Playground Staff - See Event playing in that particular day, weather status around the ground
Publics - The general view of the public.

(As far as I see this is the main feature, but it would be thing that maximize the complexity of the architecture. Eliminating this feature we can reduce the complexity more than half)

2. The interfaces would highlight the events according to the time.
e.g.
Relevant Players, Playground Staff, Administrators would be highlighted the events happing on the particular day.
Administrators would be able to handle different stages of organizing the event like register by number stage, register by name stage. This can be defined while defining views.

3. Interfaces in printing reports, defining forums, and announcements

Well there are some other features like web services interfaces for registered media and similar things. But I think it need not be considered in the first phase of the architecture.

I have today and tomorrow. I should do whatever I can do to come up with an architecture. The Architecture of the lifetime...