Michael's Design Study
(→First Glances) |
|||
Line 96: | Line 96: | ||
It is difficult to identify other patterns with such little implementation. | It is difficult to identify other patterns with such little implementation. | ||
+ | |||
+ | == Final Design == | ||
+ | |||
+ | [[Image:Mpp40_virus_uml_final.PNG|thumb|center|upright=3.0|Virus! - The end result of the preliminary implementation.]] | ||
+ | |||
+ | |||
== Michael == | == Michael == |
Revision as of 02:20, 4 October 2010
Contents |
Virus! A project for 427
Virus! simulates the spread of a virus across a plane of red blood cells, with a mix of some white blood cells to combat the infection.
Project Outline
My Design Study is to implement a simple virus simulator and to improve the design of the application through Design Patterns and OOD principles. Virus! is a very simple animated simulator of a Virus Cell infecting a host through the red blood cells. This simulator is loosely based on real world biology but is grossly simplified for purposes of the study. This is a project for COSC427 and does not work alongside any other course, unfortunately.
Virus! Cells
Cell Rules
- Red Blood cells can be Infected
- Virus' can only infect neighboring red cells
- Virus' cannot infect White blood cells
In terms of a simple immune system three types of white blood cells exist; Dendrite Cell, Lymphocytes and Eosinophil.
- Dendrites can spawn Lymphocytes or Eosinophil (50/50 chance) cells into neighboring Red Blood Cells.
- Lymphocytes can kill neighboring viruses (and restore Red Blood Cells).
- Eosinophil cannot be infected. But does nothing more.
For some basic references see White Blood Cell
Simulator Rules
The simulator itself is totally automated, there is no user input. The simulator takes place in a Petri dish (like that in a science lab). The aim of the simulator is to see if the virus can spread throughout the petri dish, or whether the White Blood cells can destroy the Virus. Red Blood cells do nothing apart from provide positions for the Virus and White blood cells to move about.
When a White blood cell makes a move, they swap positions with the Red Blood Cell. A Virus also swaps with the Red blood cell, but converts the cell into a virus. The game plays through the following 'phases' until a winner is determined;
- White blood cells move
- Virus move
Each cell makes one move per phase (apart from Red blood cells).
Initial Design
This is a basic overview of the simulator. It shows a basic spread of red blood cells and a variety of white blood cells.
Simulator View
UML Draft
This initial draft has some similar elements from the 324 Assignment 2 (Balls), just to get it started.
First Glances
After struggling with the implementation of the application I decided to move forward and focus on the design with what I had available. Initial observations of the application included;
Cell subclasses - Strategy vs. Decorator
The two Design patterns are both suitable for the design, but in different situations there are clear differences between the two patterns.
Strategy
- If the cells want to interchange (Like when a virus takes over a red blood cell)
Decorator
- Provides extended functionality (When a new type of cell wants to be introduced)
- It also provides interchangeability
- It gives a concrete class for an Observer to observe
I decided that the Decorator pattern will work better in this application as I intend to use an Observer. This would be more difficult to work into the model if I choose a Strategy pattern due to the lack of a concrete class.
Model View Controller - VirusApp + VirusGUI
The problem is the lack of user input. If a MVC was implemented the Controller element appears to be rather useless since there is no response from the user. If the application was to be extended to include user input (The user wishes to play the role of a virus, planning its moves) then it would be wise to include a MVC.
It is difficult to identify other patterns with such little implementation.
Final Design