Class Diagrams - ViralKaos/Frozen-Bubble-Android-port-x86 GitHub Wiki
Conceptual Class Diagram
Actual Class Diagram
The system diagram (class diagram of the system) represents the most important parts of the android app. It includes the classes needed for the game to work properly. Since we are mainly concerned about the mechanics of the game, some classes that involved Bit Map wrapping and images have been excluded since they are meant more for the visual aesthetics of the game rather than how the gameplay and interface is implemented.
The main class that creates the other objects in the application is called the FrozenBubble. This class initializes the menu, the game view, the options, sprites in the game, the orientation of the screen according to the mobile device, and everything else that is associated with the setup of the game. The FrozenBubble class has associations with the GameView and GameThread class. It also implements the interfaces GameListener and AccelerometerListener. The GameView class is essentially the touch screen of the application. It pertains to all the events applicable (such as swiping or single touch) when touching the mobile application screen. The GameView has associations with the GameListener interface and the GameThread class. The GameThread is the class that decides what to do with the touch events. This leads to the association relationship with the actual game itself, the FrozenGame class. The FrozenGame class is a generalization of the GameScreen class; a class that updates the screen in which the user interacts with. The FrozenGame class is associated with BubbleSprite class, BubbleManager class, LaunchBubbleSprite class, MalusBar class, HighScoreManager class, and the LevelManager class. These classes deal with the various objects and data in the game such as the bubbles and their behavior, the high score, and the current or future levels of the game. The BubbleSprite class is also associated with the BubbleManager class and he HighScoreManager class is associated with the HighScoreDB class. There is also a ComputerAI class that is associated with the FrozenGame class and the Freil class. The ComputerAI class determines how the computer will play against the user. The class also implements the OpponentListener interface. The Freile class is also associated with the OpponentListener.
Other classes that do not have relationships with the FrozenGame class but are still essential to the application are the CollisionHelper, SplashScreen, PreferenceActivity, AccelerometerManager, and the HighScoreDO classes. The CollisionHelper is an essential helper class for how the game will play. The SplashScreen class manages the splash screen that appears when the game is launched. This class allows the player to start the game with a button. PreferenceActivity allows the user to change the settings of the game (difficulty, full screen, etc.). The AccelerometerManager allows the game view to be rotated according to the orientation of the mobile device. Finally, the HighScoreDO class collects data for determining a high score in the game.
More or less, the class diagram of the system maps to most of the architecture of the conceptual diagram. For instance, the TouchScreen can be interpreted as the GameView, GameThread, GameScreen, and FrozenGame classes. The HighScore and WinOrLose classes can be mapped to the HighScoreManager, HighScoreDA, and HighScoreDO classes. The Ball class maps to the BubbleSprite, BubbleManager, and the Freile classes. The Boundary class can be interpreted as the CollisionHelper class as well as the BubbleManager and LaunchBubbleSprite classes. The MainMenu class is the SplashScreen class, and the Options class is the PreferenceActivity class.
Some of the classes that are not similar are the Player, Options, and BackButton classes. The Player class is essentially the user of the application, and a user cannot be a class. The Options class, which is mapped as PreferenceActivity, is not associated with the MainMenu; it is a class on its own. Also not associated with the MainMenu is the BackButton. The BackButton class was more of a reference to a physical button on a mobile device and therefore will not interfere with the architecture of the project.
Even with these slight difference, we believe the architecture (functionality) of the system will not change and it will be very close to what our conceptual diagram indicates it will be. The core implementations of the classes match with the conceptual classes. There may be more than one actual class that make up a conceptual class but at least the general idea and structure of the project is implemented the way we originally believed it to be.
Tool used : ObjectAid UML Explorer - This tool allowed us to extract the classes used in the project into a UML class diagrams. This tool made it much easier to extract all attributes and functions and place them in a class diagram rather than going through each class and finding each and every attribute and function. Furthermore, the tool provided all the types of relationships between the classes such as associations, generalizations, and interface implementations.