Update of /cvsroot/crickscore/documents/architecture
In directory sc8-pr-cvs1:/tmp/cvs-serv17008
Added Files:
System_Architecture.html
Log Message:
Initial Revision
--- NEW FILE: System_Architecture.html ---
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<title>System Architecture</title>
</head>
<body>
<h1>Architecture Discussion</h1>
The purpose of this is to outline what I think the architecture of the
application should be.<br>
This is in no way final, as with everything that is ever created in
relation to <b>crickscore</b>.<br>
<br>
I think that I'll structure this document on the layers of an
application that I can think of.
<h2>Database</h2>
I am open for discussion on this point, as to whether its a java or
other (c++) application. I assume that we will want it to be a open
source. Once we decide on which one to use, we should code the system
to work specifically
<h2>Data/Persistance Layer</h2>
We need an automated object-table mapping module. I would like
this to be a simple system to configure and modify. The major
option that I can think of at the moment is <span
style="font-weight: bold;">Hibernate</span>. This section
probably requires a bit more review.<br>
<h2>Business Layer</h2>
I think that we should use an existing web application framework to
handle the processing of the requests, security, authentication,
authorsiation, etc.. There are many of these frameworks around,
and I am going to spend some time investigating them and I will add new
documents based around each of these frameworks. These frameworks
are things like Struts and Torque.<br>
<h2>Presentation Layer</h2>
This layer will be dependent on the web framework provided, but I
assume it will be a JSPish type of front end. We need to create a
system to cache items used often on the UI. The Presentation
layer will have plugins aswell, so the system needs to support
dynamical content generation, based on the availble plugins that are
registered.<br>
<h2>Client Layer</h2>
The client system should be any modern browser. We should
maintain compatiblity with as many old browsers as possible, but this
should not limit any development options that we want to persue.
I think that we should be able to use the most modern features of
current browsers (DHTML, Javascript, etc).<br>
<h2>Development Approach</h2>
I think that we should define a core of the application that handles
all generic rules about the game of cricket and generic rules about
reporting and statistic generation. This core should manage
storing the data in the database and allow access of this information
to any plugin or addition to the system. I think that each of
these modules/plugins should be developed and as a separate
module. The initial modules I can think of would be outdoor
scoring system, indoor scoring system, outdoor statistic generation,
indoor statistic generation.<br>
<br>
There should be an way upload a set of data to the core and have it
insert it into the database. I expect that this upload file will
be an XML file, in which the format will be defined at a later date.<br>
<h2>General Architecture Discussion</h2>
<h3>Plugin System</h3>
Many sections of the system should be managed by runtime addition of
plugins. Each plugin should extend a base type (ie. Report,
Statistic) and should be instantiated and initalised via either a
configuration file or a user initated process. When the plugins
are initatated, they should be able to register themselves availbile
for use by the system. Different types of plugins would work in
different ways, some would re-act to certain events, others would wait
to be invoked by the user, others may just run at specific times.<br>
<h3>Listener Usage</h3>
Each of the Business objects should allow listeners to register with
either the class or an instance. Each BO should allow multiple
different events to be watched. This is to facilitate the ability
for unrelated objects to add themselves to listen to events
generated. Plugins will utalise this listerner/producer pattern
extensivly, this is to facilitate the loosly coupled design principal.<br>
<h3>Inheritance Structure</h3>
There will be enties in the system like Game, Innings, Over, Ball,
etc.. These classes should be abstract base classes, allowing for
implementations for each item based on the type of game and rules that
exist. When the user says that a new game is to be started, the
system will check what game plugins are loaded, offer these types for
the user to select from and then based on that selection from the user
instansicate the Game object. This game object will then drive
what actions are done to start the game (how many players, who they
are, etc). Once the game has been started this specific instance
then manages creating innings objects of the same type, then overs and
balls. The base classes define the attributes that each of these
objects contain, but the sub-classes provide the logic of how the
different entities work (like how many players in a game, balls in an
over, possible ball options, etc.<br>
</body>
</html>
|
